Plano Anual da Fundação Wikimedia/2024-2025/Metas/Infraestrutura
Este documento representa a primeira parte do processo do Planejamento Anual de 2024-25 para o departamento de Produto e Tecnologia da Fundação Wikimedia. Ele descreve o esboço dos "objetivos e resultados-chave" (OKRs, na sigla em inglês) dos departamentos. Esta é uma continuação da estrutura de portfólios de trabalho (conhecidos como "baldes") que começou ano passado.
.jpg)
Eu falei com todas e todos vocês em novembro sobre o que eu acredito ser a pergunta mais urgente que o movimento Wikimedia enfrenta: como garantimos que a Wikipédia e todos os projetos Wikimedia sejam multigeracionais? Eu gostaria de agradecer a todas as pessoas que tiraram um tempo para realmente considerar essa pergunta e me responder diretamente, e agora que eu tive a chance de passar um tempo refletindo sobre suas respostas, eu vou compartilhar o que aprendi.
Em primeiro lugar, não há razão única pela qual pessoas voluntárias contribuem. Para nutrir múltiplas gerações de pessoas voluntárias, precisamos entender melhor as várias razões pelas quais as pessoas contribuem com seu tempo para nossos projetos. Depois, precisamos focar no que nos destaca: nossa habilidade de prover conteúdo confiável conforme a desinformação e as informações falsas se proliferam pela internet e em plataformas que competem pela atenção das novas gerações. Isto inclui garantir que atinjamos a missão de reunir e entregar a soma de todo o conhecimento humano para o mundo expandindo nossa cobertura e informações faltantes, o que pode ser causado por iniquidade, discriminação ou viés. Nosso conteúdo precisa também servir e permanecer vital em uma internet em mutação e guiada por inteligência artificial e experiências ricas. Por fim, precisamos encontrar maneiras de financiar sustentavelmente nosso movimento construindo uma estratégia compartilhada para nossos produtos e receita para que possamos financiar este trabalho a longo prazo.
Essas ideias serão refletidas no plano anual de 2024-2025 da Fundação Wikimedia, cuja primeira porção eu estou compartilhando com vocês hoje na forma de objetivos rascunhados para o nosso trabalho de produto e tecnologia. Como no ano passado, nosso plano anual inteiro será centrado nas necessidades tecnológicas de nossos públicos e plataformas, e nós gostaríamos de ter o seu feedback para saber se estamos focando nos problemas corretos. Esses objetivos se constroem a partir de ideias que temos ouvido de membros da comunidade ao longo dos últimos vários meses em Discutindo:2024, em listas de emails e páginas de discussões, e em eventos da comunidade sobre nossa estratégia de produto e tecnologia para o ano à frente. Você pode ver a lista completa de objetivos rascunhados abaixo.
Um "objetivo" é uma direção de nível alto que moldará os projetos de produto e tecnologia que tocaremos no próximo ano fiscal. Eles são intencionalmente amplos, representam a direção de nossa estratégia e, importantemente, que desafios estamos propondo priorizar em meio às várias possíveis áreas de foco para o ano vindouro. Estamos compartilhando isso agora para que membros da comunidade possam ajudar a moldar nosso pensamento em estágio inicial e antes que se criem compromissos com orçamentos e alvos mensuráveis para o ano.
Comentários
Uma área em que nós particularmente gostaríamos de receber feedback é o nosso trabalho agrupado sob o nome "Wiki Experiências". "Wiki Experiências" é sobre como nós entregamos, melhoramos e inovamos eficientemente a maneira com que as pessoas usam diretamente as wikis, seja como contribuidoras, consumidoras ou doadoras. Isto envolve trabalho para apoiar nossa tecnologia central e nossas capacidades e garantir que podemos melhorar a experiência de pessoas editoras voluntárias — particularmente aquelas que têm direitos estendidos — por meio de funcionalidades e ferramentas melhores, serviços de tradução e melhorias de plataforma.
Aqui vão algumas reflexões de nossas discussões de planejamento recentes, e algumas questões para todas e todos vocês nos ajudarem a refinar nossas ideias:
- Voluntariar-se em projetos Wikimedia deveria ser gratificante. Nós também achamos que a experiência da colaboração online deveria ser uma parte importante do que faz o voluntariado voltar. O que é necessário para o voluntariado achar que editar é gratificante, e para trabalhar melhor conjuntamente para construir conteúdo confiável?
- A confiabilidade do nosso conteúdo é parte da contribuição única da Wikimedia para o mundo, e é o que mantém as pessoas vindo à nossa plataforma e usando nosso conteúdo. O que podemos construir que ajudará a aumentar conteúdo confiável mais rapidamente, mas ainda dentro dos padrões de qualidade determinados pelas comunidades em cada projeto?
- Para continuar relevante e competir com outras grandes plataformas online, a Wikimedia precisa de uma nova geração de consumidores que sintam conexão com o nosso conteúdo. Como podemos tornar nosso conteúdo mais fácil de ser descoberto e interagir com as pessoas que nos leem e nos doam?
- Em uma era em que abusos online resistem, precisamos garantir que nossas comunidades, plataforma e sistema de serviço estejam protegidos. Nós também enfrentamos obrigações legais crescentes, com legisladores globais buscando moldar a privacidade, a identidade e o compartilhamento de informações online. Que melhorias às nossas capacidades de enfrentamento de abusos nos ajudarão a abordar esses desafios?
- MediaWiki, a plataforma de software e interfaces que permitem à Wikipédia funcionar, precisam de apoio contínuo pela próxima década de modo a fornecerem a criação, moderação, armazenamento descoberta e consumo de conteúdo aberto e multilíngue em larga escala. Que decisões e melhorias de plataforma podemos fazer este ano para garantir que o MediaWiki seja sustentável?
Objectives
O mais alto nível de planejamento - os "Objetivos" estão atualmente publicados
O próximo nível - o rascunho dos "Resultados-Chave" (KR, na sigla em inglês) para cada objetivo finalizado estará disponível para discussão aqui em março.
As "Hipóteses" subjacentes para cada KR serão atualizadas nas páginas wiki do projeto/equipe relevante ao longo do ano, à medida que as lições forem aprendidas.
| Experiências Wiki (WE) rascunho de objetivos | ||||
|---|---|---|---|---|
| Objetivo | Área de referência | Objetivo | Contexto do objetivo | Titular |
| WE1 | Experiência das pessoas que contribuem | Pessoas que contribuem experientes e novatas se reúnem online para construir uma enciclopédia confiável, com mais facilidade e menos frustrações. | Para que a Wikipédia seja vibrante nos próximos anos, devemos trabalhar para desenvolver e estimular múltiplas gerações de pessoas voluntárias e garantir que as pessoas queiram contribuir. Diferentes gerações de pessoas voluntárias precisam de investimentos diferentes – as pessoas que contribuem mais experientes precisam que seus poderosos fluxos de trabalho sejam simplificados e corrigidos, enquanto as pessoas que contribuem novatas precisam de novas maneiras de editar que façam sentido para elas. E ao longo destas gerações, todas as pessoas que contribuem devem ser capazes de se conectarem e colaborarem umas com as outras para realizarem o seu trabalho da forma mais impactante possível. Com isto em mente, melhoraremos os fluxos de trabalho críticos para as pessoas que contribuem experientes, reduziremos as barreiras para que as pessoas que contribuem novatas possam realizar contribuições construtivas e investiremos para que as pessoas voluntárias possam se encontrar e comunicar umas com as outras em torno de interesses comuns. | Marshall Miller |
| WE2 | Conteúdo enciclopédico | O aumento do crescimento do conteúdo enciclopédico é alcançado através de ferramentas e recursos que são mais fáceis de acessar, reutilizar, melhorar e que podem garantir de forma fidedigna a confiabilidade do conteúdo de acordo com as políticas e barreiras de proteção usadas nos projetos da Wikimedia. | O conteúdo enciclopédico principalmente na Wikipédia pode ser aumentado e melhorado através de engajamento e inovação de forma contínua. As ferramentas e recursos (técnicos e não técnicos) que estão disponíveis para as pessoas que contribuem usarem para atender suas necessidades podem se tornar mais detectáveis e confiáveis. Estas ferramentas devem ser mais bem apoiadas pela Fundação Wikimedia, através de melhorias de funcionalidades que possam ser realizadas em ciclos curtos. Levando em consideração as tendências recentes em torno da geração de conteúdo assistida por IA e na mudança do comportamento dos usuários e usuárias, também exploraremos a base para mudanças substanciais (por exemplo, Wikifunções) que possam ajudar a impulsionar o crescimento em escala da criação e reutilização de conteúdo. Os mecanismos para identificar lacunas de conteúdo devem ser mais fáceis de serem descobertos e usados para fins de planejamento. Os recursos que apoiam o crescimento do conteúdo enciclopédico, incluindo conteúdo de projetos irmãos, projetos como a Biblioteca Wikipédia e campanhas, podem ser mais bem integrados aos fluxos de trabalho de contribuição. Ao mesmo tempo, os métodos utilizados para o crescimento devem ter barreiras de proteção contra ameaças crescentes, que possam garantir que haja confiança contínua no processo, mantendo-se fiéis aos princípios básicos do conteúdo enciclopédico, conforme reconhecido nos projetos da Wikimedia.
Público-alvo: Comunidade editora, pessoas tradutoras |
Runa Bhattacharjee |
| WE3 | Experiência das pessoas consumidoras (leitura e mídia) | Uma nova geração de pessoas consumidoras está chegando à Wikipédia para descobrir um destino preferido para descobertas, se engajar e criar uma conexão duradoura com conteúdo enciclopédico. | Metas:
Reter as gerações atuais e novas de pessoas consumidoras e doadoras. Aumentar a nossa relevância para as gerações atuais e novas de pessoas consumidoras, facilitando a descoberta de e a interação com nosso conteúdo. Trabalhar em várias plataformas para adaptar as nossas experiências e conteúdos existentes, para que o conteúdo enciclopédico possa ser explorado e curado por e para uma nova geração de pessoas consumidoras e doadoras. |
Olga Vasileva |
| WE4 | Confiança e Segurança (Trust & Safety em inglês) | Melhorar a nossa infraestrutura, ferramentas e processos para que estejamos bem equipados para proteger as comunidades, a plataforma e os nossos sistemas de serviço contra diferentes tipos de abusos direcionados e em grande escala, ao mesmo tempo que permanecemos em conformidade com um ambiente regulatório em constante mudança. | Alguns aspectos das nossas capacidades de combate ao abuso precisam de ser melhoradas. A mitigação de abusos baseada em IP está se tornando cada vez menos eficaz, várias ferramentas administrativas precisam ser melhoradas para serem mais eficientes e precisamos ter uma estratégia unificada que nos ajude a combater o abuso em grande escala usando em conjunto vários sinais e mecanismos de mitigação (captchas, bloqueios etc.). Ao longo deste ano, começaremos a progredir nas questões mais importantes nesta área. Além disso, este investimento na proteção contra abusos deve ser equilibrado junto com um investimento na compreensão e melhoria da saúde da comunidade, vários aspectos dos quais estão incluídos em vários requisitos normativos. | Suman Cherukuwada |
| WE5 | Plataforma de conhecimento I (evolução da plataforma) | Evoluir a plataforma MediaWiki e suas interfaces para melhor atender às necessidades fundamentais da Wikipédia. | A plataforma MediaWiki foi desenvolvida para permitir a criação, moderação, armazenamento, descoberta e consumo de conteúdo aberto e multilíngue em grande escala. Neste segundo ano da Plataforma de Conhecimento, examinaremos o sistema como curadores e começaremos a trabalhar em melhorias na plataforma para apoiar eficazmente as necessidades fundamentais dos projetos da Wikimedia durante a próxima década, começando pela Wikipédia. Isto inclui continuar o trabalho para definir a nossa plataforma de produção de conhecimento, fortalecer a sustentabilidade da plataforma, focar no sistema de extensões/ganchos para esclarecer e agilizar o desenvolvimento de funcionalidades, e continuar a investir no compartilhamento de conhecimento e permitir que as pessoas possam contribuir para MediaWiki. | Birgit Müller |
| WE6 | Plataforma de conhecimento II (serviços para desenvolvedores) | A equipe técnica e os desenvolvedores voluntários têm as ferramentas necessárias para apoiar de forma efetiva os projetos da Wikimedia. | Continuaremos o trabalho já iniciado para melhorar (e expandir) os fluxos de trabalho de desenvolvimento, teste e implantação na Wikimedia Production e expandir a definição para incluir serviços para desenvolvedores de ferramentas. Também pretendemos melhorar nossa capacidade de responder às perguntas mais frequentes no fluxo de trabalho e no público relacionados a desenvolvedores/engenharia e tornar os dados relevantes acessíveis para permitir a tomada de decisões bem-informadas. Parte deste trabalho consiste em analisar as práticas (ou a falta delas) que atualmente representam um desafio para o nosso ecossistema. | Birgit Müller |
| Serviços de sinais e dados (SDS) rascunho de objetivos | ||||
|---|---|---|---|---|
| Objetivo | Área de referência | Objetivo | Contexto do objetivo | Titular |
| SDS1 | Shared insights | Nossas decisões sobre como apoiar a missão e o movimento da Wikimedia são informadas por métricas e insights de alto nível. | Para que possamos construir tecnologia de forma eficaz e eficiente, apoiar pessoas voluntárias e defender políticas que protejam e promovam o acesso ao conhecimento, precisamos compreender o ecossistema da Wikimedia e estarmos alinhados com o que significa o sucesso. Isso significa acompanhar um conjunto comum de métricas que sejam confiáveis, compreensíveis e disponíveis em tempo hábil. Significa também trazer à tona pesquisas e insights que nos ajudem a compreender o como e o porquê por trás de nossas medições. | Kate Zimmerman |
| SDS2 | Plataforma de experimentação | Gerentes de produtos podem avaliar com rapidez, facilidade e confiança os impactos dos recursos do produto. | Para permitir e acelerar a tomada de decisões informadas por dados sobre o desenvolvimento de recursos de produtos, gerentes de produtos precisam de uma plataforma de experimentação na qual possam definir recursos, selecionar públicos de tratamento de pessoas usuárias e ver medições de impacto. Acelerar o tempo entre o lançamento e a análise é fundamental, pois a redução do cronograma de aprendizagem acelerará a experimentação e, em última análise, a inovação. Tarefas manuais e abordagens de medição personalizadas foram identificadas como barreiras à velocidade. O cenário ideal é que gerentes de produtos possam passar do lançamento do experimento à descoberta com pouca ou nenhuma intervenção manual de engenheiros e analistas. | Tajh Taylor |
| Públicos futuros (FA) rascunho de objetivo | ||||
|---|---|---|---|---|
| Objetivo | Área de referência | Objetivo | Contexto do objetivo | Titular |
| FA1 | Testar hipóteses | Fornecer recomendações sobre investimentos estratégicos a serem considerados pela Fundação Wikimedia - com base em insights provenientes de experimentos que aprimoram nossa compreensão de como o conhecimento é compartilhado e consumido online - que ajudam nosso movimento a atender novos públicos em uma Internet em evolução. | Devido às mudanças contínuas na tecnologia e no comportamento das pessoas usuárias online (por exemplo, a crescente preferência pela obtenção de informações através de aplicativos sociais, a popularidade do entretenimento educativo em vídeos curtos, a ascensão da IA generativa), o movimento Wikimedia enfrenta desafios para atrair e reter leitores e leitoras e pessoas que contribuem. Estas mudanças também trazem oportunidades para atender novos públicos, criando e fornecendo informações de novas maneiras. No entanto, nós, como movimento, não temos uma imagem clara, baseada em dados, dos benefícios e compensações das diferentes potenciais estratégias que poderíamos adotar para superar desafios ou aproveitar novas oportunidades. Por exemplo, deveríamos...
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 para o movimento Wikimedia – a serem consideradas para atrair e reter públicos futuros. |
Maryana Pinchuk |
| Suporte de produto e engenharia (PES) rascunho de objetivo | ||||
|---|---|---|---|---|
| Objetivo | Área de referência | Objetivo | Contexto do objetivo | Titular |
| PES1 | Eficiência das operações | Tornar o trabalho da Fundação mais rápido, mais barato e mais impactante. | A equipe da Fundação Wikimedia faz muito em seu trabalho normal para que nossas operações sejam mais rápidas, mais baratas e mais impactantes. Este objetivo destaca iniciativas específicas que a) trarão ganhos substanciais em direção a resultados mais rápidos, mais baratos ou mais impactantes; bem como b) realizar esforços coordenados e alterar as práticas formais e informais da Fundação. Os resultados chaves (KRs) incluídos neste objetivo são essencialmente as melhorias mais difíceis e eficazes que podemos fazer este ano em termos de eficiência operacional do trabalho que afeta nossos produtos e tecnologia. | Amanda Bittaker |
Resultados-Chave
O rascunho dos "Resultados-Chave" (KR em inglês) para cada objetivo finalizado está aqui. Eles correspondem a cada um dos objetivos acima.
As "Hipóteses" subjacentes para cada resultado-chave (KR) serão atualizadas nas páginas wiki do projeto/equipe relevante ao longo do ano, à medida que as lições forem aprendidas.
| Experiências Wiki (WE) rascunho de Resultados-Chave | |||
|---|---|---|---|
| Nome abreviado do Resultado-Chave | Texto do Resultado-Chave | Contexto do Resultado-Chave | Titular |
| WE1.1 | Desenvolver ou aprimorar um fluxo de trabalho que ajude as pessoas que contribuem com interesses comuns a se conectarem e contribuírem juntas. | Acreditamos que os espaços comunitários e as interações nas wikis deixam as pessoas que contribuem mais felizes e mais produtivas. Além disso, os espaços da comunidade ajudam a integrar e orientar pessoas recém-chegadas, modelam as práticas recomendadas de contribuição e ajudam a resolver as lacunas de conhecimento. No entanto, os recursos, as ferramentas e os espaços existentes que apoiam a conexão humana nas wikis são inferiores e não atendem aos desafios e às necessidades da maioria das pessoas editoras atualmente. Enquanto isso, o trabalho da equipe de Campanhas demonstrou que muitas pessoas organizadoras estão ansiosas para adotar e experimentar novas ferramentas com fluxos de trabalho estruturados que as ajudem em seu trabalho comunitário. Por esses motivos, queremos nos concentrar em incentivar e promover um sentimento de pertencimento entre as pessoas que contribuem com as wikis. | Ilana Fried |
| WE1.2 | Ativação construtiva: #% de aumento anual na porcentagem de pessoas recém-chegadas que publicam ≥1 edição construtiva no namespace principal em um dispositivo móvel. |
As experiências atuais de edição de página inteira exigem muito contexto, paciência e tentativa e erro para que muitas pessoas recém-chegadas possam contribuir de forma construtiva. Para dar suporte a uma nova geração de pessoas voluntárias, aumentaremos o número e a disponibilidade de fluxos de trabalho de edição menores, estruturados e mais específicos para cada tarefa (por exemplo, Edit Check e Structured Tasks).
Observação: As linhas de base serão estabelecidas somente no final do quarto trimestre do ano fiscal atual, após o qual nossa porcentagem de métrica da meta de resultado-chave (KR) também será estabelecida. |
Peter Pelberg |
| WE1.3 | Aumentar a satisfação do usuário e da usuária em 4 produtos de moderação em X%. | Pessoas editoras com direitos estendidos fazem uso de uma ampla gama de recursos, extensões, ferramentas e scripts existentes para realizar tarefas de moderação em projetos da Wikimedia. Este ano, queremos nos concentrar em fazer melhorias nessas ferramentas, em vez de realizar projetos para criar novas funcionalidades nesse espaço. Nosso objetivo é trabalhar em vários produtos ao longo do ano e queremos fazer melhorias impactantes em cada um deles. Com isso, esperamos melhorar a experiência de moderação de conteúdo em geral. Definiremos X% após a medição de linhas de base para algumas ferramentas comuns de moderação que poderemos visar com esse fluxo de trabalho. A Pesquisa de desejos comunitários contribuirá substancialmente para a decisão sobre as prioridades desse resultado-chave (KR). We will define baselines for common moderator tools that we may target with this workstream to determine increase in satisfaction per tool. The Community Wishlist will be a substantial contributor to deciding on the priorities for this KR. |
Sam Walton |
| WE2.1 | Até o final do segundo trimestre, apoiar organizadores, pessoas que contribuem e instituições com ferramentas específicas, percepções e abordagens de organização que aumentem em X% a cobertura de conteúdo de qualidade nas principais áreas temáticas (a definir). | Este resultado-chave (KR) trata de melhorar a cobertura de tópicos para reduzir as lacunas de conhecimento existentes. Estabelecemos que as comunidades se beneficiam de ferramentas eficazes aliadas a campanhas destinadas a aumentar a qualidade do conteúdo de nossos projetos. Este ano, queremos nos concentrar no aprimoramento das ferramentas existentes e na experimentação de novas maneiras de priorizar as principais áreas temáticas que abordam as lacunas de conhecimento. Nossa meta de aumento de X% na cobertura será determinada pela análise das linhas de base existentes de criação de conteúdo de qualidade. Além disso, as áreas temáticas nas quais nos concentraremos com as comunidades e instituições serão determinadas no próximo trimestre. Our target 138 articles will be determined by looking at existing baselines of quality content creation. |
Purity Waigi & Fiona Romeo |
| WE2.2 | Até o final do segundo trimestre, implementar e testar duas recomendações, tanto sociais quanto técnicas, para apoiar a integração de idiomas em pequenas comunidades linguísticas, com uma avaliação para analisar o feedback da comunidade. | Há edições da Wikipédia em cerca de 300 idiomas. E, no entanto, há muitos outros idiomas falados por milhões de pessoas, nos quais não há Wikipédia nem Wiki algum. Isso é um obstáculo ao cumprimento de nossa visão: que cada ser humano possa compartilhar livremente a soma de todo o conhecimento. A Incubadora da Wikimedia é o local onde potenciais wikis de projetos da Wikimedia em versões de novos idiomas podem ser organizadas, escritas, testadas e comprovadas como dignas de serem hospedadas pela Wikimedia Foundation. A Incubadora foi lançada em 2006 com a suposição de que seus usuários e suas usuárias teriam conhecimento prévio de edição de wikis. Esse problema é exacerbado pelo fato de que esse processo deve ser realizado principalmente por pessoas que são as mais novas e menos experientes em nosso movimento. Embora a edição nas wikis da Wikimedia tenha melhorado significativamente desde então, a Incubadora não recebeu essas atualizações devido a limitações técnicas. Atualmente, leva várias semanas para que uma wiki seja graduada pela Incubadora e apenas cerca de 12 wikis são criadas a cada ano, demonstrando um congestionamento considerável.
Pesquisas e materiais existentes revelam desafios técnicos em todas as fases da integração de idiomas: adição de novos idiomas à Incubadora, complexidades no desenvolvimento e revisão de conteúdo e processo lento na criação de um site wiki quando um idioma sai da Incubadora. Cada fase é lenta, manual e complexa, indicando a necessidade de aprimoramento. A solução desse problema permitirá a criação de wikis em novos idiomas de forma mais rápida e fácil, além de permitir que mais pessoas compartilhem conhecimento. Várias partes interessadas, pesquisas e recursos existentes destacaram recomendações propostas, tanto sociais quanto técnicas. Esse resultado-chave propõe o teste de duas recomendações, tanto sociais quanto técnicas, e a avaliação do feedback da comunidade. |
Satdeep Gill & Mary Munyoki |
| WE2.3 | Até o final do segundo trimestre, duas novas funcionalidades orientam as pessoas que contribuem a adicionar materiais de origem que estejam em conformidade com as diretrizes do projeto, e de 3 a 5 parceiros contribuíram com materiais de origem que atendem às lacunas de idioma e geografia. | Para aumentar o acesso a materiais de origem de qualidade necessários para preencher as lacunas de conteúdo estratégicas, nós vamos:
|
Fiona Romeo & Alexandra Ugolnikova |
| WE2.4 | Até o final do segundo trimestre, habilitar as chamadas do Wikifunctions em pelo menos uma Wikipédia de idioma menor para fornecer uma maneira mais escalável de propagar novos conteúdos. | Para reduzir nossas lacunas de conhecimento de forma eficaz, precisamos aprimorar os fluxos de trabalho que dão suporte ao crescimento escalonável do conteúdo de qualidade, especialmente em comunidades linguísticas menores. | Amy Tsay |
| WE3.1 | Lançar duas experiências de navegação e aprendizado selecionadas, acessíveis e orientadas pela comunidade para wikis representativas, com o objetivo de aumentar em 5% a retenção de leitura de usuários e usuárias de experiência que não estão logados. | Este resultado-chave (KR) visa aumentar a retenção de uma nova geração de leitores em nosso site, permitindo que uma nova geração crie uma conexão duradoura com a Wikipédia, explorando oportunidades para que os leitores descubram e aprendam mais facilmente com o conteúdo de seu interesse. Isso incluirá explorações e o desenvolvimento de novas experiências de navegação e aprendizado com curadoria, personalizadas e orientadas pela comunidade (por exemplo, feeds de conteúdo relevante, recomendações e sugestões de conteúdo tópico, oportunidades de exploração de conteúdo com curadoria da comunidade etc.).
Planejamos iniciar o ano fiscal com uma série de experimentos de experiências de navegação para determinar quais gostaríamos de dimensionar para uso em produção e em qual plataforma (web, aplicativos ou ambas). Em seguida, focaremos no dimensionamento desses experimentos e no teste de sua eficácia para aumentar a retenção em ambientes de produção. Nossa meta até o final do ano é lançar pelo menos duas experiências em wikis representativas e medir com precisão um aumento de 5% na retenção de leitores envolvidos nessas experiências. Para sermos eficazes na obtenção desse resultado-chave (KR), precisaremos da capacidade de fazer testes A/B com usuários e usuárias desconectados, bem como de instrumentos capazes de medir a retenção de leitores. Talvez também precisemos de novas APIs ou serviços necessários para apresentar recomendações e outros mecanismos de curadoria. |
Olga Vasileva |
| WE3.2 | Aumento de 50% no número de doações por meio de pontos de contato fora dos apelos anuais por banner e e-mail por plataforma. | Nossa meta é oferecer uma diversidade de fontes de receita e, ao mesmo tempo, reconhecer nossos doadores atuais. Com base no feedback e nos dados, nosso foco é aumentar o número de doações além dos métodos com os quais a Fundação contava no passado, especificamente os apelos anuais por banners. Queremos mostrar que, ao investir em experiências mais integradas para os doadores, podemos sustentar nosso trabalho e expandir nosso impacto, oferecendo uma alternativa aos doadores e doadores em potencial que não respondem aos apelos por banners. 50% é uma estimativa inicial baseada na diminuição da visibilidade do botão de doação na Web como resultado do Vetor 2022 e no aumento do número de doações do projeto piloto do ano fiscal de 2023-2024 nos aplicativos da Wikipédia para aprimorar as experiências dos doadores (aumento de 50,1% nas doações). A avaliação dessa métrica por plataforma nos ajudará a entender as tendências nas plataformas e se diferentes táticas devem ser implementadas no futuro com base em uma diferença de comportamento baseada no público da plataforma. | Jazmin Tanner |
| WE3.3 | By the end of Q2 2024-25, volunteers will start converting legacy graphs to the new graph extension on production Wikipedia articles. | The Graph extension has been disabled for security reasons since April 2023, leaving readers unable to view many graphs that community members have invested time and energy into over the last 10 years. Data visualization plays a role in creating engaging encyclopedic content, so in FY 2024-25, we will build a new secure service to replace the Graph extension that will handle the majority of simple data visualization use cases on Wikipedia article pages. This new service will be built in an extensible way to support more sophisticated use cases if WMF or community developers choose to do so in the future. We will know we’ve achieved success when community members are successfully converting legacy graphs and publishing new graphs using the new service. We will determine which underlying data visualization library to use and which graph types to support during the initial phase of the project. |
Christopher Ciufo |
| WE3.4 | Develop the capability model to improve website performance through smaller scale cache site deployments that take one month to implement while maintaining technical capabilities, security and privacy. |
The Traffic team is responsible for maintaining the Content Delivery Network (CDN). This layer caches frequently accessed content, pages, etc, in memory and on disk. This reduces the time it takes to process requests for users. The second bit is storing content closer to the user in a physical sense. That reduces the time it takes for data to reach the user (latency). Last year, we enabled one site in Brazil meant to reduce latency in the Southern American region. Setting up new data centers would be great but it is expensive, time consuming, and requires a lot of work to get done – for example, last year’s work spanned the full year. We would love to have centers in Africa and Southeast Asia, and we would love to have them all around the world. Our hypothesis is to spin up smaller sites in other places around the world where traffic is lower. These would require fewer servers, of not more than four or five servers. This reduces our cost. It would still help us reduce latency for users in these regions, while being more lightweight in terms of time and effort to maintain them. |
Kwaku Ofori |
| WE4.1 | Fornecer uma proposta de 3 contramedidas para assédio e conteúdo nocivo com base em dados e de acordo com o ambiente regulatório em evolução até o terceiro trimestre. | Garantir a segurança e o bem-estar do usuário e da usuária é uma responsabilidade fundamental das plataformas on-line. Muitas jurisdições têm leis e regulamentos que exigem que as plataformas on-line tomem medidas contra assédio, cyberbullying e outros conteúdos prejudiciais. O não cumprimento dessas exigências pode expor as plataformas a responsabilidades legais e sanções regulatórias.
No momento, não temos uma ideia muito boa sobre a dimensão desses problemas ou os motivos por trás deles. Dependemos muito de evidências anedóticas e de processos manuais, o que nos deixa expostos a riscos legais e a outras consequências de longo alcance: subestimação do problema, aumento dos danos, danos à reputação e erosão da confiança do usuário e da usuária. Precisamos criar uma cultura sólida de medição da incidência de assédio e conteúdo nocivo e implementar contramedidas de forma proativa. |
Madalina Ana |
| WE4.2 | Desenvolver pelo menos dois sinais para uso em fluxos de trabalho antiabuso para melhorar a precisão das ações contra malfeitores até o terceiro trimestre. | As wikis dependem muito do bloqueio de IP como um mecanismo para bloquear vandalismo, spam e abuso. Mas os endereços de IP são cada vez menos úteis como identificadores estáveis de um indivíduo, e o bloqueio de endereços de IP tem efeitos negativos não intencionais sobre usuários e usuárias de boa-fé que compartilham o mesmo endereço de IP com malfeitores. A combinação da estabilidade decrescente dos endereços de IP e nossa forte dependência no bloqueio de IP resulta em menos precisão e eficácia no direcionamento de malfeitores, além de níveis crescentes de danos colaterais para usuários e usuárias de boa-fé. Queremos ver a situação oposta: níveis reduzidos de danos colaterais e maior precisão nas mitigações direcionadas aos malfeitores.
Para dar melhor suporte ao trabalho antiabuso dos funcionários e fornecer blocos de construção para reutilização em ferramentas existentes (por exemplo, CheckUser, Special:Block) e novas, neste resultado-chave (KR) propomos explorar maneiras de associar de forma confiável um indivíduo às suas ações (mitigação de sockpuppetting) e combinar sinais existentes (por exemplo, endereços de IP, histórico de contas, atributos de solicitação) para permitir um direcionamento mais preciso das ações contra os malfeitores. |
Kosta Harlan |
| WE4.3 | Reduzir a eficácia de um ataque distribuído em grande escala em 50%, conforme medido pelo tempo que levamos para adaptar nossas medidas e pelo volume de tráfego que podemos sustentar em uma simulação. | 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 grande escala. Esses ataques podem tornar nossos sites inacessíveis, inundando 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 nossos editores e editoras com privilégios de alto nível e nossa comunidade técnica.
Precisamos urgentemente melhorar nossa capacidade de detectar, resistir e atenuar ou interromper automaticamente esses ataques. Para medir nossos aprimoramentos, não podemos confiar apenas na frequência/intensidade dos ataques reais, pois dependeríamos de ações externas e seria difícil obter um quadro quantitativo claro do nosso progresso. Ao configurar vários ataques simulados de natureza/complexidade/duração variada para serem executados com segurança contra a nossa infraestrutura e executá-los a cada trimestre, poderemos testar nossas novas contramedidas enquanto não estivermos sob ataque e relatar objetivamente nossos aprimoramentos. |
Giuseppe Lavagetto |
| WE4.4 | Launch temp accounts to 100% of all wikis. | Temporary accounts are a solution for complying with various regulatory requirements around the exposure of IPs on our platform on various surfaces. This work involves updating many products, data pipelines, functionary tools, and various volunteer workflows to cope with the existence of an additional type of account. | Madalina Ana |
| WE5.1 | Até o terceiro trimestre, concluir pelo menos cinco intervenções destinadas a aumentar a sustentabilidade da plataforma. | A sustentabilidade da plataforma MediaWiki é um esforço constante e importante para nossa capacidade de escalonar, aumentar ou evitar a degradação da satisfação do desenvolvedor e aumentar nossa comunidade técnica. Isso é difícil de medir e depende de fatores técnicos e sociais. No entanto, temos conhecimento tácito sobre áreas específicas de melhorias que são estratégicas para a sustentabilidade. As intervenções planejadas podem ajudar a aumentar a sustentabilidade e a capacidade de manutenção da plataforma ou evitar sua degradação. Planejamos avaliar o impacto desse trabalho no quarto trimestre com recomendações para as metas de sustentabilidade no futuro. Exemplos de intervenções de sustentabilidade são: simplificar domínios de código complexos que são essenciais para o MediaWiki, mas que apenas algumas pessoas sabem como funcionam; aumentar o uso de ferramentas de análise de código para informar a qualidade de nossa base de código; simplificar processos como packaging e lançamentos. | Mateus Santos |
| WE5.2 | Identificar até o segundo trimestre e concluir até o quarto trimestre uma ou mais intervenções para desenvolver as interfaces de programação do ecossistema do MediaWiki, a fim de possibilitar o desenvolvimento de funcionalidades desacopladas, mais simples e mais sustentáveis. | O principal objetivo do resultado-chave (KR) 5.2 é melhorar e esclarecer a interação entre a plataforma central do MediaWiki e suas extensões, skins e outras partes. Nossa intenção é fornecer melhorias funcionais à arquitetura do MediaWiki que possibilitem modularidade e facilidade de manutenção práticas, para as quais seja mais fácil desenvolver extensões, e capacitar os requisitos da visão mais ampla do produto MediaWiki. Esse trabalho também tem o objetivo de informar o que deve existir (ou não) na estrutura principal, nas extensões ou nas interfaces entre elas. O ano será dividido em duas fases: uma fase de pesquisa e experimentação de 5 meses que informará a segunda fase, na qual intervenções específicas serão implementadas. | Jonathan Tweed |
| WE5.3 | Até o final do segundo trimestre, concluir uma iniciativa de coleta de dados e um experimento de melhoria de desempenho para informar o produto de acompanhamento e as intervenções da plataforma para aproveitar as capacidades desbloqueadas pela modelagem do MediaWiki de uma página como uma composição de fragmentos estruturados. | O principal objetivo aqui é empoderar os desenvolvedores e gerentes de produtos a aproveitar os novos recursos da plataforma MediaWiki para atender às necessidades atuais e futuras do conteúdo enciclopédico, possibilitando novas ofertas de produtos que atualmente são difíceis de implementar, bem como melhorar o desempenho e a resiliência da plataforma.
Especificamente, ao nível da plataforma MediaWiki, queremos mudar o modelo de processamento do MediaWiki, deixando de tratar uma página como uma unidade monolítica para tratar uma página como uma composição de unidades de conteúdo estruturado. As visualizações de leitura baseadas no Parsoid, a integração do Wikidata e a integração do Wikifunctions nas wikis são todos passos implícitos em direção a isso. Como parte desse resultado-chave (KR), queremos experimentar e coletar dados de forma mais intencional para informar futuras intervenções com base nessas novas capacidades, a fim de garantir que possamos alcançar os impactos pretendidos na infraestrutura e no produto. |
Subramanya Sastry |
| WE5.4 | By the end of Q2, execute the 1.43 LTS release with a new MW release process that synchronizes with PHP upgrades. | The MediaWiki software platform relies on regular updates to the next PHP version to remain secure and sustainable, which is a pain point in our process and important for the modernization of our infrastructure. At the same time, we regularly release new versions of the MediaWiki software, which e.g. translatewiki.net depends on, the platform used to translate software messages for the Wikimedia projects and many other open source projects. There’s an opportunity to improve the MediaWiki release process, including technical documentation and synchronization with PHP upgrades in alignment with the MediaWiki product strategy before the next release, which will be a long term support version (LTS). This work is part of our strategic investment in the sustainability of the MediaWiki platform (see also: 5.1) and aims to improve developer experience and infrastructure management. |
Mateus Santos |
| WE6.1 | Resolver 5 questões para permitir eficiência e decisões informadas sobre fluxos de trabalho e serviços de desenvolvimento e engenharia e tornar os dados relevantes acessíveis até o final do quarto trimestre. | "É complicado" é uma resposta frequente a perguntas como "quais repositórios são implantados na produção da Wikimedia". Neste resultado-chave (KR), exploraremos algumas de nossos "perenes" no campo de produtividade e experiência de engenharia - perguntas recorrentes que parecem fáceis, mas são difíceis de responder, perguntas às quais podemos responder, mas cujos dados não estão acessíveis e que exigem consultas personalizadas por especialistas no assunto, ou perguntas cuja resposta é complicada por causa de lacunas no processo ou por outros motivos. Vamos definir o que significa "resolver" para cada uma das perguntas: para algumas, isso pode significar apenas tornar acessíveis os dados existentes e precisos. Outras perguntas exigirão mais tempo de pesquisa e engenharia para serem resolvidas. O objetivo geral deste trabalho é reduzir o tempo, as soluções alternativas e o esforço necessários para obter insights sobre os principais aspectos da experiência do desenvolvedor e nos permitir aprimorar os fluxos de trabalho e os serviços de engenharia e de desenvolvimento. | [TBD] |
| WE6.2 | No quarto trimestre, aperfeiçoar um projeto existente e realizar pelo menos dois experimentos com o objetivo de fornecer ambientes direcionados e passíveis de manutenção que nos levem a uma entrega segura e semicontínua. | Pessoas desenvolvedoras e usuárias dependem do Wikimedia Beta Cluster (beta) para detectar erros antes que eles afetem os usuários e as usuárias na produção. Com o tempo, os usos do beta cresceram e entraram em conflito - os usos são muito diversos para caber em um único ambiente. Aperfeiçoaremos um ambiente alternativo existente e realizaremos experimentos com o objetivo de substituir uma única necessidade de teste de alta prioridade atualmente atendida pelo beta por um ambiente alternativo de fácil manutenção que atenda melhor às necessidades de cada caso de uso. | Tyler Cipriani |
| WE6.3 | Develop a Toolforge sustainability scoring framework by Q3. Apply it to improve at least one critical platform aspect by Q4 and inform longer-term strategy. | Toolforge, a principal plataforma para as ferramentas criadas por voluntários da Wikimedia, desempenha um papel crucial, desde a edição até o antivandalismo. Nosso objetivo é aperfeiçoar a usabilidade do Toolforge, reduzir as barreiras à contribuição, melhorar as práticas da comunidade e promover a adesão às políticas estabelecidas. Para isso, apresentaremos um sistema de pontuação até o segundo trimestre para avaliar a sustentabilidade da plataforma Toolforge, com foco nos aspectos técnicos e sociais. Usando esse sistema como guia, nosso objetivo é melhorar um dos principais fatores técnicos em 50%. | Slavina Stefanova |
| Sinais e serviços de dados (SDS) Rascunho dos Resultados-chave | |||
|---|---|---|---|
| Nome abreviado do Resultado-Chave | Texto do Resultado-Chave | Contexto do Resultado-Chave | Titular |
| SDS1.1 | Os líderes de 2 programas ou iniciativas orientadas por resultado-chave (KR) produziram documentação amplamente compartilhada explicando a ligação lógica entre o trabalho de sua equipe e o impacto em uma ou mais métricas essenciais da Fundação. | Nossas principais métricas organizacionais servem como base para avaliar o progresso da Fundação em direção às suas metas. À medida que alocamos recursos para programas e projetamos fluxos de trabalho direcionados a resultados-chave (KR), essas métricas devem orientar a forma como vinculamos esses investimentos às metas abrangentes da Fundação, conforme definido no plano anual. O trabalho nesse resultado-chave reconhece que a Fundação, como um todo, está em um estágio inicial de sua capacidade de vincular quantitativamente os impactos de todas as intervenções planejadas a métricas centrais ou de alto nível. Em busca desse objetivo final, este resultado-chave (KR) pretende desenvolver o processo pelo qual compartilhamos as ligações lógicas e teóricas entre nossas iniciativas e nossas métricas de alto nível. Na prática, isso significa estabelecer parcerias com os titulares das iniciativas em toda a Fundação para entender como o resultado de seu trabalho no nível do projeto está vinculado às nossas métricas principais no nível da Fundação e as impacta. Estruturas e exercícios de mapeamento de impacto, como o "mapeamento da teoria da mudança" e a construção de gráficos causais, serão empregados para garantir a consistência e o rigor na documentação do impacto potencial do trabalho. Para executar esse resultado fundamental, também precisaremos desenvolver materiais de apoio que ajudem os titulares das iniciativas a entender as métricas organizacionais e a construir teorias de mudança associadas ao seu trabalho. |
Omari Sefu |
| SDS1.2 | Responder a 2 perguntas estratégicas de pesquisa abertas até dezembro de 2024 para fornecer recomendações ou informar o planejamento anual do ano fiscal de 2026. | Há muitas questões de pesquisa em aberto no ecossistema Wikimedia, e responder a algumas dessas questões é estratégico para a WMF ou para os afiliados. As respostas a essas perguntas podem informar o desenvolvimento futuro de produtos ou tecnologias ou podem apoiar a tomada de decisões/defesa no espaço político. Embora algumas dessas perguntas possam ser respondidas com a utilização de conhecimentos puramente de pesquisa ou de engenharia de pesquisa, dada a natureza sociotécnica dos projetos da WM, chegar a insights confiáveis geralmente requer a colaboração de várias equipes para a coleta de dados, a criação de contexto, a interação com o usuário e a usuária, o design cuidadoso de experimentos e muito mais. Com este resultado-chave (KR), pretendemos priorizar alguns de nossos recursos para responder a uma ou mais dessas perguntas.
O trabalho nesse resultado-chave (KR) inclui a priorização de uma lista de perguntas estratégicas abertas, bem como a realização de trabalho experimental para encontrar uma resposta para um número X (atualmente estimado em 2) delas. O tipo ideal de perguntas que abordamos neste resultado-chave (KR) são perguntas que, uma vez respondidas, podem ter um efeito de desbloqueio, permitindo que várias outras equipes ou grupos façam um trabalho (melhor? informado) sobre produtos, tecnologias ou políticas. Pretendemos que o trabalho neste resultado-chave (KR) seja complementar aos seguintes resultados-chave (KRs):
|
Leila Zia |
| SDS1.3 | Obter uma redução de pelo menos 50% no tempo médio necessário para que as partes interessadas em dados compreendam e rastreiem os fluxos de dados para três métricas essenciais e fundamentais | Padrões necessários para a governança de dados.
Rastrear a transformação e a origem dos conjuntos de dados é difícil e requer conhecimento de diferentes repositórios e sistemas. Devemos facilitar a compreensão de como os dados fluem em nossos sistemas para que as partes interessadas nos dados possam trabalhar de uma forma mais autônoma. Esse trabalho dará suporte a fluxos de trabalho em que os dados são transformados e usados para análises, recursos, APIs e trabalhos de qualidade de dados. Haverá um resultado-chave (KR) sobre a documentação de métricas. |
Luke Bowmaker |
| SDS2.1 | Até o final do segundo trimestre, podemos dar suporte a uma equipe de produtos para avaliar uma funcionalidade ou um produto por meio de testes A/B básicos que reduzam em 50% o tempo de obtenção de dados de interação com o usuário ou a usuária. | Acreditamos que o uso de ferramentas compartilhadas aumentará a confiança das equipes de produtos na tomada de decisões orientadas por dados, melhorará a eficiência e a produtividade e aperfeiçoará a estratégia e a inovação de produtos. Analisaremos a adoção de linhas de base de dados de tempo individual da equipe para interação com o usuário e a usuária e a melhoraremos em 50%. Também investigaremos como podemos contextualizar esses ganhos no contexto mais completo de todas as equipes de produtos. Esperamos aprender como podemos melhorar a experiência e identificar e priorizar os aprimoramentos de recursos com base no feedback da equipe de adoção e nos resultados do SDS2.2. |
Virginia Poundstone |
| SDS2.2 | Até o final do segundo trimestre, teremos duas métricas essenciais para analisar experimentos (testes A/B) para apoiar o teste de hipóteses de produtos/funcionalidades relacionadas aos resultados-chave (KRs) do ano fiscal de 24-25. | Quando um gerente de produto (ou designer) tem uma hipótese de que um produto/funcionalidade abordará um problema/necessidade dos usuários e usuárias ou da organização, um experimento é a forma de testar essa hipótese e aprender sobre o possível impacto de sua ideia em uma métrica. Os resultados do experimento informam o gerente de produto e o ajudam a tomar uma decisão sobre qual ação tomar em seguida (abandonar essa ideia e tentar uma hipótese diferente, continuar o desenvolvimento se o experimento tiver sido realizado no início do ciclo de vida do desenvolvimento ou liberar o produto/ recurso para mais usuários e usuárias). Os gerentes de produto devem ser capazes de tomar essa decisão com confiança, apoiados por evidências que eles confiam e entendem.
Um grande obstáculo para isso é que, atualmente, as equipes de produtos formulam suas hipóteses com métricas personalizadas específicas do projeto, que exigem suporte de analistas dedicados para definir, medir, analisar e gerar relatórios sobre elas. Mudar para um conjunto de métricas essenciais para formular todas as declarações de hipóteses testáveis de produtos/funcionalidades tornaria isso:
Acreditamos que um conjunto de métricas essenciais que sejam amplamente compreendidas e usadas de forma consistente - e informadas/influenciadas por métricas padrão do setor - também melhoraria a alfabetização de dados organizacionais e promoveria uma cultura de revisão, experimentação e aprendizado. Estamos nos concentrando em métricas essenciais que (1) são necessárias para a melhor medição e avaliação do sucesso/impacto de produtos/funcionalidades relacionados a 2 resultados-chave (KRs) de Experiências Wiki - WE3.1 e WE1.2 - e (2) refletem ou mapeiam as métricas padrão do setor usadas na análise da web. |
Mikhail Popov |
| SDS2.3 | Deploy a unique agent tracking mechanism to our CDN which enables the A/B testing of product features with anonymous readers. | Without such a tracking mechanism, it is not reasonable to implement A/B testing of product features with anonymous readers.
This is basically a milestone-based result to create a new technical capability that others can build measurable things on top of. The key priority use-case will be A/B testing of features with anonymous readers, but this work also enables other important future things, which may create follow-on hypotheses later in WE4.x (for request risk ratings and mitigating large-scale attacks) and for metrics/research about unique device counts as their resourcing and priorities allow. |
Brandon Black |
| Público Futuro (FA) Rascunho do Resultado-chave | |||
|---|---|---|---|
| Nome abreviado do Resultado-Chave | Texto do Resultado-Chave | Contexto do Resultado-Chave | Titular |
| FA1.1 | Como resultado das percepções e recomendações experimentais do Público Futuro, até o final do terceiro trimestre, pelo menos um objetivo ou resultado-chave pertencente a uma equipe que não seja do Público Futuro está presente no rascunho do plano anual do ano seguinte. | Desde 2020, a Wikimedia Foundation vem rastreando tendências externas que podem afetar nossa capacidade de atender às futuras gerações de pessoas que consomem e contribuem com o conhecimento e continuar sendo um próspero movimento de conhecimento livre para as próximas gerações. Público Futuro, uma pequena equipe de P&D, irá:
|
Maryana Pinchuk |
| Suporte de produto e engenharia (PES) Rascunho de Resultado-chave | |||
|---|---|---|---|
| Nome abreviado do Resultado-Chave | Texto do Resultado-Chave | Contexto do Resultado-Chave | Titular |
| PES1.1 | Cultura de avaliação: melhorar cada vez mais as pontuações do sentimento da equipe de P+T em relação à nossa entrega, alinhamento, direção e saúde da equipe em uma pesquisa trimestral. | Uma cultura de avaliação é uma cultura de desenvolvimento de produtos baseada em ciclos mais curtos de iteração, aprendizado e adaptação. Isso significa que nossa organização pode definir metas anuais, mas o que fazemos para atingi-las mudará e se adaptará ao longo do ano à medida que aprendermos. Há dois componentes para a criação de uma cultura de avaliação: processos e comportamentos. Este resultado-chave (KR) se concentra no último. As mudanças de comportamento podem aumentar e fortalecer nossa cultura de avaliação. Isso envolve mudanças nos hábitos e rotinas individuais à medida que avançamos em direção a um desenvolvimento de produtos mais iterativo. Este resultado-chave (KR) será baseado em mudanças autorrelatadas em comportamentos individuais e na medição das mudanças resultantes, se houver, no sentimento da equipe. | Amy Tsay |
| PES1.2 | Até o final do segundo trimestre, a nova lista de desejos conecta melhor as ideias e solicitações do movimento às atividades de P+T da Fundação: os itens da lista de desejos em atraso são abordados por meio de um resultado-chave (KR) 2024-25, a Fundação concluiu 10 desejos menores e fez parceria com pessoas voluntários para identificar mais de 3 áreas de oportunidade para o ano fiscal de 2025-26. | A lista de Desejos Comunitários representa uma pequena parcela do movimento; aproximadamente 1.000 pessoas participam, a maioria das quais são pessoas que contribuem ou são administradores e administradoras. As pessoas geralmente ignoram a lista de desejos, solicitando funcionalidades e relatando bugs por meio do Phabricator, onde é difícil discernir as solicitações da WMF ou da comunidade. Para as pessoas que participam, a lista de desejos é um investimento de tempo caro com retorno mínimo. Mesmo assim, elas continuam engajadas na lista de desejos porque acham que é o único veículo para chamar a atenção para bugs e melhorias de funcionalidades impactantes, ou para sinalizar a necessidade de oportunidades estratégicas mais amplas. Os desejos geralmente são escritos como soluções, em vez de problemas. As soluções podem parecer sensatas no papel, mas não levam necessariamente em consideração a complexidade técnica ou as implicações da estratégia de movimento.
O escopo e a amplitude dos desejos às vezes excedem o escopo e a capacidade da Comunidade Técnica ou de uma única equipe, perpetuando a frustração, levando a Pedidos para comentar e a pedidos para desmantelar a lista de Desejos. Enquanto os membros da comunidade preferem usar a lista de Desejos para ter ideias de projetos, as equipes da Fundação analisam a lista de Desejos e outros processos de admissão para priorização, em parte porque os desejos são inadequados para o Planejamento Anual e são difíceis de incorporar aos roteiros/objetivos e resultados-chave (OKRs). A Futura lista de Desejos deve ser uma ponte entre a comunidade e a Fundação, onde as comunidades fornecem informações de forma estruturada para que possamos agir e, por sua vez, deixar as pessoas voluntárias felizes. Estamos criando um novo processo de entrada para que qualquer pessoa voluntária conectada possa enviar um desejo, 365 dias por ano. Os desejos podem relatar ou destacar um bug, solicitar uma melhoria ou idealizar uma nova funcionalidade. Qualquer pessoa pode comentar, trabalhar ou apoiar um desejo para influenciar a priorização. A Fundação não categorizará os desejos como "grandes demais" ou "pequenos demais". Os desejos que mapeiam tematicamente uma área problemática maior podem influenciar o planejamento anual e os roteiros da equipe, oferecendo orientações e oportunidades estratégicas. Os desejos ficarão visíveis para o Movimento em um painel que categoriza os desejos por projeto, produto/área de problema e tipo de desejo. A Fundação responderá aos desejos em tempo hábil e fará parceria com a Comunidade para categorizar e priorizar os desejos. Faremos parceria com os wikimedistas para identificar e priorizar três áreas de aprimoramento, incorporadas ao Plano Anual 2025-26 da Fundação, o que deverá melhorar a taxa de adoção e a realização de desejos impactantes. Sinalizaremos os desejos bem planejados para a comunidade de pessoas desenvolvedoras voluntárias e para as equipes da Fundação, o que resultará em mais envolvimento da equipe e das pessoas desenvolvedoras e em mais desejos atendidos, o que levará à satisfação da comunidade. Atender a mais desejos melhora a felicidade, a eficácia e a retenção das pessoas colaboradores, o que deve gerar mais edições de qualidade, conteúdo de maior qualidade e mais leitores e leitoras. |
Jack Wheeler |
| PES1.3 | Executar e concluir dois experimentos a partir de produtos/funcionalidades exploratórios existentes que nos forneçam dados/insights sobre como aumentar a Wikipédia como um destino de conhecimento para nossos públicos atuais de pessoas consumidoras e voluntárias no primeiro e segundo trimestres. Concluir e compartilhar os aprendizados e as recomendações para possível adoção em trabalhos futuros de objetivos e resultados-chave (OKR) no setor de Experiências Wiki até o final do terceiro trimestre. | Esse trabalho é uma contrapartida ao objetivo de Público Futuro, mas se concentra em descobrir oportunidades para aumentar e aprofundar o envolvimento de nossos públicos existentes (de pessoas que consomem e contribuem com a Wikipédia) por meio de testes mais ágeis de mais ideias de produtos na plataforma.
Está presente no PES1, pois é um energizador e multiplicador, canalizando o tempo que os indivíduos e as equipes "já" dedicaram ao hacking/experimento em projetos paralelos para colocar em foco funcionalidades mais promissoras. Em vez de esses projetos paralelos ficarem parados (o que não é um bom uso de nossos recursos limitados), esse resultado-chave (KR) oferece um caminho para que algumas dessas ideias possam ser incorporadas a uma configuração de APP maior por meio de experimentos comprovados, usando assim o tempo da equipe de forma mais eficiente e motivando sua criatividade e produtividade. Ao colocar em prática mais desses projetos menores e mais curtos, também diversificamos nossa gama de "apostas" para obter mais aprendizados e testes de ideias que podem transformar a Wikipédia de acordo com as necessidades e expectativas em constante mudança de nossos públicos atuais. Isso tornará nosso trabalho mais impactante e rápido, pois ajudará a fundação a se alinhar com o objetivo correto em menos tempo. |
Rita Ho |
| PES1.4 | Aprender como: definir, monitorar e tomar decisões sobre SLOs. Escolher pelo menos uma coisa nova para definir SLOs à medida que a lançarmos. Colaborar com a(s) respectiva(s) equipe(s) (normalmente: produto, equipes de desenvolvimento, SRE) para definir esse SLO. Refletir e documentar diretrizes para quais versões devem ter SLOs no futuro e como defini-los. | FUTURO RESULTADO-CHAVE (KR):
Configurar o processo e as ferramentas rudimentares para definir e monitorar SLOs para novas versões. Elaborar relatórios trimestrais e usá-los para tomar decisões sobre quando priorizar (e não priorizar) o trabalho para corrigir algo. Compartilhar o relatório com a comunidade. POR QUÊ? Não sabemos quando precisamos priorizar o trabalho para corrigir algo. E temos muito código. Como essa pegada continua a crescer, há mais situações em que talvez precisemos decidir entre resolver problemas ou focar na inovação, e mais incertezas sobre quando devemos fazê-lo. Além disso, não está claro para a equipe e para a comunidade qual é o nosso nível de suporte/compromisso com a confiabilidade e o desempenho de todas as funcionalidades e de todos os diferentes recursos com os quais eles interagem. Se definirmos um nível de serviço esperado, poderemos saber quando devemos ou não alocar recursos para ele. |
Mark Bergsma |
| PES1.5 | Define ownership and commitments (including SLOs) on services and learn how to track, report and make decisions as a standard and scalable practice by trialing it in 3 teams across senior leaders in the department. | After collaboratively defining an SLO for the EditCheck feature as part of PES1.5, we will now trial and learn from using the SLO in practice to help prioritisation of reliability work. We will also document roles and responsibilities for ownership of code/services, allowing us to make clear shared commitments on the level of ongoing support. We will try to use these as practices in 3 teams across the department. | Mark Bergsma |
Hypotheses
The hypotheses below are the specific things we are doing each quarter to address the associated key results above.
Each hypothesis is an experiment or stage in an experiment we believe will help achieve the key result. Teams make a hypothesis, test it, then iterate on their findings or develop an entirely different new hypothesis. You can think of the hypotheses as bets of the teams’ time–teams make a small bet of a few weeks or a big bet of several months, but the risk-adjusted reward should be commensurate with the time the team puts in. Our hypotheses are meant to be agile and adapt quickly. We may retire, adjust, or start a hypothesis at any point in the quarter.
To see the most up-to-date status of a hypothesis and/or to discuss a hypothesis with the team please click the link to its project page below.
Q1
The first quarter (Q1) of the WMF annual plan covers July-September.
| Wiki Experiences (WE) Hypotheses
[ WE Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| WE1.1.1 | If we expand the Event List to become a Community List that includes WikiProjects, then we will be able to gather some early learnings in how to engage with WikiProjects for product development. | |
| WE1.1.2 | If we identify at least 15 WikiProjects in 3 separate Wikipedias to be featured in the Community List, then we will be able to advise Campaigns Product in the key characteristics needed to build an MVP of the Community List that includes WikiProjects. | |
| WE1.1.3 | If we consult 20 event organizers and 20 WikiProject organizers on the best use of topics available via LiftWing, then we can prioritize revisions to the topic model that will improve topical connections between events and WikiProjects. | |
| WE1.2.1 | If we build a first version of the Edit Check API, and use it to introduce a new Check, we can evaluate the speed and ease with other teams and volunteers could use the API to create new Checks and Suggested Edits. | |
| WE1.2.2 | If we build a library of UI components and visual artefacts, Edit Check’s user experience can extend to accommodate Structured Tasks patterns. | |
| WE1.2.3 | If we conduct user tests on two or more design prototypes introducing structured tasks to newcomers within/proximate to the Visual Editor, then we can quickly learn which designs will work best for new editors, while also enabling engineers to assess technical feasibility and estimate effort for each approach. | mw:Growth/Constructive activation experimentation |
| WE1.2.4 | If we train an LLM on detecting "peacock" behavior, then we can learn if it can detect this policy violation with at least >70% precision and >50% recall and ultimately, decide if said LLM is effective enough to power a new Edit Check and/or Suggested Edit. | |
| WE1.2.5 | If we conduct an A/B/C test with the alt-text suggested edits prototype in the production version of the iOS app we can learn if adding alt-text to images is a task newcomers are successful with and ultimately, decide if it's impactful enough to implement as a suggested edit on the Web and/or in the Apps. | mw:Wikimedia Apps/iOS Suggested edits project/Alt Text Experiment |
| WE1.3.1 | If we enable additional customisation of Automoderator's behaviour and make changes based on pilot project feedback in Q1, more moderators will be satisfied with its feature set and reliability, and will opt to use it on their Wikimedia project, thereby increasing adoption of the product. | mw:Automoderator |
| WE1.3.2 | If we are able interpret subsets of wishes as moderator-related focus areas and share these focus areas for community input in Q1-Q2, then we will have a high degree of confidence that our selected focus area will improve moderator satisfaction, when it is released in Q3. | |
| WE2.1.1 | If we build a country-level inference model for Wikipedia articles, we will be able to filter lists of articles to those about a specific region with >70% precision and >50% recall. | m:Research:Language-Agnostic Topic Classification/Countries |
| WE2.1.2 | If we build a proof-of-concept providing translation suggestions that are based on user-selected topic areas, we will be set up to successfully test whether translators will find more opportunities to translate in their areas of interest and contribute more compared to the generic suggestions currently available. | mw: Translation suggestions: Topic-based & Community-defined lists |
| WE2.1.3 | If we offer list-making as a service, we’ll enable at least 5 communities to make more targeted contributions in their topic areas as measured by (1) change in standard quality coverage of relevant topics on the relevant wiki and (2) a brief survey of organizer satisfaction with topic area coverage on-wiki. | |
| WE2.1.4 | If we developed a proof of concept that adds translation tasks sourced from WikiProjects and other list-building initiatives, and present them as suggestions within the CX mobile workflow, then more editors would discover and translate articles focused on topical gaps. By introducing an option that allows editors to select translation suggestions based on topical lists, we would test whether this approach increases the content coverage in our projects. | mw: Translation suggestions: Topic-based & Community-defined lists |
| WE2.2.1 | If we expand Wikimedia's State of Languages data by securing data sharing agreements with UNESCO and Ethnologue, at least one partner will decide to represent Wikimedia’s language inclusion progress in their own data products and communications. On top of being useful to our partner institutions, our expanded dataset will provide important contextual information for decision-making and provide communities with information needed to identify areas for intervention. | |
| WE2.2.2 | If we map the language documentation activities that Wikimedians have conducted in the last 2 years, we will develop a data-informed baseline for community experiences in onboarding new languages. | |
| WE2.2.3 | If we provide production wiki access to 5 new languages, with or without Incubator, we will learn whether access to a full-fledged wiki with modern features such as those available on English Wikipedia (including ContentTranslation and Wikidata support, advanced editing and search results) aids in faster editing. Ultimately, this will inform us if this approach can be a viable direction for language onboarding for new or existing languages, justifying further investigation. | mw:Future of Language Incubation |
| WE2.3.1 | If we make two further improvements to media upload flow on Commons and share them with community, the feedback will be positive and it will help uploaders make less bad uploads (with the focus on copyright) as measured by the ratio of deletion requests within 30 days of upload. This will include defining designs for further UX improvements to the release rights step in the Upload Wizard on Commons and rolling out an MVP of logo detection in the upload flow. | |
| WE2.4.1 | If we build a prototype of Wikifunctions calls embedded within MediaWiki content, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2. | phab:T261472 |
| WE2.4.2 | If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2 (see hypothesis 1). | phab:T363391 |
| WE2.4.3 | If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful. | phab:T282926 |
| WE3.1.1 | Designing and qualitatively evaluating three proofs of concept focused on building curated, personalized, and community-driven browsing and learning experiences will allow us to estimate the potential for increased reader retention (experiment 1: providing recommended content in search and article contexts, experiment 2: summarizing and simplifying article content, experiment 3: making multitasking easier on wikis. | |
| WE3.1.3 | If we develop models for remixing content such as a content simplification or summarization that can be hosted and served via our infrastructure (e.g. LiftWing), we will establish the technical direction for work focused on increasing reader retention through new content discovery features. | |
| WE3.1.4 | If we analyze the projected performance impact of hypothesis WE3.1.1 and WE3.1.2 on the Search API, we can scope and address performance and scalability issues before they negatively affect our users. | |
| WE3.1.5 | If we enhance the search field in the Android app to recommend personalized content based on a user's interest and display better results, we will learn if this improves user engagement by observing whether it increases the impression and click-through rate (CTR) of search results by 5% in the experimental group compared to the control group over a 30-day A/B test. This improvement could potentially lead to a 1% increase in the retention of logged out users. | |
| WE3.2.1 | If we create a clickable design prototype that demonstrates the concept of a badge representing donors championing article(s) of interest, we can learn if there would be community acceptance for a production version of this method for fundraising in the Apps. | Fundraising Experiment in the iOS App |
| WE3.2.2 | Increasing the prominence of entry points to donations on the logged-out experiences of the web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% Year over Year | phab:T368765 |
| WE3.2.3 | If we make the “Donate” button in the iOS App more prominent by making it one click or less away from the main navigation screen, we will learn if discoverability was a barrier to non banner donations. | |
| WE3.3.1 | If we select a data visualization library and get an initial version of a new server-rendered graph service available by the end of July, we can learn from volunteers at Wikimania whether we’re working towards a solution that they would use to replace legacy graphs. | |
| WE4.1.1 | If we implement a way in which users can report potential instances of harassment and harmful content present in discussions through an incident reporting system, we will be able to gather data around the number and type of incidents being reported and therefore have a better understanding of the landscape and the actions we need to take. | |
| WE4.2.1 | If we explore and define Wikimedia-specific methods for a unique device identification model, we will be able to define the collection and storage mechanisms that we can later implement in our anti-abuse workflows to enable more targeted blocking of bad actors. | phab:T368388 |
| WE4.2.9 | If we provide contextual information about reputation associated with an IP that is about to be blocked, we will see fewer collateral damage IP and IP range blocks, because administrators will have more insight into potential collateral damage effects of a block. We can measure this by instrumenting Special:Block and observing how behavior changes when additional information is present, vs when it is not. | WE4.2.9 Talk page |
| WE4.2.2 | If we define an algorithm for calculating a user account reputation score for use in anti-abuse workflows, we will prepare the groundwork for engineering efforts that use this score as an additional signal for administrators targeting bad actors on our platform. We will know the hypothesis is successful if the algorithm for calculating a score maps with X% precision to categories of existing accounts, e.g. a "low" score should apply to X% of permanently blocked accounts | WE4.2.2 Talk page |
| WE4.2.3 | If we build an evaluation framework using publicly available technologies similar to the ones used in previous attacks we will learn more about the efficacy of our current CAPTCHA at blocking attacks and could recommend a CAPTCHA replacement that brings a measurable improvement in terms of the attack rate achievable for a given time and financial cost. | |
| WE4.3.1 | If we apply some machine learning and data analysis tools to webrequest logs during known attacks, we'll be able to identify abusive IP addresses with at least >80% precision sending largely malicious traffic that we can then ratelimit at the edge, improving reliability for our users. | phab:T368389 |
| WE4.3.2 | If we limit the load that known IP addresses of persistent attackers can place on our infrastructure, we'll reduce the number of impactful cachebusting attacks by 20%, improving reliability for our users. | |
| WE4.3.3 | If we deploy a proof of concept of the 'Liberica' load balancer, we will measure a 33% improvement in our capacity to handle TCP SYN floods. | |
| WE4.3.4 | If we make usability improvements and also perform some training exercises on our 'requestctl' tool, then SREs will report higher confidence in using the tool. | phab:T369480 |
| WE4.4.1 | If we run at least 2 deployment cycles of Temp Accounts we will be able to verify this works successfully. | |
| WE5.1.1 | If we successfully roll out Parsoid Read Views to all Wikivoyages by Q1, this will boost our confidence in extending Parsoid Read Views to all Wikipedias. We will measure the success of this rollout through detailed evaluations using the Confidence Framework reports, with a particular focus on Visual Diff reports and the metrics related to performance and usability. Additionally, we will assess the reduction in the list of potential blockers, ensuring that critical issues are addressed prior to wider deployment. | |
| WE5.1.2 | If we disable unused Graphite metrics, target migrating metrics using the db-prefixed data factory and increase our outreach efforts to other teams and the community in Q1, then we would be on track to achieve our goal of making Graphite read-only by Q3 FY24/25, by observing an increase of 30% in migration progress. | |
| WE5.1.3 | If we implement a canonical url structure with versioning for our REST API then we can enable service migration and testing for Parsoid endpoints and similar services by Q1. | phab:T344944 |
| WE5.1.4 | If we complete the remaining work to mitigate the impact of browsers' anti-tracking measures on CentralAuth autologin and move to a more resilient authentication infrastructure (SUL3), we will be ready to roll out to production wikis in Q2. | |
| WE5.1.5 | If we increase the coverage of Sonar Cloud to include key MediaWiki Core repos, we will be able to improve the maintainability of the MediaWiki codebase. This hypothesis will be measured by spliting the selected repos into test and control groups. These groups will then be compared over the course of a quarter to measure impact of commit level feedback to developers. | |
| WE5.2.1 | If we make a classification of the types of hooks and extension registry properties used to influence the behavior of MediaWiki core, we will be able to focus further research and interventions on the most impactful. | [1] |
| WE5.2.2 | If we explore a new architecture for notifications in MW core and Echo, we will discover new ways to provide modularity and new ways for extensions to interact with core. | [2] |
| WE5.3.1 | If we instrument parser and cache code to collect template structure and fine-grained timing data, we can quantify the expected performance improvement which could be realized by future evolution of the wikitext parsing platform. | T371713 |
| WE5.3.2 | On template edits, if we can implement an algorithm in Parsoid to reuse HTML of a page that depends on the edited template without processing the page from scratch and demonstrate 1.5x or higher processing speedup, we will have a potential incremental parsing solution for efficient page updates on template edits. | T363421 |
| WE5.4.1 | If the MediaWiki engineering group is successful with release process accountability and enhances its communication process by the end of Q2 in alignment with the product strategy, we will eliminate the current process that relies on unplanned or volunteer work and improve community satisfaction with the release process. Measured by community feedback on the 1.43 LTS release coupled with a significant reduction in unplanned staff and volunteer hours needed for release processes. | |
| WE5.4.2 | If we research and build a process to more regularly upgrade PHP in conjunction with our MediaWiki release process we will increase speed and security while reducing the complexity and runtime of our CI systems, by observing the success of PHP 8.1 upgrade before 1.43 release. | |
| WE6.1.1 | If we design and complete the initial implementation of an authorization framework, we’ll establish a system to effectively manage the approval of all LDAP access requests. | |
| WE6.1.2 | If we research available documentation metrics, we can establish metrics that measure the health of Wikimedia technical documentation, using MediaWiki Core documentation as a test case. | mw:Wikimedia Technical Documentation Team/Doc metrics |
| WE6.1.3 | If we collect insights on how different teams are making technical decisions we are able to gather good practices and insights that can enable and scale similar practices across the organization. | |
| WE6.2.1 | If we publish a versioned build of MediaWiki, extensions, skins, and Wikimedia configuration at least once per day we will uncover new constraints and establish a baseline of wallclock time needed to perform a build. | mw:Wikimedia Release Engineering Team/Group -1 |
| WE6.2.2 | If we replace the backend infrastructure of our existing shared MediaWiki development and testing environments (from apache virtual servers to kubernetes), it will enable us to extend its uses by enabling MediaWiki services in addition to the existing ability to develop MediaWiki core, extensions, and skins in an isolated environment. We will develop one environment that includes MediaWiki, one or more Extensions, and one or more Services. | wikitech:Catalyst |
| WE6.2.3 | If we create a new deployment UI that provides more information to the deployer and reduce the amount of privilege needed to do deployment, it will make deployment easier and open deployments to more users as measured by the number of unique deployers and number of patches backported as a percentage of our overall deployments. | Wikimedia Release Engineering Team/SpiderPig |
| WE6.2.4 | If we migrate votewiki, wikitech and commons to MediaWiki on Kubernetes we reap the benefits of consistency and no longer need to maintain 2 different infrastructure platforms in parallel, allowing to reduce the amount of custom written tooling, making deployments easier and less toilous for deployers. This will be measured by a decrease in total deployment times and a reduction in deployment blockers. | tarefa T292707 |
| WE6.2.5 | If we move MultiVersion routing out of MediaWiki, we 'll be able to ship single version MediaWiki containers, largely cutting down the size of containers allowing for faster deployments, as measured by the deployment tool. | SingleVersion MW: Routing options |
| WE6.3.1 | By consulting toolforge maintainers about the least sustainable aspects of the platform, we will be able to gather a list of potential categories to measure. | |
| WE6.3.2 | By creating a "standard" tool to measure the number of steps for a deployment we will be able to assess the maximal improvement in the deployment process. | |
| WE6.3.3 | If we conduct usability tests, user interviews, and competitive analysis to explore the existing workflows and use cases of Toolforge, we can identify key areas for improvement. This research will enable us to prioritize enhancements that have the most significant impact on user satisfaction and efficiency, laying the groundwork for a future design of the user interface. | |
| Signals & Data Services (SDS) Hypotheses
[ SDS Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| SDS 1.1.1 | If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics. | |
| SDS1.2.2 | If we study the recruitment, retention, and attrition patterns among long-tenure community members in official moderation and administration roles, and understand the factors affecting these phenomena (the ‘why’ behind the trends), we will better understand the extent, nature, and variability of the phenomenon across projects. This will in turn enable us to identify opportunities for better interventions and support aimed at producing a robust multi-generational framework for editors. | phab:T368791 |
| SDS1.2.1 | If we gather use cases from product and feature engineering managers around the use of AI in Wikimedia services for readers and contributors, we can determine if we should test and evaluate existing AI models for integration into product features, and if yes, generate a list of candidate models to test. | phab:T369281 |
| SDS1.3.1 | If we define the process to transfer all data sets and pipeline configurations from the Data Platform to DataHub we can build tooling to get lineage documentation automatically. | |
| SDS 1.3.2 | If we implement a well documented and understood process to produce an intermediary table representing MediaWiki Wikitext History, populated using the event platform, and monitor the reliability and quality of the data we will learn what additional parts of the process are needed to make this table production ready and widely supported by the Data Platform Engineering team. | |
| SDS2.1.2 | If we investigate the data products current sdlc, we will be able to determine inflection points where QTE knowledge can be applied in order to have a positive impact on Product Delivery. | |
| SDS2.1.3 | If the Growth team learns about the Metrics Platform by instrumenting a Homepage Module on the Metrics Platform, then we will be prepared to outline a measurement plan in Q1 and complete an A/B test on the new Metrics platform by the end of Q2. | |
| SDS2.1.4 | If we conduct usability testing on our prototype among pilot users of our experimentation process, we can identify and prioritize the primary pain points faced by product managers and other stakeholders in setting up and analyzing experiments independently. This understanding will lead to the refinement of our tools, enhancing their efficiency and impact. | |
| SDS2.1.5 | If we design a documentation system that guides the experience of users building instrumentation using the Metrics Platform, we will enable those users to independently create instrumentation without direct support from Data Products teams, except in edge cases. | phab:T329506 |
| SDS2.2.1 | If we define a metric for logged-out mobile app reader retention, which is applicable for analyzing experiments (A/B test), we can provide guidance for planning instrumentation to measure retention rate of logged out readers in the mobile apps and enable the engineering team to develop an experiment strategy targeting logged out readers. | |
| SDS2.2.2 | If we define a standard approach for measuring and analyzing conversion rates, it will help us establish a collection of well-defined metrics to be used for experimentation and baselines, and start enabling comparisons between experiments/projects to increase learning from these. | |
| SDS2.2.3 | If we define a standard way of measuring and analyzing clickthrough rate (CTR) in our products/features, it will help us design experiments that target CTR for improvement, standardize click-tracking instrumentation, and enable us to make CTR available as a target metric to users of the experimentation platform. | |
| SDS2.3.1 | If we conduct a legal review of proposed unique cookies for logged out users, we can determine whether there are any privacy policy or other legal issues which inform the community consultation and/or affect the technical implementation itself. | |
| Future Audiences (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| FA1.1.1 | If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform. | m:Future Audiences/Experiment:Add a Fact |
| Product and Engineering Support (PES) Hypotheses
[ PES Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| PES1.1.1 | If the P&T leadership team syncs regularly on how they’re guiding their teams towards a more iterative software development culture, and we collect baseline measurements of current development practices and staff sentiment on how we work together to ship products, we will discover opportunity areas for change management. The themes that emerge will enable us to build targeted guidance or programs for our teams in coming quarters. | |
| PES1.2.2 | If the Moderator Tools team researches the Community Wishlist and develops 2+ focus areas in Q1, then we can solicit feedback from the Community and identify a problem that the Community and WMF are excited about tackling. | |
| PES1.2.3 | If we bundle 3-5 wishes that relate to selecting and inserting templates, and ship an improved feature in Q1, then CommTech can take the learnings to develop a Case Study for the foundation to incorporate more "focus areas" in the 2025-26 annual plan. | |
| PES1.3.1 | If we provide insights to audiences about their community and their use of Wikipedia over a year, it will stimulate greater connection with Wikipedia – encouraging greater engagement in the form of social sharing, time spent interacting on Wikipedia, or donation. Success will be measured by completing an experimental project that provides at least one recommendation about “Wikipedia insights” as an opportunity to increase onwiki engagement. | mw: New Engagement Experiments#PES1.3.1_Wikipedia_user_insights |
| PES1.3.2 | If we create a Wikipedia-based game for daily use that highlights the connections across vast areas of knowledge, it will encourage consumers to visit Wikipedia regularly and facilitate active learning, leading to longer increased interaction with content on Wikipedia. Success will be measured by completing an experimental project that provides at least one recommendation about gamification of learning as an opportunity to increase onwiki engagement. | mw: New Engagement Experiments#PES_1.3.2:_Wikipedia_games |
| PES1.3.3 | If we develop a new process/track at a Wikimedia hack event to incubate future experiments, it will increase the impact and value of such events in becoming a pipeline for future annual plan projects, whilst fostering greater connection between volunteers and engineering/design staff to become more involved with strategic initiatives. Success will be measured by at least one PES1.3 project being initiated and/or advanced to an OKR from a foundation-supported event. | mw: New Engagement Experiments#PES_1.3.3:_Incubator_space |
| PES1.4.1 | If we draft an SLO with the Editing team releasing Edit Check functionality, we will begin to learn and understand how to define and track user-facing SLOs together, and iterate on the process in the future. | |
| PES1.4.2 | If we define and publish SLAs for putting OOUI into “maintenance mode”, growth of new code using OOUI across Wikimedia projects will stay within X% in Q1. | |
| PES1.4.3 | If we map ownership using the proposed service catalog for known owned services in Q1, we will be able to identify significant gaps in service catalog as it helps in solving the SLO culture by the end of the year. | |
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 expand the Event list to become a Community List that includes WikiProjects, then we will be able to gather some early learnings in how to engage with WikiProjects for product development. | Campaigns/Foundation Product Team/Event list |
| WE1.1.2 | If we launch at least 1 consultation focused on on-wiki collaborations, and if we collect feedback from at least 20 people involved in such collaborations, then we will be able to advise Campaigns Product on the key characteristics needed to develop a new or improved way of connecting. | Campaigns/WikiProjects |
| WE1.1.3 | If we consult 20 event organizers and 20 WikiProject organizers on the best use of topics available via LiftWing, then we can prioritize revisions to the topic model that will improve topical connections between events and WikiProjects. | |
| WE1.1.4 | If we integrate CampaignEvents into Community Configuration in Q2, then we will set the stage for at least 5 more wikis opting to enable extension features in Q3, thereby increasing tool usage. | |
| WE1.2.2 | If we build a library of UI components and visual artifacts, Edit Check’s user experience can extend to accommodate Structured Tasks patterns. | |
| WE1.2.5 | If we conduct an A/B/C test with the alt-text suggested edits prototype in the production version of the iOS app we can learn if adding alt-text to images is a task newcomers are successful with and ultimately, decide if it's impactful enough to implement as a suggested edit on the Web and/or in the Apps. | |
| WE1.2.6 | If we introduce new account holders to the “Add a Link” Structured Task in Wikipedia articles, we expect to increase the percentage of new account holders who constructively activate on mobile by 10% compared to the baseline. | |
| WE1.3.1 | If we enable additional customisation of Automoderator's behaviour and make changes based on pilot project feedback in Q1, more moderators will be satisfied with its feature set and reliability, and will opt to use it on their Wikimedia project, thereby increasing adoption of the product. | mw:Moderator_Tools/Automoderator |
| WE1.3.3 | If we improve the user experience and features of the Nuke extension during Q2, we will increase administrator satisfaction of the product by 5pp by the end of the quarter. | mw:Extension:Nuke/2024_Moderator_Tools_project |
| WE2.1.3 | If we offer list-making as a service, we’ll enable at least 5 communities to make more targeted contributions in their topic areas as measured by (1) change in standard quality coverage of relevant topics on the relevant wiki and (2) a brief survey of organizer satisfaction with topic area coverage on-wiki. | |
| WE2.1.4 | If we developed a proof of concept that adds translation tasks sourced from WikiProjects and other list-building initiatives, and present them as suggestions within the CX mobile workflow, then more editors would discover and translate articles focused on topical gaps. By introducing an option that allows editors to select translation suggestions based on topical lists, we would test whether this approach increases the content coverage in our projects. |
|
| WE2.1.5 | If we expose topic-based translation suggestions more broadly and analyze its initial impact, we will learn which aspects of the translation funnel to act on in order to obtain more quality translations. | |
| WE2.2.4 | If we provide production wiki access to 5 new languages, with or without Incubator, we will learn whether access to a full-fledged wiki with modern features such as those available on English Wikipedia (including ContentTranslation and Wikidata support, advanced editing and search results) aids in faster editing. Ultimately, this will inform us if this approach can be a viable direction for language onboarding for new or existing languages, justifying further investigation. | |
| WE2.2.5 | If we move addwiki.php to core and customize it to Wikimedia, we will improve code quality in our wiki creation system making it testable and robust, and we will make it easy for creators of new wikis and thereby make significant steps towards simplifying wiki creation process. | phab:T352113 |
| WE2.3.2 | If we make two further improvements to media upload flow on Commons and share them with community, the feedback will be positive and it will help uploaders make less bad uploads (with the focus on copyright) as measured by the ratio of deletion requests within 30 days of upload. This will include release of further UX improvements to the release rights step in the Upload Wizard on Commons and automated detection of external sources. | |
| WE2.3.3 | If the BHL-Wikimedia Working Group creates Commons categories and descriptive guidelines for the South American and/or African species depicted in publications, they will make 3,000 images more accessible to biodiversity communities. (BHL = Biodiversity Heritage Library) |
|
| WE2.4.1 | If we build a prototype of Wikifunctions calls embedded within MediaWiki content and test it locally for stability, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2. | phab:T261472 |
| WE2.4.2 | If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2, as stated in Hypothesis 1. | phab:T363391 |
| WE2.4.3 | If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful. | phab:T282926 |
| WE3.1.3 | If we develop models for remixing content such as a content simplification or summarization that can be hosted and served via our infrastructure (e.g. LiftWing), we will establish the technical direction for work focused on increasing reader retention through new content discovery features. | Research |
| WE3.1.6 | If we introduce a personalized rabbit hole feature in the Android app and recommend condensed versions of articles based on the types of topics and sections a user is interested in, we will learn if the feature is sticky enough to result in multi-day usage by 10% of users exposed to the experiment over a 30-day period, and a higher pageview rate than users not exposed to the feature. | |
| WE3.1.7 | If we run a qualitative experiment focused on presenting article summaries to web readers, we will determine whether or not article summaries have the potential to increase reader retention, as proxied by clickthrough rate and usage patterns | |
| WE3.1.8 | If we build one feature which provides additional article-level recommendations, we will see an increase in clickthrough rate of 10% over existing recommendation options and a significant increase in external referrals for users who actively interact with the new feature. | |
| WE3.2.2 | Increasing the prominence of entry points to donations on the logged-out experiences of the Vector web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY. | mw:Readers/2024_Reader_and_Donor_Experiences |
| WE3.2.3 | If we make the “Donate” button in the iOS App more prominent by making it one click or less away from the main navigation screen, we will learn if discoverability was a barrier to non banner donations. | Navigation Refresh |
| WE3.2.4 | If we update the contributions page for logged-in users in the app to include an active badge for someone that is an app donor and display an inactive state with a prompt to donate for someone that decided not to donate in app, we will learn if this recognition is of value to current donors and encourages behavior of donating for prospective donors, informing if it is worth expanding on the concept of donor badges or abandoning it. | Private Donor Recognition Experiment |
| WE3.2.5 | If we create a Wikipedia in Review experiment in the Wikipedia app, to allow users to see and share personalized data about their reading, editing, and donation habits, we will see 2% of viewers donate on iOS as a result of this feature, 5% click share and, 65% of users rating the feature neutral or satisfactory. | Personalized Wikipedia Year in Review |
| WE3.2.7 | Increasing the prominence of entry points to donations on the logged-out experiences of the Minerva web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY. | |
| WE3.3.2 | If we develop the Charts MVP and get it working end-to-end in production test wikis, at least two Wikipedias + Commons agree to pilot it before the code freeze in December. | |
| WE3.4.1 | If we were to explore the feasibility by doing an experiment of setting up smaller PoPs in cloud providers like Amazon, we can expand our data center map and reach more users around the world, at reduced cost and increased turn-around time. | |
| WE4.1.2 | If we deploy at least one iteration of the Incident Reporting System MVP on pilot wikis, we will be able to gather valuable data around the frequency and type of incidents being reported. | https://meta.wikimedia.org/wiki/Incident_Reporting_System# |
| WE4.2.1 | If we explore and define Wikimedia-specific methods for a unique device identification model, we will be able to define the collection and storage mechanisms that we can later implement in our anti-abuse workflows to enable more targeted blocking of bad actors. | |
| WE4.2.9 | If we provide contextual information about reputation associated with an IP that is about to be blocked, we will see fewer collateral damage IP and IP range blocks, because administrators will have more insight into potential collateral damage effects of a block. We can measure this by instrumenting Special:Block and observing how behavior changes when additional information is present, vs when it is not. | |
| WE4.2.2 | If we define an algorithm for calculating a user account reputation score for use in anti-abuse workflows, we will prepare the groundwork for engineering efforts that use this score as an additional signal for administrators targeting bad actors on our platform. We will know the hypothesis is successful if the algorithm for calculating a score maps with X% precision to categories of existing accounts, e.g. a "low" score should apply to X% of permanently blocked accounts. | |
| WE4.2.3 | If we build an evaluation framework using publicly available technologies similar to the ones used in previous attacks we will learn more about the efficacy of our current CAPTCHA at blocking attacks and could recommend a CAPTCHA replacement that brings a measurable improvement in terms of the attack rate achievable for a given time and financial cost. | |
| WE4.3.1 | If we apply some machine learning and data analysis tools to webrequest logs during known attacks, we'll be able to identify abusive IP addresses with at least >80% precision sending largely malicious traffic that we can then ratelimit at the edge, improving reliability for our users. | |
| WE4.3.3 | If we deploy a proof of concept of the 'Liberica' load balancer, we will measure a 33% improvement in our capacity to handle TCP SYN floods. | |
| WE4.3.5 | By creating a system that spawns and controls thousands of virtual workers in a cloud environment, we will be able to simulate Distributed Denial of Service (DDoS) attacks and effectively measure the system's ability to withstand, mitigate, and respond to such attacks. | |
| WE4.3.6 | If we integrate the output of the models we built in WE 4.3.1 with the dynamic thresholds of per-ip concurrency limits we've built for our TLS terminators in WE 4.3.2, we should be able to increase our ability to neutralize automatically attacks with 20% more volume, as measured with the simulation framework we're building. | |
| WE4.3.7 | If we roll out a user-friendly web application that enables assisted editing and creation of requestctl rules, SREs will be able to mitigate cachebusting attacks in 50% less time than our established baseline. | |
| WE4.4.2 | If we deploy Temporary Accounts to a set of small-to-medium sized projects, we will be able to the functionality works as intended and will be able to gather data to inform necessary future work. | mw:/wiki/Trust_and_Safety_Product/Temporary_Accounts |
| WE5.1.1 | If we successfully roll out Parsoid Read Views to all Wikivoyages by Q1, this will boost our confidence in extending Parsoid Read Views to all Wikipedias. We will measure the success of this rollout through detailed evaluations using the Confidence Framework reports, with a particular focus on Visual Diff reports and the metrics related to performance and usability. Additionally, we will assess the reduction in the list of potential blockers, ensuring that critical issues are addressed prior to wider deployment. | |
| WE5.1.3 | If we reroute the endpoints currently exposed under rest_v1/page/html and rest_v1/page/title paths to comparable MW content endpoints, then we can unblock RESTbase sunsetting without disrupting clients in Q1. | |
| WE5.1.4 | If we complete the remaining work to mitigate the impact of browsers' anti-tracking measures on CentralAuth autologin and move to a more resilient authentication infrastructure (SUL3), we will be ready to roll out to production wikis in Q2. | |
| WE5.1.5 | If we increase the number of relevant SonarCloud rules enabled for key MediaWiki Core repositories and refine the quality of feedback provided to developers, we will optimize the developer experience and enable them to improve the maintainability of the MediaWiki codebase in the future. This will be measured by tracking developer satisfaction levels and whether test group developers feel the tool is becoming more useful and effective in their workflow. Feedback will be gathered through surveys and direct input from developers to evaluate the perceived impact on their confidence in the tool and the overall development experience. | |
| WE5.1.7 | If we represent all content module endpoint responses (10 in total) in our MediaWiki REST API OpenAPI spec definitions, we will be able to implement programmatic validation to guarantee that our generated documentation matches the actual responses returned in code. | |
| WE5.1.8 | If we introduce support for endpoint description translation (ie: does not include actual object definitions or payloads) into our generated MediaWiki REST API OpenAPI specs, we can lay the foundation to support Wikimedia’s expected internationalization standards. | |
| WE5.2.3 | If we conduct an experiment to reimplement at least [1-3] existing Core and Extension features using a new Domain Event and Listener platform component pattern as an alternative to traditional hooks, we will be able to confirm our assumption of this intervention enabling simpler implementation with more consistent feature behavior. | |
| WE5.3.3 | If we instrument both parsers to collect availability of prior parses and timing of template expansions, and to classify updates and dependencies, we can prioritize work on selective updates (Hypothesis 5.3.2) informed by the quantification of the expected performance benefits. | |
| WE5.3.4 | If we can increase the capability of our prototype selective update implementation in Parsoid using the learnings from the 5.3.1 hypothesis, we can leverage more opportunities to increase the performance benefit from selective update. | |
| WE5.4.1 | If the MediaWiki engineering group is successful with release process accountability and enhances its communication process by the end of Q2 in alignment with the product strategy, we will eliminate the current process that relies on unplanned or volunteer work and improve community satisfaction with the release process. Measured by community feedback on the 1.43 LTS release coupled with a significant reduction in unplanned staff and volunteer hours needed for release processes. | |
| WE5.4.2 | If we research and build a process to more regularly upgrade PHP in conjunction with our MediaWiki release process we will increase speed and security while reducing the complexity and runtime of our CI systems, by observing the success of PHP 8.1 upgrade before 1.43 release. | |
| WE6.1.3 | If we collect insights on how different teams are making technical decisions we are able to gather good practices and insights that can enable and scale similar practices across the organization. | |
| WE6.1.4 | If we research solutions for indexing the code of all projects hosted in WMF’s code repositories, we will be able to pick a solution that allows our users to quickly discover where the code is located whenever dealing with incident response or troubleshooting. | |
| WE6.1.5 | If we test a subset of draft metrics on an experimental group of technical documentation collections, we will be able to make an informed decision about which metrics to implement for MediaWiki documentation. | Wikimedia_Technical_Documentation_Team/Doc_metrics |
| WE6.2.1 | If we publish a versioned build of MediaWiki, extensions, skins, and Wikimedia configuration at least once per day we will uncover new constraints and establish a baseline of wallclock time needed to perform a build. | mw:Wikimedia Release Engineering Team/Group -1 |
| WE6.2.2 | If we replace the backend infrastructure of our existing shared MediaWiki development and testing environments (from apache virtual servers to kubernetes), it will enable us to extend its uses by enabling MediaWiki services in addition to the existing ability to develop MediaWiki core, extensions, and skins in an isolated environment. We will develop one environment that includes MediaWiki, one or more Extensions, and one or more Services. | wikitech:Catalyst |
| WE6.2.3 | If we create a new deployment UI that provides more information to the deployer and reduce the amount of privilege needed to do deployment, it will make deployment easier and open deployments to more users as measured by the number of unique deployers and number of patches backported as a percentage of our overall deployments. | mw:SpiderPig |
| WE6.2.5 | If we move MultiVersion routing out of MediaWiki, we 'll be able to ship single version MediaWiki containers, largely cutting down the size of containers allowing for faster deployments, as measured by the deployment tool. | https://docs.google.com/document/d/1_AChNfiRFL3VdNzf6QFSCL9pM2gZbgLoMyAys9KKmKc/edit |
| WE6.2.6 | If we gather feedback from QTE, SRE, and individuals with domain specific knowledge and use their feedback to write a design document for deploying and using the wmf/next OCI container, then we will reduce friction when we start deploying that container. | T379683 |
| WE6.3.4 | If we enable the automatic deployment of a minimal tool, we will be able to evaluate the end to end flow and set the groundwork to adding support for more complex tools and deployment flows. | phab:T375199 |
| WE6.3.5 | By assessing the relative importance of each sustainability category and its associated metrics, we can create a normalized scoring system. This system, when implemented and recorded, will provide a baseline for measuring and comparing Toolforge’s sustainability progress over time. | phab:T376896 |
| WE6.3.6 | If we conduct discovery, such as target user interviews and competitive analysis, to identify existing Toolforge pain points and improvement opportunities, we will be able to recommend a prioritized list of features for the future Toolforge UI. | Phab:T375914 |
| Signals & Data Services (SDS) Hypotheses
[ SDS Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| SDS 1.1.1 | If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics. | |
| SDS1.2.1.B | If we test the accuracy and infrastructure constraints of 4 existing AI language models for 2 or more high-priority product use-cases, we will be able to write a report recommending at least one AI model that we can use for further tuning towards strategic product investments. | Phab:T377159 |
| SDS1.2.2 | If we study the recruitment, retention, and attrition patterns among long-tenure community members in official moderation and administration roles, and understand the factors affecting these phenomena (the ‘why’ behind the trends), we will better understand the extent, nature, and variability of the phenomenon across projects. This will in turn enable us to identify opportunities for better interventions and support aimed at producing a robust multi-generational framework for editors. | Learn more. |
| SDS1.2.3 | If we combine existing knowledge about moderators with quantitative methods for detecting moderation activity, we can systematically define and identify Wikipedia moderators. | T376684 |
| SDS1.3.1.B | If we integrate the Spark / DataHub connector for all production Spark jobs, we will get column-level lineage for all Spark-based data platform jobs in DataHub. | |
| SDS1.3.2.B | If we implement a frequently run Spark-based MariaDB MW history data querying job, reconciliate missing events and enrich them, we will provide a daily updated MW history wikitext content data lake table. | |
| SDS2.1.1 | If we create an integration test environment for the proposed 3rd party experimentation solution, we can collaborate practically with Data SRE, SRE, QTE, and Product Analytics to evaluate the solution’s viability within WMF infrastructure in order to make a confident build/install/buy recommendation. | mw:Data_Platform_Engineering/Data_Products/work_focus |
| SDS2.1.3 | If the Growth team learns about the Metrics Platform by instrumenting a Homepage Module on the Metrics Platform, then we will be prepared to outline a measurement plan in Q1 and complete an A/B test on the new Metrics platform by the end of Q2. | |
| SDS2.1.4 | If we conduct usability testing on our prototype among pilot users of our experimentation process, we can identify and prioritize the primary pain points faced by product managers and other stakeholders in setting up and analyzing experiments independently. This understanding will lead to the refinement of our tools, enhancing their efficiency and impact. | |
| SDS2.1.5 | If we design a documentation system that guides the experience of users building instrumentation using the Metrics Platform, we will enable those users to independently create instrumentation without direct support from Data Products teams, except in edge cases. | tarefa T329506 |
| SDS2.1.7 | If we provide a function for user enrollment and a mechanism to capture and store CTR events to a monotable in a pre-declared event stream we can ship MPIC Alpha in order to launch an basic split A/B test on logged in users. | |
| SDS2.2.2 | If we define a standard approach for measuring and analyzing conversion rates, it will help us establish a collection of well-defined metrics to be used for experimentation and baselines, and start enabling comparisons between experiments/projects to increase learning from these. | |
| SDS2.3.1 | If we conduct a legal review of proposed unique cookies for logged out users, we can determine whether there are any privacy policy or other legal issues which inform the community consultation and/or affect the technical implementation itself. | |
| Future Audiences (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| FA1.1.1 | If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform. | Experiment:Add a Fact |
| Product and Engineering Support (PES) Hypotheses
[ PES Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| PES1.2.4 | If we research the Task Prioritization focus area in the Community Wishlist in early Q2, we will be able to identify and prioritize work that will improve moderator satisfaction, which we can begin implementing in Q3. | |
| PES1.2.5 | If we are able to publish and receive community feedback on 6+ focus areas in Q2, then we will have confidence in presenting at least 3+ focus areas for incorporation in the 2025-26 annual plan. | |
| PES1.2.6 | By introducing favouriting templates, we will improve the number of templates added via the template dialog by 10%. | |
| PES1.3.4 | If we create an experience that provides insights to Wikipedia Audiences about their community over the year, it will stimulate greater connection with Wikipedia – encouraging engagement in the form of social sharing, time spent interacting on Wikipedia, or donation. | |
| PES1.4.1 | If we draft an SLO with the Editing team releasing Edit Check functionality, we will begin to learn and understand how to define and track user-facing SLOs together, and iterate on the process in the future. | |
| PES1.4.2 | If we define and publish SLAs for putting OOUI into “maintenance mode”, growth of new code using OOUI across Wikimedia projects will stay within X% in Q1. | |
| PES1.4.3 | If we map ownership using the proposed service catalog for known owned services in Q1, we will be able to identify significant gaps in service catalog as it helps in solving the SLO culture by the end of the year. | |
| PES1.5.1 | If we finalize and publish the Edit Check SLO draft, practice incorporating it in regular workflows and decisions, and draft a Citoid SLO, we’ll continue learning how to define and track user-facing and cross-team SLOs together. | |
| PES1.5.2 | If we clarify and define in writing a document with set of roles and responsibilities of stakeholders throughout the service lifecycle, this will enable teams to make informed commitments in the Service Catalog, including SLOs | |
Explanation of buckets
Wiki Experiences
The purpose of this bucket is to efficiently deliver, improve and innovate on wiki experiences that enable the distribution of free knowledge world-wide. This bucket aligns with movement strategy recommendations #2 (Improve User Experience) and #3 (Provide for Safety and Inclusion). Our audiences include all collaborators on our websites, as well as the readers and other consumers of free knowledge. We support a top-10 global website, and many other important free culture resources. These systems have performance and uptime requirements on-par with the biggest tech companies in the world. We provide user interfaces to wikis, translation, developer APIs (and more!) and supporting applications and infrastructure that all form a robust platform for volunteers to collaborate to produce free knowledge world-wide. Our objectives for this bucket should enable us to improve our core technology and capabilities, ensure we continuously improve the experience of volunteer editors and moderators of our projects, improve the experience of all technical contributors working to improve or enhance the wiki experiences, and ensure a great experience for readers and consumers of free knowledge worldwide. We will do this through product and technology work, as well as through research and marketing. We expect to have at most five objectives for this bucket.
Knowledge is constructed by people! And as a result our annual plan will focus on the content as well as the people who contribute to the content and those who access and read it.
Our aim is to produce an operating plan based on existing strategy, mainly our hypotheses about the contributor, consumer and content "flywheel". The primary shift I’m asking for is an emphasis on the content portion of the flywheel, and exploration of what our moderators and functionaries might need from us now, with the aim of identifying community health metrics in the future.
Signals and Data Services
In order to meet the Movement Strategy Recommendations for Ensuring Equity in Decision Making (Recommendation #4), Improving User Experience (Recommendation #2), and Evaluating, Iterating and Adapting (Recommendation #10), decision makers from across the Wikimedia Movement must have access to reliable, relevant, and timely data, models, insights, and tools that can help them assess the impact (both realized and potential) of their work and the work of their communities, enabling them to make better strategic decisions.
In the Signals & Data Services bucket, we have identified four primary audiences: Wikimedia Foundation staff, Wikimedia affiliates and user groups, developers who reuse our content, and Wikimedia researchers, and we prioritize and address the data and insights needs of these audiences. Our work will span a range of activities: defining gaps, developing metrics, building pipelines for computing metrics, and developing data and signals exploration experiences and pathways that help decision makers interact more effectively and joyfully with the data and insights.
Future Audiences
.svg)
The purpose of this bucket is to explore strategies for expanding beyond our existing audiences of consumers and contributors, in an effort to truly reach everyone in the world as the essential infrastructure of the ecosystem of free knowledge. This bucket aligns with Movement Strategy Recommendation #9 (Innovate in Free Knowledge). More and more, people are consuming information in experiences and forms that diverge from our traditional offering of a website with articles – people are using voice assistants, spending time with video, engaging with AI, and more. In this bucket, we will propose and test hypotheses around potential long-term futures for the free knowledge ecosystem and how we will be its essential infrastructure. We will do this through product and technology work, as well as through research, partnerships, and marketing. As we identify promising future states, learnings from this bucket will influence and be expanded through Buckets #1 and #2 in successive annual plans, nudging our product and technology offerings toward where they need to be to serve knowledge-seekers of the future. Our objectives for this bucket should drive us to experiment and explore as we bring a vision for the future of free knowledge into focus.
Sub-buckets
We also have two other “sub-buckets” which consist of areas of critical functions, which must exist at the Foundation to support our basic operations, and some of which we have in common with any software organization. These “sub-buckets” won’t have top level objectives of their own, but will have input on and will support the top level objectives of the other groups. They are:
- Infrastructure Foundations. This bucket covers the teams which sustain and evolve our datacenters, our compute and storage platforms, the services to operate them, the tools and processes that enable the operation of our public facing sites and services.
- Product and Engineering Support. This bucket includes teams which operate “at scale” providing services to other teams that improve the productivity and operations of other teams.