Plan roczny Wikimedia Foundation/2024-2025/Kluczowe rezultaty - Produkt i technologia
Dokument jest częścią pierwszej fazy planowania działu Produktu i Technologii na rok 2024-25 w ramach planu rocznego Wikimedia Foundation. Przedstawia wstępny zarys celów i oczekiwanych rezultatów. Jest to kontynuacja planowania podzielonego na "koszyki", rozpoczętego w zeszłym roku.
.jpg)
W listopadzie mówiłam Wam o tym, co według mnie jest najważniejszym pytaniem dla ruchu Wikimedia. Jak powielić sukces Wikipedii i innych projektów Wikimedia na kolejne pokolenia? Chciałbym podziękować wszystkim, którzy zatrzymali się nad tym pytaniem, którzy się ze mną skontaktowali. Spędziłam nieco czasu nad przemyśleniem Waszych uwag i podzielę się swoimi spostrzeżeniami.
Przede wszystkim, nie istnieje jedna zidentyfikowana przyczyna, dla której edytujemy projekty Wikimedia. Chcąc lepiej rozwijać przyszłe pokolenia wolontariuszy, musimy lepiej poznać przyczyny, które przyciągają ich do edytowania. Musimy też pomyśleć o tym, co nas odróżnia od innych projektów: zdolność do dostarczania wiarygodnych treści w zalewie dezinformacji i fake newsów przez rywalizujące platformy. Częścią naszych wysiłków jest zebranie i zaprezentowanie sumy ludzkiej wiedzy poprzez uzupełnianie brakujących szczegółów, co wynikać może z nierówności dostępu do wiedzy, stronniczości czy dyskryminacji. Nasze treści muszą również pozostać istotne w zmieniającym się Internecie napędzanym sztuczną inteligencją i bogatymi doświadczeniami użytkownika. Musimy też znaleźć sposoby na zrównoważone finansowanie naszego ruchu, budując wspólną strategię dla naszych produktów i źródeł przychodu, by finansowanie działało długoterminowo.
Umieścimy te pomysły w planie rocznym Fundacji na rok obrotowy 2024–2025. Dzisiaj przedstawiam Wam pierwszy szkic – celów dla działu Produktu i Technologii. Podobnie, jak w zeszłym roku, ogólny plan roczny będzie skupiony naokoło potrzeb technologicznych naszych odbiorców i platform. Chcemy usłyszeć od Was, czy koncentrujemy się na tych właściwych aspektach. Cele pochodzą z pomysłów zgłaszanych przez społeczności w ramach projektu Talking:2924, na listach dyskusyjnych i stronach dyskusji. O założenia produktowe i technologiczne na kolejny rok pytaliśmy też w trakcie wydarzeń społecznościowych. Możecie poznać pełną listę celów.
"Celem" nazywamy kierunek, który będzie kształtował nasze projekty w kolejnym roku budżetowym. Specjalnie są one szerokie, przedstawiają kierunek naszej strategii i co ważne, nadają priorytety różnym możliwym sprawom, którymi moglibyśmy się zająć. Publikujemy szkic już teraz, by członkowie społeczności dopomogli nam w ukształtowaniu wizji przed ustaleniem budżetów i zobowiązań na kolejny rok.
Komentarze
Rzeczą, do której szczególnie mocno chcemy uzyskać Wasze komentarze, są działania związane z "Doświadczeniem Wiki". Jest to kwestia tego, jak dostarczamy, usprawniamy i dokonujemy innowacji w tym, jak użytkownicy - zarówno czytelnicy, darczyńcy, jak i edytujący - korzystają z wiki. W tym obszarze wspieramy naszą rdzenną technologię i poszerzamy możliwości, ale też upewniamy się, że możemy poprawić doświadczenie naszych edytorów, szczególnie tych z zaawansowanymi uprawnieniami, dzięki lepszym narzędziom i rozwiązaniom, tłumaczeniom i usprawnieniom w obrębie platformy.
Poniżej znajdziecie przemyślenia po naszych rozmowach związanych z planowaniem kolejnego roku, jak też pytania, dzięki którym zamierzamy poprawić nasze pomysły.
- Działania wolontariackie w projektach Wikimedia powinny dawać satysfakcję. Sądzimy też, że doświadczenie ze współpracy online powinno być czynnikiem, dzięki któremu użytkownicy wracają do Wikimediów. Co sprawia, że edytorzy czują satysfakcję i współpracują lepiej w celu tworzenia wiarygodnych treści?
- Wiarygodność naszych treści jest częścią unikalnego wkładu Wikimediów do świata, jak też czynnikiem, dzięki któremu ludzie korzystają z naszych projektów i treści. Co możemy zrobić, by wiarygodne treści przyrastały szybciej i lepiej, ale nadal zgodnie z zasadami jakości, ustanowionymi przez społeczności każdego projektu?
- By utrzymać istotność i skutecznie konkurować z innymi wielkimi platformami internetowymi, Wikimedia potrzebują nowego pokolenia odbiorców czujących więź z naszymi treściami. Jak sprawić, by nasze treści łatwiej było odszukać i jak prowadzić interakcję z naszymi czytelnikami i darczyńcami?
- W czasach, gdy nękanie w internecie kwitnie, musimy zapewnić, że nasze społeczności, platforma i systemy dostarczania zawartości są zabezpieczone. Stoimy również w obliczu rozwijanych wymogów regulacyjnych, gdzie światowi decydenci zajmują się modelowaniem prywatność, tożsamość i udostępnianiem informacji online. Jak powinniśmy poprawiać nasze zdolności zwalczania nękania, aby odpowiedzieć na powyższe wyzwania?
- MediaWiki, platforma programistyczna i interfejsy, dzięki którym działa Wikipedia, wymaga ciągłego wsparcia na kolejną dekadę, by umożliwiać tworzenie, moderowanie, przechowywanie, odkrywania i korzystanie z informacji - otwartej, wielojęzycznej, na dużą skalę. Jakie decyzje i jaki rozwój platformy MediaWiki są konieczne w tym roku, by platforma ta nadal wypełniała swoje zadania?
Cele (szkic)
Aktualnie opublikowane są najbardziej ogólne cele .
Kolejny poziom, czyli kluczowe rezultaty dla każdego celu, podane są niżej.
Hipotezy leżące u podstaw każdego kluczowego rezultatu znajdą się i będą aktualizowane przez cały rok na stronach projektów i zespołów, w miarę zyskiwania wiedzy o rozwijanych obszarach.
| Wstępne cele - Wiki Experiences (Doświadczenie wiki) | ||||
|---|---|---|---|---|
| Cel | Obszar | Cel | Kontekst | Właściciel |
| WE1 | Doświadczenie twórców | Doświadczeni i nowi twórcy współpracują online celem tworzenia wiarygodnej encyklopedii, z coraz większą łatwością i mniejszą frustracją. | By Wikipedia w kolejnych latach była żywa, musimy wychować kolejne pokolenia twórców i uczynić wnoszenie wkładu czymś, co się chce robić. Różne pokolenia twórców potrzebują różnych inwestycji - doświadczeni ucieszą się z usprawnienia narzędzi do zaawansowanej pracy, a nowsi potrzebują nowych metod edytowania, które dla nich mają sens. Ponadto niezależnie od pokolenia, wszyscy twórcy muszą być w stanie łączyć się z innymi, by mieć jak największe efekty pracy. W ramach tego celu pracujemy nad usprawnieniami dla zaawansowanych użytkowników, obniżamy bariery konstruktywnego wkładu dla nowicjuszy i inwestujemy w sposoby komunikacji między edytującymi pokrewne tematy. | Marshall Miller |
| WE2 | Encyklopedyczne treści | Społeczności są wspierane w uzupełnianiu luk w wiedzy dzięki narzędziom i systemom, które są dostępniejsze, łatwiejsze w użyciu, dostosowywaniu i usprawnianiu, co daje wzrost zaufania do wiarygodnej encyklopedycznej wiedzy. | Encyklopedyczne treści, głównie w Wikipedii, można mnożyć i poprawiać dzięki ciągłemu zaangażowaniu i innowacyjności. Narzędzia i zasoby - techniczne i inne - dostępne dla twórców mogą być łatwiejsze do odnalezienia i bardziej wiarygodne w działaniu. Takie narzędzia powinny mieć lepsze wsparcie ze strony WMF, dzięki usprawnieniom opracowywanym w krótkich cyklach produkcyjnych. W świetle ostatnich trendów związanych z generowaniem treści z udziałem AI i zmieniających się zachowań użytkowników, podejmiemy również prace nad projektami, takimi, jak Wikifunkcje, które pomogą w skalowaniu tworzenia i wykorzystywania wiedzy. Mechanizmy do znajdowania luk w wiedzy powinny być łatwiejsze do odnalezienia i powinny wspierać planowanie prac. Zasoby wspierające tworzenie encyklopedycznej wiedzy, takie jak Biblioteka Wikipedii czy kampanie edycyjne, powinny być lepiej zintegrowane z mechanizmami pracy twórców. Metody wykorzystywane do mnożenia wiedzy powinny jednocześnie mieć zabezpieczenia przed narastającymi zagrożeniami, zapewniające ciągłe zaufanie w proces tworzenia treści, utrzymując podstawowe założenia encyklopedyczności obecne w projektach Wikimedia.
Publiczność: redaktorzy, tłumacze |
Runa Bhattacharjee |
| WE3 | Doświadczenie użytkownika (tekst i media) | Nowe pokolenie konsumentów dociera do Wikipedii, odkrywając w niej preferowane miejsce dowiadywania się i interakcji i budując długofalową relację z encyklopedycznymi treściami. | Cele:
Utrzymania istniejących i przyszłych pokoleń konsumentów i darczyńców Zwiększenie istotności dla bieżących i przyszłych pokoleń konsumentów, przez ułatwienie odkrywania treści Wikipedii i usprawnienie interakcji z tymi treściami. Praca na różnych platformach nad zaadaptowaniem naszych doświadczeń i istniejącej wiedzy, by encyklopedyczne treści można było odkrywać i poprawiać dla i w ramach nowego pokolenia konsumentów i darczyńców. |
Olga Vasileva |
| WE4 | Zaufanie i bezpieczeństwo | Poprawa infrastruktury, narzędzi i procesów, by projekty Wikimedia były odpowiednio przygotowane na ochronę społeczności, platformy i infrastruktury przed różnorodnymi skalowalnymi i bezpośrednimi naruszeniami, przy zachowaniu zgodności z regulacjami prawnymi. | Niektóre aspekty naszej zdolności do walki z nadużyciami wymagają ulepszenia. Zmniejszenie nadużyć związanych z adresami IP staje się coraz mniej skuteczne, kilka narzędzi administracyjnych wymaga poprawy wydajności, a my musimy stworzyć jednolita strategię, która pomoże nam wielkoskalowo zwalczać nadużycia poprzez łączone wykorzystanie różnych sygnałów i mechanizmów łagodzenia (captcha, blokady, itp.). W tym roku rozpoczniemy prace nad największymi problemami w tym obszarze. Ponadto, inwestycje w ochronę przed nadużyciami muszą być zrównoważone inwestycjami w zrozumienie i poprawę kondycji społeczności - kilka aspektów tego obszaru uwzględniono w różnych wymaganiach prawnych. | Suman Cherukuwada |
| WE5 | Platforma wiedzy I (Ewolucja platformy) | Ewolucja platformy MediaWiki i jej interfejsów do usprawnienia podstawowych potrzeb Wikipedii. | Oprogramowanie MediaWiki stworzono dla tworzenia, moderowania, przechowywania, odkrywania i korzystania z otwartych wielojęzycznych treści na wielką skalę. W drugim roku Platformy Wiedzy, chcemy przyjrzeć się systemowi i rozpocząć prace nad usprawnieniami platformy, by przez kolejna dekadę wspierała ona prawidłowo najważniejsze potrzeby projektów Wikimedia, począwszy od Wikipedii. Kontynuować będziemy prace nad lepszym scharakteryzowaniem naszej platformy produkowania wiedzy, wzmocnieniem jej zrównoważonego rozwoju, skoncentrujemy się na rozszerzeniach, lepiej opisując i projektując rozwijanie kolejnych funkcji, dalej też będziemy wspierać dzielenie się wiedzą i zapraszając ludzi do rozwijania MediaWiki. | Birgit Müller |
| WE6 | Platforma wiedzy II (Usługi dla programistów) | pracownicy techniczni i programiści-wolontariusze będą mieć narzędzia do wydajnego wspierania projektów Wikimedia. | Będziemy kontynuować prace nad usprawnianiem i zwiększaniem skali cyklu rozwijania, testowania i publikowania oprogramowania; rozszerzymy też definicję Wikimedia Production, by zawarły się w niej usługi dla programistów narzędzi. Chcemy też lepiej odpowiadać na najczęściej zadawane pytania w dziedzinie o prace programistyczne i inżynierskie, a posiadane dane będziemy udostępniać, by podejmowane decyzje były bardziej świadome. Częścią naszych działań w tym obszarze jest poszukiwanie praktyk (lub nieistniejących praktyk) które utrudniają rozwój naszego ekosystemu. | Birgit Müller |
| Wstępne cele Sygnałów i Usług Danych | ||||
|---|---|---|---|---|
| Cel | Obszar | Cel | Kontekst | Właściciel |
| SDS1 | Shared insights | Nasze decyzje dotyczące wspierania misji i ruchu Wikimedia są zawarte w wysokopoziomowych metrykach i przemyśleniach. | By wydajnie i skutecznie tworzyć rozwiązania technologiczne, wspierać wolontariuszy i prowadzić rzecznictwo w sprawie zasad, które chronią i poszerzają dostęp do wiedzy, musimy dobrze zrozumieć ekosystem Wikimedia i dopasować nasze działania do tego, co jest określane mianem sukcesu. Oznacza to śledzenie zestawu metryk, które są wiarygodne, zrozumiałe i szybko dostępne. Oznacza to również prowadzenie badań i zbieranie przemyśleń, dzięki którym zrozumiemy, dlaczego i jak pewne rzeczy się dzieją. | Kate Zimmerman |
| SDS2 | Platforma eksperymentalna | Menedżerowie produktów mogą szybko, łatwo i z pewnością ocenić wpływ cech prowadzonych przez nich produktów. | Aby umożliwić i przyspieszyć podejmowanie decyzji na temat rozwoju funkcji produktów, menedżerowie produktu potrzebują platformy eksperymentalnej, w której mogą zdefiniować funkcje, wybierać grupy użytkowników do badania i sprawdzać pomiary wpływu zmian. Skrócenie czasu pomiędzy rozpoczęciem badania a analizą wyników jest niezwykle istotne, gdyż skrócenie czasu poświęconego na uczenie się przyspieszy prowadzenie eksperymentów, a w konsekwencji innowacje. Testy prowadzone ręcznie o dotychczasowe metody pomiarów określiliśmy jako bariery wzrostu. W idealnym scenariuszu, menedżerowie produktu menedżerowie produktu mogą przejść od rozpoczęcia eksperymentu do konkluzji przy zerowym lub minimalnym nakładzie pracy ręcznej ze strony inżynierów i analityków. | Tajh Taylor |
| Wstępne cele - przyszli odbiorcy | ||||
|---|---|---|---|---|
| Cel | Obszar | Cel | Kontekst | Właściciel |
| FA1 | Hipotezy testowe | Wydanie rekomendacji dotyczących inwestycji strategicznych ze strony WMF - na podstawie wniosków z eksperymentów dających lepsze zrozumienie dzielenia się wiedzą i jej konsumpcji w środowisku online - by ruch Wikimedia lepiej służył odbiorcom w zmieniającym się Internecie. | Ze względu na ciągłe zmiany w technologii i zachowaniu użytkowników online (np. zwiększająca się preferencja do uzyskiwania informacji za pośrednictwem aplikacji społecznościowych, popularność krótkich materiałów wideo, wzrost ilości treści generowanych przez AI), ruch Wikimedia staje w obliczu coraz trudniejszego przyciągania i utrzymania czytelników i edytorów. Zmiany te przynoszą jednak również możliwości obsłużenia nowych odbiorców poprzez tworzenie i dostarczanie informacji w nowy sposób. Jednakże, jako ruch nie mamy jasnego, opartego na danych obrazu korzyści i kompromisów, które należy mieć na uwadze by przełamać wyzwania stojące na drodze ku nowym szansom. Czy więc powinniśmy na przykład...
Aby zapewnić, że projekty Wikimedia staną się wielopokoleniowe, będziemy testować hipotezy, aby lepiej zrozumieć i zarekomendować odpowiednie obiecujące strategie działania - dla WMF i całego ruchu Wikimedia - by dążyć do przyciągnięcia i utrzymania przyszłych odbiorców. |
Maryana Pinchuk |
| Wstępne cele - wsparcie produktu i inżynierii | ||||
|---|---|---|---|---|
| Cel | Obszar | Cel | Kontekst | Właściciel |
| PES1 | Wydajność działania | Sprawienie, by Wikimedia Foundation pracowała szybciej, taniej i z większym efektem | Pracownicy robią wiele w swojej pracy, aby nasze działania były szybsze, tańsze i bardziej efektywne. W ramach tego celu podkreślono konkretne inicjatywy, które a) przyniosą znaczne zyski w kierunku szybszego, tańszego lub bardziej skutecznego działania; b) podejmą skoordynowane wysiłki i zmienią praktyki formalne i nieformalne w Fundacji. W istocie kluczowe rekomendacje w ramach tego celu są najtrudniejszymi i najlepszymi ulepszeniami, jakich możemy w tym roku dokonać w zakresie efektywności operacyjnej pracy w dziedzinie naszych produktów i technologii. | Amanda Bittaker |
Wstępne kluczowe rezultaty (Key Results, KR)
Wstępne kluczowe rezultaty dla każdego celu są spisane poniżej. Odpowiadają celom wymienionym wyżej.
Hipotezy dla każdego kluczowego rezultatu będą aktualizowane przez cały rok na stronach projektów i zespołów, w miarę zyskiwania wiedzy o rozwijanych obszarach.
| Doświadczenie wiki (WE) - Projekt kluczowych rezultatów
[ Wstępne cele ] | |||
|---|---|---|---|
| Skrótowa nazwa rezultatu | Opis rezultatu | Kontekst rezultatu | Właściciel |
| WE1.1 | Opracowanie lub ulepszanie jednego cyklu pracy, który pomaga uczestnikom o wspólnych zainteresowaniach łączyć się ze sobą i współpracować nad tworzeniem treści. | Uważamy, że przestrzenie społecznościowe i interakcje na wiki sprawią, że ludzie będą szczęśliwsi i bardziej produktywni jako twórcy. Ponadto przestrzenie społeczne pomagają we wdrożeniu i mentoringu nowych użytkowników, służą do modelowania najlepszych praktyk tworzenia treści i pomagają identyfikować luki w wiedzy. Jednak istniejące zasoby, narzędzia i przestrzenie wspierające współpracę nie nadążają za rzeczywistością i nie odpowiadają na potrzeby i wyzwania współczesnych twórców. W międzyczasie, praca zespołu Kampanii edycyjnych wykazała, że wielu organizatorów takich wydarzeń chętnie eksperymentuje z nowymi narzędziami dzięki ustrukturyzowanemu cyklowi pracy, co pomaga im w działaniach organizatorskich. Z tego powodu, chcemy skupić się na wspieraniu i promowaniu poczucia przynależności uczestników projektów do społeczności. | Ilana Fried |
| WE1.2 | Konstruktywne aktywowanie: #% przyrost rok do roku procenta nowicjuszy, którzy dokonali co najmniej jednej konstruktywnej edycji na urządzeniu mobilnym. |
Aktualne całostronicowe edytowanie wymaga zbyt wiele kontekstu, cierpliwości i prób i błędów od nowicjuszy, by byli w stanie wnieść konstruktywne treści do projektów. Chcąc wesprzeć nowe pokolenie wolontariuszy, zwiększymy liczbę i dostępność mniejszych, ustrukturyzowanych i zadaniowych metod edytowania, na przykład Edit Check i Ustrukturyzowane zadania.
Uwaga: wartości bazowe zostaną ustalone pod koniec 4. kwartały aktualnego roku obrotowego, po czym również ustalona zostanie metryka (procentowa) tego rezultatu. |
Peter Pelberg |
| WE1.3 | Zwiększenie zadowolenia użytkownika w 4 produktach moderacyjnych o X%. | Redaktorzy z rozszerzonymi uprawnieniami korzystają z szerokiej gamy istniejących funkcji, rozszerzeń, narzędzi i skryptów do wykonywania zadań moderacyjnych w projektach Wikimedia. W tym roku chcemy skupić się na udoskonalaniu tego zestawu narzędzi zamiast podejmować projekty mające na celu zbudowanie nowej funkcjonalności w tej przestrzeni. Zamierzamy wprowadzić wiele produktów w ciągu roku i chcemy w każdym z nich dokonać ulepszeń. Mamy nadzieję, że w ten sposób poprawimy ogólną jakość moderowania treści. Zdefiniujemy X% na podstawie pomiaru wartości bazowych dla niektórych popularnych narzędzi moderatorskich, na które możemy być ukierunkowani w tym strumieniu pracy. Istotny wpływ na decyzję o priorytetach tego KR będzie mieć Lista życzeń społeczności. 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 | Do końca 2. kwartału wspierać będziemy organizatorów, uczestników i instytucje specjalnymi narzędziami, wnioskami i podejściami organizacyjnymi, które zwiększą zasięg wysokiej jakości treści w kluczowych obszarach tematycznych [do ustalenia] o X%. | W tym KR chodzi o poprawę pokrycia tematycznego treści w celu zmniejszenia istniejących luk w wiedzy. Ustalono, że społeczności korzystają na istnieniu skutecznych narzędzi i kampanii edycyjnych mających na celu zwiększenie jakości treści w naszych projektach. W tym roku chcemy skupić się na ulepszaniu istniejących narzędzi i eksperymentowaniu z nowymi sposobami priorytetyzowania kluczowych obszarów tematycznych, które zmniejszają luki w wiedzy. Nasz cel wzrostu pokrycia wiedzy o X% zostanie określony poprzez analizę istniejących bazowych wartości dotyczących tworzenia treści wysokiej jakości. Tematykę, na której będziemy się skupiać w ramach społeczności i instytucji, będziemy określać w przyszłym kwartale. Our target 138 articles will be determined by looking at existing baselines of quality content creation. |
Purity Waigi & Fiona Romeo |
| WE2.2 | Do końca 2. kwartału wdrożyć i przetestować dwa zalecenia, zarówno społeczne, jak i techniczne, w celu wspierania integracji języków w małych społecznościach, z oceną analizującą opinie społeczności. | Istnieje ponad 300 edycji językowych Wikipedii. A jednak istnieje o wiele więcej języków, którymi posługują się miliony ludzi i w których nie ma Wikipedii ani w ogóle serwisu wiki. Stanowi to przeszkodę w realizacji naszej wizji: że każdy człowiek może swobodnie dzielić się sumą wszelkiej wiedzy. Wikimedia Incubator to miejsce, w którym można organizować, pisać, testować i sprawdzać, czy wiki potencjalnych projektów Wikimedia w nowych wersjach językowych nadają się do hostowania przez WMF. Inkubator został uruchomiony w 2006 roku przy założeniu, że jego użytkownicy będą mieli wcześniejszą wiedzę z zakresu edycji wiki. Problem ten pogłębia jednak fakt, że proces ten powinien być wykonywany głównie przez osoby najnowsze i najmniej doświadczone w naszym ruchu. Chociaż od tego czasu edytowanie wiki Wikimedia znacznie się poprawiło, Inkubator nie otrzymał aktualizacji z powodu ograniczeń technicznych. Obecnie wiki potrzebuje kilku tygodni, aby wyjść z Inkubatora i każdego roku powstaje tylko około 12 nowych językowych, co wskazuje na znaczne wąskie gardło.
Istniejące badania i materiały ujawniają wyzwania techniczne na każdym etapie wdrażania nowego języka: dodawanie nowych języków do Inkubatora, złożoność w opracowywaniu i przeglądaniu treści oraz powolny proces tworzenia wiki po wyjściu z Inkubatora na własną platformę językową. Każda faza jest powolna i złożona, a do tego wymaga wiele ręcznej pracy, co wskazuje na potrzebę ulepszeń. Rozwiązanie tego problemu umożliwi szybsze i łatwiejsze tworzenie wiki w nowych językach oraz umożliwi dzielenie się wiedzą przez większą liczbę osób. Interesariusze oraz prowadzone badania i zasoby zwróciły uwagę na proponowane rekomendacje zarówno pod względem społecznym, jak i technicznym. Ten kluczowy rezultat sugeruje przetestowanie dwóch zaleceń, zarówno społecznych, jak i technicznych, oraz ocenę opinii społeczności. |
Satdeep Gill & Mary Munyoki |
| WE2.3 | Do końca 2. kwartału, 2 nowe funkcje poprowadzą uczestników do dodawania materiałów źródłowych zgodnych z wytycznymi projektu, a 3-5 partnerów przekaże materiały źródłowe, które odniosą się do luk językowych i geograficznych. | Aby zwiększyć dostęp do wysokiej jakości materiałów źródłowych potrzebnych do zmniejszenia strategicznych luki w wiedzy, podejmiemy następujące działania:
|
Fiona Romeo & Alexandra Ugolnikova |
| WE2.4 | Do końca 2. kwartału, wdrożenie Wikifunctions na co najmniej jednej Wikipedii w małym języku, by doprowadzić do lepszej skalowalności dodawania nowej wiedzy. | By skutecznie redukować luki w wiedzy, niezbędne jest usprawnienie metod pracy wspierających skalowalny przyrost wysokojakościowej wiedzy, szczególnie w mniejszych społecznościach językowych. | Amy Tsay |
| WE3.1 | Wdrożenie dwóch nadzorowanych, dostępnych i pochodzących od społeczności doświadczeń z przeglądania treści na reprezentatywnych wiki. Celem będzie zwiększenie retencji niezalogowanych czytelników o 5%. | Ten KR skupia się na zwiększeniu retencji nowego pokolenia czytelników na naszego serwisu, umożliwiając nowemu pokoleniu zbudowanie trwałego połączenia z Wikipedią, poprzez badanie możliwości łatwiejszego odkrywania i uczenia się treści, które interesują czytelników. Będzie to obejmować eksplorację i rozwój nowych, wyselekcjonowanych, spersonalizowanych i kierowanych przez społeczność możliwości przeglądania i uczenia się (na przykład kanały z odpowiednią treścią, rekomendacje i sugestie dotyczące treści tematycznych, możliwości eksploracji treści wyselekcjonowanych przez społeczność itp.).
Planujemy rozpocząć rok finansowy od przeprowadzenia serii eksperymentów związanych z czytelnictwem, aby określić, które elementy chcielibyśmy skalować do użytku produkcyjnego i na jakiej platformie (strona, apka lub jedno i drugie). Następnie skupimy się na skalowaniu tych eksperymentów i testowaniu ich skuteczności w zwiększaniu retencji w środowiskach produkcyjnych. Naszym celem do końca roku jest uruchomienie co najmniej dwóch doświadczeń na reprezentatywnych wiki i dokładne zmierzenie 5% wzrostu retencji czytelników w przypadku czytelników zaangażowanych w te doświadczenia. Aby osiągnąć skutecznie ten KR, będziemy potrzebować możliwości testowania A/B z użytkownikami zalogowanymi, a także instrumentów zdolnych do pomiaru retencji czytelników. Możemy również potrzebować nowych API lub usług niezbędnych do przedstawienia zaleceń i innych mechanizmów tworzenia treści. |
Olga Vasileva |
| WE3.2 | 50% wzrost na platformę liczby darowizn za pośrednictwem punktów dotykowych poza corocznym banerem i e-mailami. | Naszym celem jest zapewnienie różnorodności źródeł dochodów przy jednoczesnym uznaniu naszych dotychczasowych darczyńców. Na podstawie informacji zwrotnych i danych skupiamy się na zwiększeniu liczby darowizn poza metodami, na których Fundacja polegała w przeszłości, a w szczególności poza rocznym bannerem. Chcemy pokazać, że poprzez inwestowanie w bardziej zintegrowane doświadczenia darczyńców, możemy utrzymać naszą pracę i rozszerzyć nasz wpływ, zapewniając alternatywę dla istniejących i potencjalnych darczyńców, którzy nie reagują na banery. Początkowym szacunkiem opartym na zmniejszonej widoczności przycisku przekazywania darowizny w działaniach programu Vector 2022 jest 50% przyrost darowizn oraz wzrost liczby wpłat z projektu pilotażowego w latach fiskalnych 2023-2024 na aplikacjach Wikipedii w celu poprawy doświadczeń darczyńców (50,1% wzrost wpłat). Ocena tej metryki per platforma pomoże nam zrozumieć trendy w platformach i to, czy w przyszłości powinny być wdrożone inne taktyki w oparciu o różnice w zachowaniu użytkowników platformy. | 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 | Przedstawić 3 środki przeciwdziałania nękaniu i szkodliwym treściom, które będą wprowadzone na podstawie danych i zgodne z zmieniającym się środowiskiem prawnym, do 3. kwartału. | Zapewnienie bezpieczeństwa i dobrego samopoczucia użytkowników jest podstawowym obowiązkiem platform internetowych. W wielu jurysdykcjach obowiązują przepisy i regulacje wymagające od platform internetowych podejmowania działań przeciwko nękaniu, cyberprzemocy i innym szkodliwym treściom. Niezastosowanie się do nich może narazić platformy na odpowiedzialność prawną i sankcje regulacyjne.
W tej chwili nie mamy zbyt dobrego pojęcia, jak duże są te problemy ani jakie są ich przyczyny. W dużym stopniu opieramy się na dowodach niepotwierdzonych i ręcznie prowadzonych procesach, które narażają nas zarówno na ryzyko prawne, jak i inne dalekosiężne konsekwencje: niedoszacowanie problemu, eskalację szkód, utratę reputacji i spadek zaufania użytkowników. Musimy stworzyć silną kulturę pomiaru częstotliwości nękania i występowania szkodliwych treści oraz aktywnie wdrażać środki zaradcze. |
Madalina Ana |
| WE4.2 | Opracowanie co najmniej dwóch sygnałów do wykorzystania w procesach przeciwdziałania nękaniu, aby do trzeciego kwartału poprawić precyzję działań wobec podejrzanych podmiotów. | Wiki w dużym stopniu opierają się na blokowaniu adresów IP jako mechanizmie blokowania wandalizmów, spamu i nadużyć. Adresy IP są jednak coraz mniej przydatne jako stabilne identyfikatory poszczególnych aktorów, a blokowanie adresów IP ma niezamierzone negatywne skutki dla użytkowników działających w dobrej wierze, którzy akurat korzystają z tego samego adresu IP co nieuczciwi aktorzy. Połączenie malejącej stabilności adresów IP i naszej dużej zależności od blokowania adresów IP skutkuje mniejszą precyzją i skutecznością w eliminowaniu złych aktorów, w połączeniu z rosnącym poziomem szkód ubocznych ponoszonych przez użytkowników działających w dobrej wierze. Chcielibyśmy, aby sytuacja była odwrotna: zmniejszony poziom szkód ubocznych i większa precyzja w działaniach łagodzących wymierzonych w złe podmioty.
Lepsze wspieranie pracy funkcjonariuszy w zakresie przeciwdziałania nadużyciom i zapewnienie elementów składowych do ponownego wykorzystania w istniejących (np. CheckUser, Special:Block) i nowych narzędziach. W tym KR proponujemy zbadać sposoby wiarygodnego skojarzenia danej osoby z jej działaniami (łagodzenie efektu pacynkowania) i łączyć istniejące sygnały (np. adresy IP, historię konta, atrybuty komunikacji), aby umożliwić bardziej precyzyjne ukierunkowanie działań na nieuczciwych aktorów. |
Kosta Harlan |
| WE4.3 | Zmniejszenie skuteczności rozproszonego ataku na dużą skalę o 50%, mierząc działanie czasem potrzebnym na dostosowanie naszych środków i natężeniem ruchu, jaki możemy utrzymać w symulacji. | Ewolucja krajobrazu Internetu, w tym rozwój botnetów na dużą skalę i częstsze ataki, sprawiły, że nasze tradycyjne metody ograniczania nadużyć na dużą skalę stały się przestarzałe. Takie ataki mogą spowodować, że nasze witryny będą niedostępne poprzez zalanie naszej infrastruktury żądaniami lub przeciążenie zdolności naszej społeczności do zwalczania wandalizmów na dużą skalę. Stanowi to również nieuzasadnione obciążenie dla naszych redaktorów o wysokich uprawnieniach i naszej społeczności technicznej.
Musimy pilnie poprawić naszą zdolność do automatycznego wykrywania, przeciwstawiania się i łagodzenia lub powstrzymywania takich ataków. Aby zmierzyć naszą poprawę, nie możemy polegać wyłącznie na częstotliwości/intensywności rzeczywistych ataków, ponieważ bylibyśmy zależni od działań zewnętrznych i trudno byłoby uzyskać jasny ilościowy obraz naszego postępu. Konfigurując wiele symulowanych ataków o różnym charakterze/złożoności/czasie trwania, które będą bezpiecznie przeprowadzane na naszej infrastrukturze testowej i przeprowadzając je co kwartał, będziemy mogli zarówno przetestować nasze nowe środki zaradcze, gdy nie jesteśmy atakowani, jak i obiektywnie zgłaszać nasze ulepszenia. |
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 | Do trzeciego kwartału zakończenie co najmniej pięciu działań mających na celu zwiększenie zrównoważonego rozwoju platformy. | Zrównoważony rozwój platformy MediaWiki to ciągły wysiłek ważny dla naszej zdolności do skalowania, zwiększania lub unikania pogorszenia satysfakcji programistów oraz rozwoju naszej społeczności technicznej. Jest to trudne do zmierzenia i zależy od czynników technicznych i społecznych. Posiadamy jednak wiedzę na temat konkretnych obszarów ulepszeń, które są strategiczne dla zrównoważonego rozwoju. Planowane interwencje mogą pomóc zwiększyć trwałość i łatwość konserwacji platformy lub zapobiec jej degradacji. Planujemy ocenić wpływ tych prac w czwartym kwartale, przedstawiając zalecenia dotyczące celów zrównoważonego rozwoju w przyszłości. Przykłady działań na rzecz zrównoważonego rozwoju obejmują: upraszczanie złożonych domen kodu, które są podstawą MediaWiki, ale co do działania których wiedzę posiada jedynie garstka osób; zwiększenie wykorzystania narzędzi do analizy kodu w celu informowania o jakości naszej bazy kodu; usprawnienie procesów takich, jak składanie pakietów oprogramowania i ich publikacja. | Mateus Santos |
| WE5.2 | Zidentyfikowanie do drugiego kwartału i ukończenie do czwartego kwartału jednej lub więcej interwencji w celu ewolucji interfejsów programistycznych ekosystemu MediaWiki, aby umożliwić niezależny, prostszy i bardziej zrównoważony rozwój funkcji. | Głównym celem KR 5.2 jest ulepszenie i wyjaśnienie interakcji pomiędzy podstawową platformą MediaWiki a jej rozszerzeniami, skórkami i innymi częściami. Naszym zamiarem jest zapewnienie ulepszeń funkcjonalnych architektury MediaWiki, które umożliwią praktyczną modularność i łatwość konserwacji, dla których łatwiej jest opracowywać rozszerzenia, a także takich, które wzmocnią wymagania wynikające z szerszej wizji produktu MediaWiki. Ta praca ma również na celu poinformowanie, co powinno istnieć (lub nie) w samym MediaWiki, rozszerzeniach lub interfejsach między nimi. Rok zostanie podzielony na dwie fazy: pięciomiesięczną fazę badań i eksperymentów, która stanie się podstawą drugiej fazy, w której zostaną wdrożone określone konkretne interwencje. | Jonathan Tweed |
| WE5.3 | Do końca drugiego kwartału: ukończenie jednej inicjatywy polegającej na gromadzeniu danych i jednego eksperymentu dotyczącego poprawy wydajności, aby uzyskać informacje na temat dalszych interwencji w zakresie produktów i platform w celu wykorzystania możliwości odblokowanych dzięki modelowaniu strony przez MediaWiki jako kompozycji ustrukturyzowanych fragmentów. | Głównym celem jest umożliwienie programistom i menedżerom produktu wykorzystania nowych możliwości platformy MediaWiki w celu zaspokojenia obecnych i przyszłych potrzeb w zakresie treści encyklopedycznych poprzez udostępnienie nowych ofert produktów, które są obecnie trudne do wdrożenia, a także poprawę wydajności i odporności platformy.
W szczególności, na poziomie platformy MediaWiki chcemy zmienić model przetwarzania MediaWiki z traktowania strony jako monolitycznej jednostki na traktowanie strony jako kompozycji jednostek treści strukturalnej. Widoki oparte na Parsoidzie, integracja z Wikidanymi i integracja z Wikifunctions są krokami w tym właśnie kierunku. W ramach niniejszych Kluczowych Wyników chcemy w bardziej świadomy sposób eksperymentować i gromadzić dane, aby informować o przyszłych interwencjach w oparciu o te nowe możliwości, aby też mieć pewność, że uda nam się osiągnąć zamierzony wpływ na infrastrukturę i produkt. |
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 | Rozwiniecie 5 pytań, aby umożliwić podejmowanie efektywnych i świadomych decyzji dotyczących przepływów pracy i usług dla programistów i inżynierów, a także udostępnienie odpowiednich danych do końca czwartego kwartału. | „To skomplikowane” to częsta odpowiedź na pytania typu „które repozytoria są wykorzystywane w produkcji Wikimedia?”. W tym KR przyjrzymy się niektórym z naszych „evergreenów” w dziedzinie produktywności i doświadczenia inżynierskiego – powtarzających się pytań, które wydają się łatwe, ale trudno na nie odpowiedzieć, pytań, na które możemy odpowiedzieć, ale dane nie są dostępne i wymagają niestandardowych tematycznych zapytań ekspertów w danej dziedzinie lub pytań, na które uzyskanie odpowiedzi jest kłopotliwe ze względu na luki w procesie lub z innych powodów. Zdefiniujemy, co oznacza „rozwiązać” dla każdego z pytań: dla niektórych może to oznaczać po prostu udostępnienie istniejących, dokładnych danych. Rozwiązanie innych kwestii będzie wymagało więcej czasu na badania i prace inżynieryjne. Nadrzędnym celem tej pracy jest skrócenie czasu, obejść problemów i wysiłku potrzebnych do uzyskania wglądu w kluczowe aspekty doświadczenia programistów i umożliwienie nam wprowadzenia ulepszeń w przepływach pracy i usługach inżynieryjnych i programistycznych. | [TBD] |
| WE6.2 | Do czwartego kwartału ulepszenie istniejącego projektu i przeprowadzenie co najmniej dwóch eksperymentów mających na celu zapewnienie łatwych w utrzymaniu, ukierunkowanych środowisk, które poprowadzą nas w kierunku bezpiecznych, pół-automatycznych dostaw oprogramowania. | Programiści i użytkownicy polegają na Wikimedia Beta Cluster (beta), aby wychwytywać błędy, zanim wpłyną one na użytkowników w środowisku produkcyjnym. Z biegiem czasu zastosowania wersji beta wzrosły i zaczęły wywoływać konflikty — zastosowania są zbyt różnorodne, aby zmieściły się w jednym środowisku. Ulepszymy jedno istniejące alternatywne środowisko i przeprowadzimy eksperymenty mające na celu zastąpienie pojedynczej potrzeby testowej o wysokim priorytecie, obecnie spełnianej przez wersję beta, łatwym w utrzymaniu alternatywnym środowiskiem, które lepiej służy potrzebom każdego przypadku użycia. | 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, kluczowa platforma dla narzędzi Wikimedia tworzonych przez wolontariuszy, odgrywa kluczową rolę od edycji po ochronę przed wandalizmem. Naszym celem jest zwiększenie użyteczności Toolforge, obniżenie barier w zakresie wkładu, poprawa praktyk społecznościowych i promowanie przestrzegania ustalonych zasad. W tym celu do drugiego kwartału wprowadzimy system punktacji, który będzie oceniał zrównoważony rozwój platformy Toolforge, koncentrując się na aspektach technicznych i społecznych. Kierując się tym systemem jako wskazówką, naszym celem jest poprawa jednego z kluczowych czynników technicznych o 50%. | Slavina Stefanova |
| Kluczowe rezultaty - Signals & Data Services (Sygnały i usługi danych, SDS)
[ Wstępne cele ] | |||
|---|---|---|---|
| Skrótowa nazwa rezultatu | Opis rezultatu | Kontekst rezultatu | Właściciel |
| SDS1.1 | Liderzy 2 programów lub inicjatyw opartych na KR stworzą szeroko rozpowszechnioną dokumentację wyjaśniającą logiczny związek między pracą ich zespołu a wpływem na jeden lub więcej podstawowych wskaźników Fundacji. | Nasze podstawowe wskaźniki organizacyjne służą jako podstawa do oceny postępów Fundacji w realizacji jej celów. Podczas przydzielania zasobów do programów i projektowania strumieni pracy zorientowanych na kluczowe wyniki (KR), te wysokopoziomowe wskaźniki powinny wskazywać, w jaki sposób łączymy te inwestycje z nadrzędnymi celami Fundacji określonymi w planie rocznym. Praca nad tym kluczowym rezultatem potwierdza, że Fundacja jako całość znajduje się na wczesnym etapie swojej zdolności do ilościowego powiązania wpływu wszystkich planowanych interwencji z wysokopoziomowymi lub podstawowymi wskaźnikami. Dążąc do tego ostatecznego celu, niniejszy KR ma na celu opracowanie procesu, w ramach którego dzielimy się logicznymi i teoretycznymi powiązaniami między naszymi inicjatywami a wysokopoziomowymi wskaźnikami. W praktyce oznacza to współpracę z właścicielami inicjatyw w całej Fundacji w celu zrozumienia, w jaki sposób wyniki ich pracy na poziomie projektu są powiązane i wpływają na nasze podstawowe wskaźniki na poziomie Fundacji. Aby zapewnić spójność w dokumentowaniu potencjalnego wpływu pracy, zastosowane zostaną ramy i ćwiczenia mapowania wpływu, takie jak "mapowanie teorii zmian" i tworzenie wykresów przyczynowo-skutkowych. Aby zrealizować ten kluczowy rezultat, będziemy również musieli opracować materiały pomocnicze, które pomogą właścicielom inicjatyw zrozumieć wskaźniki organizacyjne i zrozumieć, jak tworzyć teorie zmian związane z ich pracą. |
Omari Sefu |
| SDS1.2 | Odpowiedzi na 2 strategiczne otwarte pytania badawcze do grudnia 2024, aby przedstawić rekomendacje lub informacje dotyczące rocznego planowania na rok 2026. | W ekosystemie Wikimedia istnieje wiele otwartych pytań badawczych, a udzielenie odpowiedzi na niektóre z nich ma strategiczne znaczenie dla WMF lub afiliantów. Odpowiedzi na te pytania mogą stanowić podstawę przyszłego rozwoju produktów lub technologii lub mogą wspierać proces decyzyjny/rzecznictwo w przestrzeni politycznej. Chociaż na niektóre z tych pytań można odpowiedzieć, wykorzystując wyłącznie wiedzę naukową lub inżynierię badawczą, biorąc pod uwagę społeczno-techniczny charakter projektów Wikimedia, uzyskanie wiarygodnych wniosków często wymaga współpracy między zespołami w celu gromadzenia danych, budowania kontekstu, interakcji z użytkownikiem, starannego projektowania eksperymentów i nie tylko. Za pomocą tego KR staramy się nadać priorytet niektórym naszym zasobom, aby odpowiedzieć na jedno lub więcej takich pytań.
Praca w ramach tego KR obejmuje ustalenie priorytetów listy strategicznych pytań otwartych, a także wykonanie prac eksperymentalnych w celu znalezienia odpowiedzi na X z nich (obecnie szacunkowo 2). Idealnym rodzajem pytań, którymi zajmiemy się w tym KR, są pytania, które po udzieleniu odpowiedzi mogą odblokować jakiś efekt, umożliwiając wielu innym zespołom lub grupom pracę (lepiej? świadomie?) z produktem, technologią lub zasadami. Zamierzamy, aby prace w ramach tego KR miały charakter uzupełniający w stosunku do następujących KR:
|
Leila Zia |
| SDS1.3 | Osiągnięcie co najmniej 50% redukcji średniego czasu potrzebnego interesariuszom danych na zrozumienie i śledzenie przepływów danych w przypadku 3 podstawowych i niezbędnych wskaźników | Wymagane dla standardów Zarządzania Danymi.
Śledzenie transformacji i źródła zbiorów danych jest trudne i wymaga znajomości różnych repozytoriów i systemów. Powinniśmy ułatwić zrozumienie sposobu przepływu danych w naszych systemach, aby zainteresowane strony mogły pracować w sposób bardziej samoobsługowy. Ta praca będzie wspierać przepływy pracy, w których dane są przekształcane i wykorzystywane do celów analitycznych, budowy funkcji, interfejsów API i zadań związanych z jakością danych. Nastąpi kontynuacja KR dotycząca dokumentowania wskaźników. |
Luke Bowmaker |
| SDS2.1 | Do końca drugiego kwartału możemy wesprzeć 1 zespół produktowy w ocenie funkcji lub produktu za pomocą podstawowych testów A/B, które skracają czas potrzebny na uzyskanie danych o interakcji z użytkownikiem o 50%. | Uważamy, że korzystanie ze wspólnych narzędzi zwiększy pewność zespołów produktowych w podejmowaniu decyzji w oparciu o dane, poprawi wydajność i produktywność oraz ulepszy strategię produktu i innowacyjność. Przyjrzymy się przyjęciu bazowych danych dotyczących indywidualnego czasu interakcji użytkownika przez zespół i poprawimy go o 50%. Zbadamy również, w jaki sposób możemy skontekstualizować te korzyści w pełniejszym kontekście wszystkich zespołów produktowych. Oczekujemy, że dowiemy się, jak możemy ulepszyć doświadczenie użytkownika oraz zidentyfikować i ustalić priorytety ulepszeń możliwości platformy w oparciu o opinie zespołu wdrażającego i wyniki SDS2.2. |
Virginia Poundstone |
| SDS2.2 | Do końca drugiego kwartału będziemy mieli 2 podstawowe wskaźniki do analizy eksperymentów (testy A/B) w celu wsparcia testowania hipotez dotyczących produktów/funkcji związanych z KR na lata 24-25. | Kiedy menedżer produktu (lub projektant) ma hipotezę, że produkt/funkcja rozwiąże problem/potrzebę użytkowników lub organizacji, eksperyment polega na tym, jak testuje się tę hipotezę i poznaje potencjalny wpływ pomysłu na metrykę. Wyniki eksperymentu informują menedżera produktu i pomagają mu podjąć decyzję, jakie dalsze działania podjąć (porzucić ten pomysł i wypróbować inną hipotezę, kontynuować rozwój, jeśli eksperyment przeprowadzono na wczesnym etapie cyklu rozwoju, lub wypuścić produkt/funkcję większej liczbie użytkowników). Menedżerowie produktu muszą móc podjąć taką decyzję z pewnością, popartą dowodami, którym ufają i które rozumieją.
Główną przeszkodą jest to, że zespoły produktowe formułują obecnie swoje hipotezy na podstawie niestandardowych wskaźników specyficznych dla projektu, które wymagają dedykowanego wsparcia analityka w celu ich zdefiniowania, pomiaru, analizy i raportowania na ich temat. Przejście na zestaw podstawowych metryk do formułowania wszystkich testowalnych hipotez dotyczących produktu/cechy spowodowałoby, że:
Uważamy, że zestaw podstawowych wskaźników, które są szeroko rozumiane i konsekwentnie stosowane – oraz na które wpływają standardowe wskaźniki branżowe lub które wpływają na standardowe wskaźniki – poprawiłyby również organizacyjną umiejętność korzystania z danych i promowały kulturę przeglądu, eksperymentowania i uczenia się. Koncentrujemy się na podstawowych metrykach, które (1) są potrzebne do najlepszego pomiaru i oceny sukcesu/wpływu produktów/cech związanych z 2 KR Doświadczeń Wiki – WE3.1 i WE1.2 – oraz (2) odzwierciedlają lub mapują do branży standardowe wskaźniki stosowane w analityce internetowej. |
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 |
| Kluczowe rezultaty - przyszli odbiorcy (FA)
[ Wstępne cele ] | |||
|---|---|---|---|
| Skrótowa nazwa rezultatu | Opis rezultatu | Kontekst rezultatu | Właściciel |
| FA1.1 | W wyniku eksperymentalnych spostrzeżeń i zaleceń Future Audiences (przyszli odbiorcy, FA) do końca trzeciego kwartału co najmniej jeden cel lub kluczowy wynik należący do zespołu spoza Future Audiences będzie obecny w projekcie planu rocznego na kolejny rok. | Od 2020 roku WMF śledzi trendy zewnętrzne które mogą mieć wpływ na naszą zdolność do służenia przyszłym pokoleniom konsumentów wiedzy i twórców wiedzy oraz pozostania rozwijającym się ruchem wolnej wiedzy dla przyszłych pokoleń. Future Audiences, mały zespół badawczo-rozwojowy, będzie:
|
Maryana Pinchuk |
| Kluczowe rezultaty - wsparcie produktu i inżynierii (PES)
[ Wstępne cele ] | |||
|---|---|---|---|
| Skrótowa nazwa rezultatu | Opis rezultatu | Kontekst rezultatu | Właściciel |
| PES1.1 | Kultura przeglądu: Stopniowa poprawa wyników nastrojów personelu P+T w odniesieniu do dostawy produktu, dostosowania, kierunku i kondycji zespołu w kwartalnej ankiecie. | Kultura przeglądu to kultura rozwoju produktu oparta na krótszych cyklach iteracji, uczenia się i adaptacji. Oznacza to, że nasza organizacja może wyznaczać cele roczne, ale to, co robimy, aby je osiągnąć, będzie się zmieniać i dostosowywać w ciągu roku, w miarę zdobywania wiedzy. Na budowanie kultury przeglądu składają się dwa elementy: procesy i zachowania. W niniejszym KR skupiono się na tym drugim. Zmiany w zachowaniu mogą się rozwijać i wzmacniać naszą kulturę przeglądu. Wiąże się to ze zmianami indywidualnych nawyków i procedur w miarę zbliżania się do bardziej iteracyjnego rozwoju produktu. KR będzie opierał się na zgłaszanych przez samych pracowników zmianach w indywidualnych zachowaniach i pomiarze wynikających z nich zmian, jeśli takie wystąpią, w nastrojach personelu. | Amy Tsay |
| PES1.2 | Do końca drugiego kwartału nowa Lista życzeń lepiej łącząca pomysły i prośby pochodzące z ruchu Wikimedia z działaniami Fundacji i zespołu P+T: pozycje z listy życzeń są opracowywane za pośrednictwem KR na lata 2024–25, Fundacja zrealizuje w tym czasie 10 pomniejszych życzeń i zawrze współpracę z wolontariuszami celem zidentyfikowania co najmniej 3 obszarów rozwoju na rok 2025-26. | Lista życzeń społeczności reprezentuje wąski wycinek tego ruchu; uczestniczy w nim około 1 tys. osób, z których większość to edytorzy lub administratorzy. Ludzie często omijają listę życzeń, pisząc prośby o nowe funkcje i raporty o błędach za pośrednictwem Phabricatora, gdzie trudno jest rozpoznać prośby WMF od wniosków ze społeczności. Dla edytorów, Lista życzeń jest kosztowną inwestycją czasu przy minimalnym zysku. Nadal korzystają z niej, ponieważ uważają, że jest to jedyne narzędzie, które zwraca uwagę na istotne błędy i ulepszenia funkcji lub sygnalizuje potrzebę szerszych, strategicznych możliwości. Życzenia są często zapisywane jako rozwiązania, a nie problemy. Rozwiązania mogą wydawać się rozsądne na papierze, ale niekoniecznie uwzględniają złożoność techniczną lub implikacje strategii Ruchu.
Zakres i szerokość życzeń czasami przekracza zakres i możliwości zespołu Community Tech lub dowolnego innego zespołu, utrwalając frustrację, prowadząc do RFC i wezwań do usunięcia Listy życzeń. Podczas gdy członkowie społeczności wolą korzystać z listy życzeń w przypadku pomysłów na projekty, zespoły w Fundacji przyglądają się Liście życzeń i innym procesom przyjmowania w celu ustalenia priorytetów, po części dlatego, że życzenia są nieodpowiednie w czasie planowania rocznego i trudno je uwzględnić w planach działania. Przyszła Lista życzeń powinna być pomostem pomiędzy społecznością a Fundacją, gdzie społeczności wnoszą wkład w zorganizowany sposób, abyśmy mogli podjąć działania, a co za tym idzie, uszczęśliwić wolontariuszy. Tworzymy nowy proces przyjmowania życzeń, dzięki któremu każdy zalogowany wolontariusz może złożyć swoje życzenie 365 dni w roku. Użytkownicy publikujący owe życzenia mogą zgłosić lub uwidocznić błąd, poprosić o ulepszenie lub zaproponować nową funkcję. Każdy może komentować, uczestniczyć w warsztatach lub wspierać chęć wpływania na ustalanie priorytetów. Fundacja nie będzie kategoryzować życzeń jako „za duże” lub „za małe”. Życzenia, które tematycznie odnoszą się do większego obszaru problemowego, mogą wpłynąć na roczne planowanie i plany działania zespołu, oferując strategiczne kierunki i możliwości. Życzenia będą widoczne dla Ruchu na pulpicie nawigacyjnym, który kategoryzuje je według projektu, obszaru produktu/problemu i rodzaju życzeń. Fundacja będzie reagować na życzenia w odpowiednim czasie i współpracować ze Społecznością w celu kategoryzowania i ustalania priorytetów życzeń. Będziemy współpracować z wikimedianami, aby zidentyfikować i nadać priorytet trzem obszarom ulepszeń, uwzględnionym w rocznym planie Fundacji na lata 2025-26, które powinny poprawić wskaźnik przyjęcia i realizację wpływowych życzeń. Będziemy oznaczać dobrze sformułowane życzenia dla społeczności programistów-wolontariuszy i zespołów Fundacji, co doprowadzi do większego zaangażowania zespołu i programistów oraz większej liczby spełnionych życzeń, co z kolei doprowadzi do zadowolenia społeczności. Spełnianie większej liczby życzeń poprawia zadowolenie, skuteczność i retencję twórców, co powinno generować więcej wartościowych edycji, wyższą jakość treści i większą liczbę czytelników. |
Jack Wheeler |
| PES1.3 | Przeprowadzić i zakończyć dwa eksperymenty z wykorzystaniem istniejących produktów/funkcji eksploracyjnych, które dostarczą nam danych/wglądu w to, w jaki sposób rozwijamy Wikipedię jako miejsce wiedzy dla naszych obecnych konsumentów i wolontariuszy w pierwszym i drugim kwartale. Uzupełnienie i podzielenie się wnioskami i zaleceniami do potencjalnego zastosowania w przyszłych pracach OKR w segmencie Wiki Experiences do końca trzeciego kwartału. | Ta praca jest odpowiednikiem celu w obszarze Przyszłych odbiorców, ale koncentruje się na odkrywaniu możliwości zwiększenia i pogłębienia zaangażowania naszych obecnych odbiorców (konsumentów i autorów Wikipedii) poprzez sprawniejsze testowanie większej liczby pomysłów na produkty na platformie.
Działa w PES1, ponieważ dodaje energii i mnoży działania, wykorzystując czas, który pojedyncze osoby i zespoły „już” poświęciły na projektowanie/eksperymentowanie w projektach pobocznych, aby skupić się na bardziej obiecujących funkcjach. Zamiast marnowania tych pobocznych projektów (nie jest to dobre wykorzystanie naszych ograniczonych zasobów), niniejszy KR zapewnia niektórym z tych pomysłów drogę do potencjalnego przekształcenia się w szersze środowisko poprzez sprawdzone eksperymenty, a tym samym efektywniejsze wykorzystanie czasu pracowników i motywowanie ich kreatywności i wydajności. Wprowadzając w życie więcej takich mniejszych, krótszych projektów, dywersyfikujemy także nasze rozpowszechnianie „losów”, aby uzyskać więcej wiedzy i prób pomysłów, które mogą przekształcić Wikipedię zgodnie ze zmieniającymi się potrzebami i oczekiwaniami naszych obecnych odbiorców. Dzięki temu nasza praca będzie skuteczniejsza i szybsza, ponieważ pomoże Fundacji osiągnąć właściwy cel w krótszym czasie. |
Rita Ho |
| PES1.4 | Dowiedzenie się, jak: ustalać, monitorować i podejmować decyzje dotyczące SLO. Wybranie przynajmniej jednej nowej rzeczy, dla której zdefiniowane zostanie SLO, gdy ją udostępnimy. Współpraca z odpowiednimi zespołami (zwykle: zespołami ds. produktu, programistów, SRE), aby zdefiniować ten SLO. Zastanowienie się i udokumentowanie wytycznych dotyczących tego, jakie wydania oprogramowania powinny mieć poziomy docelowego poziomu usług w przyszłości i jak je ustawić. | PRZYSZŁY KR:
Konfiguracja procesów i podstawowych narzędzi do ustawiania i monitorowania docelowych poziomów usług dla nowych wydań. Sprawozdania będą kwartalne i wykorzystane będą do podejmowania decyzji, kiedy (a kiedy nie) nadawać priorytet pracy w celu naprawienia czegoś. Raporty bedą udostępnione społeczności. CZEMU: Nie wiemy, kiedy musimy nadać priorytet działaniom, aby coś naprawić. Mamy też mnóstwo kodu. W miarę jak ten ślad stale rośnie, pojawia się coraz więcej sytuacji, w których możemy być zmuszeni podjąć decyzję między rozwiązaniem problemów a skupieniem się na innowacjach, a do tego wzrasta niepewność co do tego, kiedy powinniśmy to zrobić. Ponadto nie jest jasne dla personelu i społeczności, jaki jest nasz poziom wsparcia/zaangażowania w niezawodność i wydajność w przypadku wszystkich różnych funkcji i funkcjonalności, z którymi współdziała nasze oprogramowanie. Jeśli zdefiniujemy oczekiwany poziom usług, będziemy wiedzieć, kiedy powinniśmy przeznaczyć na niego zasoby, a kiedy nie. |
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. | phab:T370117 |
| 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. | zadanie 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. | Rabbit Holes |
| 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. | zadanie 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 | |
Wyjaśnienie "koszyków"
Doświadczenie wiki
Celem tego koszyka jest efektywne dostarczanie, ulepszanie i wprowadzanie innowacji w środowiskach wiki, które umożliwiają dystrybucję bezpłatnej wiedzy na całym świecie. Ten Koszyk jest zgodny z zaleceniami dotyczącymi strategii Ruchu #2 (Popraw doświadczenie użytkownika) i #3 (Zapewnij bezpieczeństwo i integrację). Naszymi odbiorcami są wszyscy edytorzy na naszych stronach internetowych, a także czytelnicy i inni konsumenci bezpłatnej wiedzy. Obsługujemy 10. najpopularniejszą światową witrynę internetową i wiele innych ważnych zasobów wolnej kultury. Systemy te mają wymagania dotyczące wydajności i czasu pracy porównywalne z wymaganiami największych firm technologicznych na świecie. Zapewniamy interfejsy użytkownika do wiki, tłumaczenia, interfejsy API dla programistów (i nie tylko!) oraz aplikacje pomocnicze i infrastrukturę, które tworzą solidną platformę współpracy dla wolontariuszy w celu tworzenia bezpłatnej wiedzy na całym świecie. Nasze cele w tym segmencie powinny umożliwić nam udoskonalenie naszej podstawowej technologii i możliwości, zapewnić ciągłe doskonalenie doświadczenia redaktorów i moderatorów-wolontariuszy naszych projektów, poprawić doświadczenie wszystkich współpracowników technicznych pracujących nad ulepszeniem lub udoskonaleniem środowiska wiki oraz zapewnić wspaniałe doświadczenie dla czytelników i konsumentów wolnej wiedzy na całym świecie. Będziemy to robić poprzez prace nad produktami i technologią, a także badania i marketing. Oczekujemy, że w tym segmencie będzie maksymalnie pięć celów.
Wiedzę tworzą ludzie! W rezultacie nasz roczny plan skupi się na treści, a także na osobach, które ją tworzą, oraz na tych, którzy uzyskują do niej dostęp i ją czytają.
Naszym celem jest stworzenie planu operacyjnego w oparciu o istniejącą strategię, głównie nasze hipotezy dotyczące „koła zamachowego” twórców, konsumentów i treści. Podstawowa zmiana, o którą proszę, to położenie nacisku na część "treści" w tym kole zamachowym i zbadanie, czego mogą od nas teraz potrzebować nasi moderatorzy i funkcjonariusze, w celu zidentyfikowania wskaźników zdrowia społeczności w przyszłości.
Sygnały i usługi danych
Aby spełnić Zalecenia strategii ruchu dotyczące zapewnienia równości w podejmowaniu decyzji (Zalecenie nr 4), Poprawy doświadczenia użytkownika (Zalecenie nr 2) oraz Oceny, iteracji i adaptacji (Zalecenie nr 10), decydenci z całego Ruchu Wikimedia muszą mieć dostęp do wiarygodnych, istotnych i aktualnych danych, modeli, spostrzeżeń i narzędzi, które mogą pomóc im ocenić wpływ (zarówno zrealizowany, jak i potencjalny) ich pracy i pracy ich społeczności, umożliwiając im podejmowanie lepszych decyzji strategicznych.
W koszyku Sygnały i usługi danych zidentyfikowaliśmy czterech głównych odbiorców: pracowników Wikimedia Foundation, afiliantów Wikimedia i grupy użytkowników, programistów, którzy ponownie wykorzystują nasze treści, oraz badaczy Wikimedia, po czym ustalamy priorytety i zaspokajamy potrzeby tych odbiorców w zakresie danych i spostrzeżeń. Nasza praca obejmie szereg działań: definiowanie luk, opracowywanie metryk, budowanie przepływów dla metryk obliczeniowych oraz opracowywanie doświadczeń i ścieżek eksploracji danych i sygnałów, które pomogą decydentom skuteczniej i lepiej wchodzić w interakcję z danymi i spostrzeżeniami.
Przyszli odbiorcy
.svg)
Celem tego koszyka jest zbadanie strategii wyjścia poza naszą obecną publiczność konsumentów i współpracowników, w celu prawdziwego dotarcia do każdego na świecie jako niezbędnej infrastruktury ekosystemu bezpłatnej wiedzy. Ten segment jest zgodny z Zaleceniem nr 9 dotyczącym strategii ruchu (Innowacje w wolnej wiedzy). Coraz więcej ludzi konsumuje informacje w postaciach i doświadczeniach odbiegających od naszej tradycyjnej oferty serwisu z artykułami – korzystają z asystentów głosowych, spędzają czas z wideo, korzystają z AI i nie tylko. W tym koszyku zaproponujemy i przetestujemy hipotezy dotyczące możliwych dalekich przyszłości ekosystemu wolnej wiedzy oraz tego, w jaki sposób będziemy jego podstawową infrastrukturą. Zrobimy to poprzez prace nad produktami i technologią, a także poprzez badania, partnerstwa i marketing. W miarę jak identyfikujemy obiecujące przyszłe stany, wnioski wyciągnięte z tego segmentu będą miały wpływ i będą rozszerzane w ramach koszyków nr 1 i 2 w kolejnych planach rocznych, kierując naszą ofertę produktów i technologii tam, gdzie powinna być, aby służyć przyszłym poszukiwaczom wiedzy. Nasze cele w tym segmencie powinny nas skłonić do eksperymentowania i odkrywania, skupiając się na wizji przyszłości wolnej wiedzy.
Koszyki podrzędne
Mamy także dwa inne „pod-koszyki”, które składają się z obszarów funkcji krytycznych, a także które muszą istnieć w Fundacji, aby wspierać nasze podstawowe operacje, i z których część jest wspólna z każdą organizacją zajmującą się oprogramowaniem. Te „pod-koszyki” nie będą miały własnych celów najwyższego poziomu, ale będą miały swój wkład i będą wspierać cele najwyższego poziomu innych grup. Są to:
- Podstawy infrastruktury. Ten koszyk obejmuje zespoły, które utrzymują i rozwijają nasze centra danych, platformy obliczeniowe i centra przechowywania danych, usługi do ich obsługi, narzędzia i procesy umożliwiające działanie naszych publicznych witryn i usług.
- Wsparcie produktowe i inżynieryjne. Ten koszyk obejmuje zespoły, które działają „na dużą skalę”, świadcząc usługi innym zespołom, które poprawiają produktywność i działanie innych zespołów.