Jump to content

Plan roczny Wikimedia Foundation/2025-2026/Kluczowe rezultaty - Produkt i technologia

Add links
From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs and the translation is 59% complete.
Outdated translations are marked like this.
Other languages:
Plan Roczny Wikimedia Foundation 2025–2026

Kolejny rok

Nawet gdy świat się zmienia, Wikimedia Foundation pozostaje pewna, że chcemy, aby nasza misja - bezpłatne udostępnianie i przechowywanie przydatnych informacji z projektów Wikimedia w Internecie - była przedsięwzięciem wielopokoleniowym: chcemy, aby wolna wiedza była ciągle dostępna dla wielu przyszłych pokoleń.

Internet szybko się zmienia. Nowe pokolenia zdobywają informacje za pośrednictwem filmów społecznościowych i sztucznej inteligencji, a w porównaniu ze starszymi pokoleniami, mniej z nich zna Wikipedię. Obserwujemy związane z tym spadki liczby osób odwiedzających nasze witryny i liczby osób edytujących. Tymczasem platformy w całym Internecie polegają na treściach Wikimedia, które stanowią podstawę ich ofert AI i wyszukiwania. Dynamika ta stanowi poważne wyzwanie, ale jasno pokazuje, dlaczego wiarygodna, bezpłatna wiedza, którą wspólnie tworzymy, jest tak ważna. Świat potrzebuje źródła wiarygodnej, sprawdzonej przez ludzi wiedzy bardziej niż kiedykolwiek wcześniej, a projekty Wikimedia wciąż pokazują, że mogą ją zapewnić.

Aby sprostać tym wyzwaniom w nadchodzącym roku, zbudujemy ścieżki zrównoważonego korzystania z treści Wikimedia i wprowadzimy treści Wikimedia do internetowych przestrzeni społecznościowych, w których nowe pokolenia spędzają czas. Ulepszymy nasze własne strony, aby czytelnicy chcieli do nas wracać, głęboko się angażować i wnosić swój wkład w sposób, który jest dla nich znaczący. Będziemy też inwestować w naszą zdolność do szybkiego eksperymentowania z nowymi technologiami, aby nasze tempo rozwoju dorównywało tempu, w jakim zmienia się świat.

Cel infrastrukturalny dotyczy tego, w jaki sposób platforma i doświadczenia użytkowników będą wspierać podejmowanie tych wyzwań i docieranie do większości uczestników ruchu. Nie jest to lista projektów, ale zestaw kierunków działań, które mają napędzać rozwój wolontariatu, umożliwiać wolontariuszom tworzenie wiarygodnych treści encyklopedycznych, finansować naszą misję i rozwijać naszą ofertę, aby kształtować zmieniający się internet. Więcej informacji na temat tych czterech filarów strategicznych można znaleźć tutaj.

Napędzanie rozwoju wolontariatu

Społeczność wolontariuszy jest wyjątkowym motorem napędzającym sukces projektów Wikimedia i potrzebujemy, aby była ona zdrowa i by się rozwijała. Jednak w ciągu ostatniego roku zaobserwowaliśmy stały spadek liczby nowych i powracających redaktorów projektów. Aby lepiej zrozumieć potrzeby naszych obecnych wolontariuszy i skuteczniej na nie reagować, Fundacja przekształciła listę życzeń społeczności z corocznej ankiety w proces zbierania opinii, który jest otwarty przez cały czas i dzięki któremu potrzeby użytkowników i pomysły dotyczące projektów mogą zostać uwzględnione w pracy wielu zespołów Fundacji. Życzenia pogrupowaliśmy w „obszary priorytetowe” i trzy z nich włączyliśmy do kluczowych rezultatów planu rocznego. Rozpoczęliśmy również pilotażowy program Rady Doradczej ds. Produktów i Technologii, który ma uzupełniać liczne rozmowy prowadzone przez zespoły Fundacji z członkami społeczności na wiki i poza nią przez cały rok. Ponadto zidentyfikowaliśmy możliwości przyciągnięcia nowych pokoleń do naszych projektów, takie jak fakt, że młodsze osoby chętnie uczestniczą w innych internetowych przestrzeniach społecznościowych, gdzie mają łatwy i przyjazny dla urządzeń mobilnych sposób na nawiązywanie kontaktów wokół wspólnych tematów.

W nadchodzącym roku będziemy wspierać rozwój wolontariatu, ułatwiając i zwiększając atrakcyjność udziału nowych pokoleń poprzez rozszerzenie mobilnych nowych sposobów edycji („zadania strukturalne”) oraz dodanie inteligentnych procesów pracy, które ułatwią nowym użytkownikom konstruktywne edytowanie na urządzeniach mobilnych („sprawdzanie edycji”). Aby głębiej zaangażować i zatrzymać obecnych wolontariuszy, będziemy proponować zalecane działania i zadania oraz udostępniać je w centralnym miejscu, które ułatwi organizację działań w wiki. Będziemy rozważnie wykorzystywać sztuczną inteligencję, aby wzmocnić pracę wolontariuszy, zawsze zachowując kontrolę nad procesem i priorytetowo traktując przejrzystość. Zarówno dla nowych, jak i doświadczonych wolontariuszy stworzymy możliwości nawiązywania kontaktów i współpracy na naszych stronach – inspirując się udanymi kampaniami i wikiprojektami – umożliwiając im znalezienie podobnie myślących redaktorów i ulepszanie treści związanych z ich zainteresowaniami (zgodnie z tym obszarem zainteresowań listy życzeń).

Dostarczanie godnych zaufania treści encyklopedycznych

Wraz z mnożeniem się materiałów generowanych przez sztuczną inteligencję w Internecie, świat potrzebuje bardziej niż kiedykolwiek wiarygodnych treści encyklopedycznych. Chcemy zwiększyć możliwości wolontariuszy zarówno w zakresie tworzenia nowych treści, jak i zapewnienia wiarygodności istniejących oraz dostarczania wiarygodnych treści nowemu pokoleniu czytelników o nowych potrzebach i preferencjach.

Aby pomóc wolontariuszom w tworzeniu nowych treści, będziemy rozwijać istniejące narzędzia i procesy (takie jak narzędzie do tłumaczenia treści), tak aby zarówno duże, jak i mniejsze społeczności mogły zajmować się ważnymi treściami. Aby zapewnić wiarygodność istniejących treści, pomożemy doświadczonym wolontariuszom lepiej zarządzać rosnącą ilością pracy, rozszerzając narzędzia, których używają do wyszukiwania zadań wymagających ich uwagi – ułatwiając im aktualizowanie artykułów i cofanie nieprzydatnych zmian (zgodnie z tym obszarem zainteresowań listy życzeń).

Pomożemy również użytkownikom funkcyjnym bronić naszych treści, wyświetlając nowe sygnały (poza adresami IP), które identyfikują osoby działające w złej wierze, umożliwiając blokowanie użytkowników w sposób, który minimalizuje błędne blokowanie redaktorów działających w dobrej wierze.

Aby dostarczyć treści encyklopedyczne nowemu pokoleniu, stworzymy funkcje, które pomogą nowym rodzajom czytelników łatwo zrozumieć artykuły, pomogą im znaleźć interesujące ich informacje i pozwolą im aktywnie uczestniczyć w czytaniu. Zmiany te mają na celu zachęcenie nowych czytelników Wikipedii do zostania oddanymi czytelnikami Wikipedii, a niektórych z nich do zostania darczyńcami (zgodnie z obszarem zainteresowania listy życzeń).

Dostarczanie wiarygodnych treści oznacza również wspieranie modelu „wiedzy jako usługi”, w którym cały internet czerpie z treści ekosystemu Wikimedia. W tym modelu nasza infrastruktura jest nie tylko cennym zasobem dla ludzi odwiedzających naszą stronę internetową, ale także dla firm zajmujących się wyszukiwaniem i sztuczną inteligencją, które automatycznie uzyskują dostęp do naszych treści jako podstawowych danych wejściowych i wyjściowych dla swoich produktów. Tego rodzaju firmy stanowią tylko jedno z wielu zastosowań, które w coraz większym stopniu obciążają naszą infrastrukturę. W ostatnim roku znaczny wzrost liczby żądań pochodzących z narzędzi do data scrapingu i botów sprawił, że pilnie musimy skorygować ten trend. Musimy ustanowić zrównoważone ścieżki dla programistów i ponownych użytkowników treści, aby uzyskać dostęp do treści wiedzy, tak aby ludzie mieli pierwszeństwo przed botami.

Finansowanie „darmowości" na przyszłość

Dział Produktów i Technologii odgrywa ważną rolę w zapewnieniu trwałości naszego ruchu. W nadchodzącym roku będziemy ściśle współpracować z zespołem ds. pozyskiwania funduszy, aby nasi darczyńcy mieli coraz bardziej przejrzyste i satysfakcjonujące doświadczenia. W naszych witrynach i aplikacjach mobilnych stworzymy możliwości dla czytelników, aby wyrazili swoje uznanie dla Wikipedii poprzez darowizny, a także stworzymy nowe sposoby, aby darczyńcy czuli się zauważeni i aby kontynuowali darowizny z roku na rok.

Kształtowanie zmieniającego się internetu

Aby dostarczyć darmową wiedzę każdemu na świecie, musimy spotkać się z ludźmi tam, gdzie są, z doświadczeniami, które pomogą im się uczyć. Osoby w wieku 18-24 lat mają mniejszą świadomość i sposób korzystania z Wikipedii niż pokolenia, które były przed nimi. W dużej mierze uczą się i wchodzą w interakcje z krótkimi platformami wideo, zaufanymi osobowościami online, grami społecznościowymi i, w coraz większym stopniu, aplikacjami AI. W tym roku udostępnimy Wikipedię tym odbiorcom w miejscach, w których spędzają czas online, aby znali Wikipedię jako źródło wiarygodnej i tworzonej przez ludzi wiedzy. Zwiększymy naszą obecność na popularnych platformach wideo, rozpowszechniając treści Wikipedii i generując społeczność w tych przestrzeniach. Zbadamy też pomysły na przeniesienie wiedzy z Wikipedii do gier i platform społecznościowych.

W ramach infrastruktury podzieliliśmy to na trzy obszary działania (zwane „koszykami”): doświadczenia wiki, sygnały i usługi danych oraz przyszłe grupy odbiorców. Koszyki te są takie same jak w dwóch poprzednich latach.

Podsumowując, uważamy, że plan ten spełnia kluczowy moment w historii Internetu, przygotowując nas do zapewnienia, że wolne treści nadal będą dostępne tam, gdzie były i że będą kształtowane przez wszystkie pokolenia. Nasze cele i kluczowe rezultaty pokazują strukturę i zawartość tego planu bardziej szczegółowo i czekamy na pytania i pomysły od szerszej społeczności.

Budowanie, ulepszanie i utrzymywanie infrastruktury opartej na naszych wartościach dla projektów Wikimedia i wolontariuszy

„Fundacja będzie udostępniać w Internecie bezpłatnie i bezterminowo przydatne informacje pochodzące z jej projektów”.

Zespoły ds. produktów i technologii przez cały rok poświęcają się budowaniu, ulepszaniu i utrzymywaniu infrastruktury służącej projektom Wikimedia. Inwestujemy w hosting projektów Wikimedia, opracowywanie oprogramowania open source i systemów projektowych oraz utrzymywanie i ulepszanie infrastruktury dla produktów danych i modeli sztucznej inteligencji.

Część naszej podstawowej pracy koncentruje się na podstawach tworzenia i hostingu dużej, popularnej strony internetowej. Hostujemy projekty Wikimedia w centrach danych, na serwerach i sprzęcie, który kupujemy, instalujemy i konserwujemy, połączonych ze sobą i resztą Internetu za pośrednictwem szybkiej sieci. Monitorujemy i zwiększamy przepustowość w razie potrzeby, a także odświeżamy sprzęt, gdy staje się zbyt stary. Na przykład w tym roku planujemy zwiększyć przepustowość i odświeżyć sprzęt w naszych centrach danych w Ashburn w stanie Wirginia i Carrollton w stanie Teksas.

Projektujemy i tworzymy oprogramowanie open source (w szczególności MediaWiki). Korzystamy również z wielu istniejących aplikacji, bibliotek i frameworków open source innych firm. Ważne błędy w naszym oprogramowaniu są traktowane priorytetowo i naprawiane. Utrzymanie oprogramowania open source wymaga wysoko wykwalifikowanej pracy osób posiadających specjalistyczną wiedzę w zakresie tworzenia oprogramowania open source, inżynierii niezawodności witryn (SRE), zarządzania produktami, zarządzania programami, projektowania i nie tylko. Nasi pracownicy dbają o to, aby nasze oprogramowanie i systemy były aktualne i dostosowane do ciągle zmieniającego się środowiska. Obejmuje to modernizację naszego kodu, aby nadal korzystać z poprawek bezpieczeństwa i zapewnić dobrą współpracę z nowym oprogramowaniem innych firm. Na przykład MediaWiki jest napisane w języku PHP, a w ciągu ostatniego roku przeszliśmy z PHP 7.4 na 8.1, co wymagało zmian zarówno w kodzie, jak i infrastrukturze, w której hostujemy nasze strony i usługi. W tym roku będziemy kontynuować te działania by przejść na wersję 8.3, wykorzystując doświadczenia zdobyte podczas aktualizacji do wersji 8.1 oraz opracowane narzędzia. Aktualizacja sprawi, że nasze systemy będą szybsze dla czytelników, łatwiejsze w użyciu dla pracowników i wolontariuszy oraz bezpieczniejsze dla wszystkich. Pozwoli to również zaoszczędzić czas potrzebny na przyszły rozwój dzięki ulepszeniom w zakresie bezpieczeństwa, wydajności i wsparcia, które towarzyszą aktualizacjom języka.

Aby zapewnić dostępność naszych projektów i treści w Internecie, zarówno dzisiaj, jak i w przyszłości, nasze zespoły poświęcają wiele wysiłku na zapewnienie wysokiej dostępności naszych stron i usług. Jednym z aspektów tej pracy jest odzyskiwanie danych po katastrofach lub złośliwych działaniach. Na przykład dbamy o to, aby mieć kopie zapasowe ważnych danych i być w stanie je odzyskać. Podobnie, dwa razy w roku testujemy naszą zdolność do automatycznego przełączania naszych stron między centrami danych i naprawiamy wszelkie wykryte problemy. Innym aspektem tej pracy jest identyfikowanie i dostosowywanie się do zmieniających się trendów w rodzajach i ilościach ruchu, jaki otrzymujemy. Na przykład, w związku z bezprecedensowym wzrostem liczby automatycznych scraperów, priorytetowo traktujemy prace mające na celu zapewnienie dostępności naszych stron i usług dla użytkowników ludzkich, stosując systematyczne podejście do ustanawiania norm odpowiedzialnego korzystania z naszej infrastruktury.

Nie wszystkie prace są planowane z dużym wyprzedzeniem. Reagujemy również na nieoczekiwane zdarzenia i incydenty, takie jak awarie witryn, zgłoszenia dotyczące bezpieczeństwa lub incydenty związane z bezpieczeństwem, a także ataki wandalizmu na dużą skalę na nasze projekty. Monitorujemy nasze wyniki i przeszkody w dostępności na całym świecie (w tym problemy z łącznością internetową lub blokady cenzury) oraz badamy wszelkie wykryte anomalie. Niektóre z tych nieoczekiwanych zdarzeń lub powtarzających się problemów powodują, że pracownicy nadają priorytet krótkoterminowym projektom następczym, których celem jest złagodzenie lub całkowite zapobieżenie dalszym negatywnym skutkom. Na przykład tego rodzaju działania miały kluczowe znaczenie dla umożliwienia projektom Wikimedia wytrzymania globalnych wzrostów ruchu spowodowanych ważnymi wydarzeniami (np. śmiercią znanych osób) dzięki połączeniu optymalizacji wydajności, przeprojektowania architektury obszarów, w których występowały wąskie gardła, oraz zwiększenia przepustowości. Podobnie, ostatnie ulepszenia użyteczności naszych narzędzi i systemów do zarządzania ruchem, który otrzymujemy, umożliwiły nam szybsze i skuteczniejsze reagowanie na zmieniające się warunki. Tego rodzaju prace adaptacyjne są integralną częścią naszej zdolności do reagowania na pojawiające się zdarzenia, często w krótkim czasie, oraz zapewnienia dostępności naszych projektów i treści.

Cele dotyczące produktów i technologii

Przedstawione tutaj cele mają formę roboczą i są otwarte na komentarze i dyskusję.

  • Cele reprezentują kierunek wysokopoziomowy
  • „Kluczowe rezultaty” (KR) stanowią wymierny sposób śledzenia sukcesu celów.
  • Podstawowe „Hipotezy” dla każdego KR reprezentują rzeczywistą pracę, którą wykonujemy, aby spróbować osiągnąć powiązane kluczowe rezultaty. Będą one aktualizowane w tym dokumencie i na stronach wiki odpowiednich projektów lub zespołów w miarę zdobywania spostrzeżeń w ciągu roku.
  • wishlist item dotyczy pracy, którą Fundacja traktuje priorytetowo w ramach Listy życzeń społeczności.

Doświadczenia wiki (WE)

Doświadczenia współtwórców (WE1)

  • Cel: Wkład wzrośnie, ponieważ wolontariusze otrzymają atrakcyjne możliwości i zrozumieją ich wpływ. Dyskusja
    • Kontekst: Cel ten będzie podstawą do realizacji nowej strategii dla współtwórców z jej 3 filarami: 1) oferowanie wolontariuszom scentralizowanego sposobu organizowania ich aktywności na wiki, 2) zapewnianie mniejszych, dyskretnych zadań, aby stworzyć większą przejrzystość i pomóc wolontariuszom w osiągnięciu ich potencjału, oraz 3) zwiększanie znaczenia wkładu. W roku budżetowym 25/26 planujemy dostarczyć podstawową infrastrukturę, aby pomóc wolontariuszom zorganizować ich aktywność na wiki w scentralizowany sposób, zaczynając od interwencji skoncentrowanych konkretnie na doświadczonych redaktorach i moderatorach. W kolejnych latach dodamy interwencje dla wszystkich ról edytorskich i uwzględnimy więcej obszarów problemowych. Dodatkowo, będziemy nadal inwestować w mechanizmy Edit Check i Structured Tasks, budując podstawy do wykorzystania sztucznej inteligencji w skalowalny sposób, zarówno jako wskazówki podczas procesu edycji, jak i jako sposób na wskazanie wolontariuszom atrakcyjnych możliwości. Wreszcie, zainwestujemy w zwiększenie widoczności wpływu wolontariuszy, aby stworzyć dla nich bardziej znaczące doświadczenie.
      • lista życzeń Kluczowy rezultat WE1.1: Zwiększenie liczby edytorów z łącznie ponad 100 edycjami, którzy publikują konstruktywne edycje w wersji mobilnej [i] o 4% [ii] w kontrolowanych eksperymentach do końca Q2
        • i. „Konstruktywne edycje” = edycje w głównej przestrzeni nazw (artykułach), które nie zostały cofnięte w ciągu 48 godzin od ich opublikowania.
        • ii. T389403#10960480
        • Nowi / nowsi wolontariusze mają trudności z pomyślnym rozpoczęciem edycji. W szczególności osoby korzystające z urządzeń mobilnych, gdzie przestrzeń ekranu jest ograniczona, a uwaga często podzielona.
        • Niektórzy są zmęczeni kontekstem, cierpliwością oraz próbami i błędami wymaganymi do wniesienia konstruktywnego wkładu. Inni nie napotkali jeszcze atrakcyjnej okazji, by spróbować.
        • WE 1.1 zajmie się tymi kwestiami poprzez:
          • Ujawnianie sugestii dotyczących edycji
          • Oferowanie praktycznych wskazówek podczas edycji
          • Budowanie bardziej specyficznych dla zadań przepływów pracy edycji
        • U podstaw tych wysiłków leży potrzeba skalowalnych sposobów wykrywania, w jaki sposób można poprawić edycje "w trakcie" i istniejącą zawartość. Aby zwiększyć te możliwości, będziemy nadal eksperymentować z uczeniem maszynowym, aby dowiedzieć się, w jaki sposób może ono wspomóc edytorów w różnych rolach.
        • Proponowana metodologia punktacji KR: Dla każdej platformy obliczymy odsetek interwencji, które wdrożyliśmy i oceniliśmy w ramach kontrolowanych eksperymentów, które osiągnęły lub przekroczyły cel konstruktywnej edycji, który wyznaczyliśmy na początku tego roku. Zobacz phab:T379285#10782051.
          • Uwaga: na dzień 30 czerwca 2025, w ramach WE 1.1 zaplanowano dwa eksperymenty.
      • lista życzeń Kluczowy rezultat WE1.2: Wzrost liczby współprac na wiki o 55% rok do roku do końca 4 kwartału.
        • Współtwórcy często mają trudności ze znalezieniem okazji do współpracy, zwłaszcza w zakresie tematów i zadań, na których im zależy. Może to prowadzić do poczucia osamotnienia na wiki dla nowicjuszy i wypalenia w przypadku doświadczonych redaktorów. Ponadto wpływ działań opartych na współpracy jest często niejasny, co może prowadzić do tego, że mniej osób chce dołączać, organizować lub wspierać współpracę na wiki.
        • Chcemy sprawić, by wartość współpracy była wyraźniejsza, podejmując następujące czynności:
        1. Stworzenie nowych sposobów dzielenia się wpływem wspólnych działań na wiki.
        2. Rozpoczęcie gromadzenia danych dotyczących wpływu wspólnych działań na cały ruch.
        3. Stworzenie podstawowej infrastruktury do śledzenia wkładu o charakterze współpracy, abyśmy mogli zapewnić nowe, innowacyjne sposoby rozpoznawania i nagradzania wkładu w przyszłości.
        • Współpraca będzie mierzona na podstawie nowych działań utworzonych poprzez rejestrację wydarzeń w rozszerzeniu CampaignEvents. Celem jest, aby do końca tego KR mieć więcej użytkowników narzędzi rozszerzenia i nowe sposoby ujawniania wpływu współpracy. Dzięki temu będziemy w stanie połączyć naszą istniejącą infrastrukturę z innymi sposobami uznawania i nagradzania pracy na wiki (takimi jak moduł wpływu, podziękowania itp.).
        • Obszar zainteresowania listy życzeń: Lista życzeń społeczności/Obszary zainteresowania/ Łączenie współtwórców
      • lista życzeń Kluczowy wynik WE1.3: Do końca trzeciego kwartału 10% użytkowników, którym zaprezentowano stronę główną skierowaną do nowych moderatorów, odwiedziło ją przez dwa tygodnie z rzędu.
        • Wierzymy, że możemy lepiej przedstawiać wolontariuszom możliwości zaangażowania się w Wikipedię. W dłuższej perspektywie uważamy, że strona główna może być pomocna dla każdego redaktora w organizowaniu pracy, znajdowaniu nowych możliwości i zrozumieniu swojego wpływu. Naszym celem w roku finansowym 2025/2026 jest przedstawienie doświadczonym redaktorom nowych możliwości podjęcia zadań moderacyjnych, z którymi w innym przypadku nie mieliby okazji się zetknąć.
        • Najpierw przetestujemy tę teorię, sprawdzając, w jakim stopniu doświadczeni redaktorzy angażują się w działania na stronie głównej, podobnie jak nowi użytkownicy, którzy mają do niej dostęp.
        • Następnie przedstawimy konkretne działania moderacyjne (szczegóły do ustalenia) autorom, którzy nie mają doświadczenia w tego typu działaniach, aby pomóc zmniejszyć obciążenie doświadczonych redaktorów poprzez zmniejszenie zaległości (w ramach nowego KR).
        • Jeśli koncepcja strony głównej okaże się sukcesem, planujemy uczynić tę stronę modułową, aby zaspokoić potrzeby społeczności. Moduły te mogłyby obejmować takie elementy, jak ułatwienie redaktorom zrozumienia ich wpływu.
        • Uwagi na temat metodologii:
        • Będziemy mieli hipotezę dotyczącą zdefiniowania naszej grupy docelowej, która będzie częścią WE1.3.1.
        • „Moderatorzy” będą zgodni z definicją zawartą w Research:Develop a working definition for moderation activity and moderators, jednak konieczne będą dalsze prace w celu zawężenia definicji ilościowej.
        • Drugi tydzień zostanie określony w odniesieniu do czasu pierwszej wizyty każdego użytkownika. W tym przypadku przejrzymy wszystkich nowych moderatorów, którzy odwiedzili stronę główną w określonym przedziale czasowym, a następnie ponownie odwiedzili ją co najmniej raz (od 7 do 14 dni później).
        • Obszar zainteresowania listy życzeń: Lista życzeń społeczności/Obszary tematyczne/Priorytetyzacja zadań
      • lista życzeń Kluczowy wynik WE1.4: Zwiększenie odsetka unikalnych użytkowników odwiedzających listę obserwowanych i/lub ostatnie zmiany, którzy klikają, aby wyświetlić edycję.
        • Naszym celem jest pomóc redaktorom, którzy dokonali ponad 100 edycji, w bardziej efektywnym wyszukiwaniu i otwieraniu edycji związanych z ich zainteresowaniami. Zbadamy obszar priorytetów zadań, zrealizujemy życzenia w tym obszarze i poprosimy wolontariuszy o dodatkowe opinie na temat tego, jak ulepszyć te przestrzenie. Sukces możemy zmierzyć poprzez poprawę skuteczności każdej strony w „wyszukiwaniu pracy”, definiowanej przez wskaźnik klikalności.
      • Kluczowy wynik WE1.5: Zdefiniowanie i wdrożenie siedmiu priorytetowych wskaźników [1] niezbędnych do śledzenia postępów w realizacji celów określonych w strategii edytorów do końca czwartego kwartału poprzez stworzenie pulpitu nawigacyjnego i wdrożenie wskaźników dotyczących aktywnych moderatorów miesięcznie[1]. Zatrzymani redaktorzy, konstruktywna aktywizacja, konstruktywne edycje, rejestracje kont zatrzymanych w projekcie nowicjuszy, aktywni redaktorzy według stażu działalności, aktywni redaktorzy według poziomu doświadczenia.
        • Strategia dotycząca doświadczeń współpracowników zakłada 3-5-letni wysiłek mający na celu „wspieranie rozwoju wolontariatu” oraz „zwiększenie retencji i aktywizacji” zarówno nowych, jak i obecnych współpracowników poprzez trzy główne obszary działań:
        1. Usprawnienie sposobu, w jaki wolontariusze mogą otrzymywać rekomendacje, zarządzać swoimi zadaniami i zainteresowaniami, śledzić wydarzenia na stronach wiki oraz rozumieć swój wpływ.
        2. Oferowanie odpowiednio skonstruowanych zadań w celu zapewnienia większej przejrzystości i pomocy wolontariuszom w osiągnięciu ich potencjału poprzez optymalizację procesów, do których ich kierujemy, w tym ciągłe inwestowanie w zapewnianie ustrukturyzowanych wskazówek i automatyzację powtarzalnych zadań, ze szczególnym uwzględnieniem doświadczenia mobilnego.
        3. Nadanie znaczenia zaangażowaniu poprzez pokazanie wolontariuszom ich wpływu oraz inwestowanie w możliwości nawiązywania kontaktów międzyludzkich i środowisko oparte na pozytywnych opiniach.
        • W ramach projektu dotyczącego strategii pomiarowej nakreślono następnie rozbudowaną sieć wskaźników służących do śledzenia tej teorii zmian. Stwierdzono, że podstawowym miernikiem sukcesu („wskaźnikiem podstawowym”) powinna być liczba zatrzymanych redaktorów, uzupełniona węższymi wskaźnikami, takimi jak konstruktywna aktywizacja i zamiar powrotu edytorów, oraz szerszymi wskaźnikami „downstream”, takimi jak aktywni redaktorzy i jakość treści. Musimy zapewnić, aby wskaźniki te były operacyjne i widoczne w panelu kontrolnym, tak abyśmy mogli śledzić nasze postępy w realizacji strategii.
      • Key result WE1.6: By the end of Q3, watchlist users can more easily organize their work and act more effectively on taking patrolling or editing action, as measured by qualitative feedback.
        • Our goal is to help editors with 100+ edits to more efficiently find edits that relate to their interests. We will explore the Task Prioritization Focus Area, deliver wishes in this area, and solicit additional feedback from volunteers on how to improve these surfaces.
      • Key result WE1.7: Primary: Achieve a ≥ 10% relative increase in the edit completion rate of qualified newcomer and Junior Contributor mobile edit sessions, based on controlled A/B test(s).[i]
        [i]         Qualified edit session = edit session in which a logged-in user with ≤100 cumulative edits spent at least ≥2 seconds in VE's "ready" state.
        Guardrail:         No meaningful decreases in constructive edit rate among mobile edits published by newcomer and Junior Contributors, based on controlled A/B test(s).
        • 150,000–200,000 times/day, someone will tap "Edit" on mobile web, wait for the editing interface to load, look around for at least 2 seconds, and then leave without doing anything. No keystrokes, no taps on the toolbar…nothing.
        • WE 1.7 will meet these "curious clicks" with clear, compelling, and structured edit suggestions that cause the people making them to experience the satisfaction, joy, and meaning that can come with making Wikipedia, the resource they chose to visit, a bit better.
      • Key result WE1.8: By the end of Q4, target a 5 percent overall relative increase in the mobile web account creation completion rate, with success measured by at least three controlled experiments achieving a minimum 2 percent relative improvement each.
        • Account creation is the gateway to meaningful participation on Wikimedia projects, yet it remains an outdated experience in the newcomer journey. The current flows impose high cognitive load, present limited or confusing value propositions, and rely on legacy interface patterns that no longer reflect contemporary expectations. As a result, many potential contributors disengage before they have a chance to join the community.
        • This initiative aims to modernize account creation, reduce friction for good faith contributors, and introduce thoughtful experiments that encourage registration at the moments where motivation is naturally highest. The work lays essential groundwork for long term improvements in newcomer activation, retention, and editor diversity.
        • We estimate a 5 percent relative increase in account creation on Wikipedia on mobile would translate to several thousand additional new accounts per month, and several hundred more retained new editors per month, based on current registration volumes.
      • Key result WE1.9: By the end of Q4, deliver one tangible product recommendation each for goal setting, newcomer progression, and recognition to enable junior contributors to stay engaged and evolve.
        • Background: we know that retention of junior contributors is quite low despite recent gains (data). We believe that a fundamental challenge for overcoming this low junior contributor retention is developing our platforms to help editors stay highly motivated to contribute – i.e. not just reducing the barrier to contribute but also making the experience rewarding. This is not trivial though – e.g., editors enter the project with varying motivations; interventions such as gamification that may boost initial engagement might not help with long-term retention.
        • Why now: much of the focus of Contributors Product teams to date has been related to reducing technical barriers to activation/engagement but there are a suite of upcoming projects that are more retention-focused – e.g., Progression System and Recognition. The research under this KR aims to get ahead of this implementation work and provide clear recommendations to Product teams in this space about how they should design their platforms to better support the diverse motivations of editors and increase long-term retention. This links back to key questions related to newcomers and junior editors in the Contributor Strategy.
        • Proposed KR scoring methodology: for each identified project (goal setting; progression system; recognition), we will make at least one concrete recommendation with implications for design. Research is experimental work and the projects may evolve over the course of the KR but we will keep in close communication with the relevant product teams. In practice, these recommendations may include insights about what is most demotivating for newcomers (things to avoid) what is most satisfying (things to emphasize), common "tripping points" in journeys that need to be addressed, strategies for getting through these challenges, etc. The recommendation should help the PM identify clear next steps for design and/or engineering.
      • Key result WE1.10: By the end of Q4, implement a new guided article creation flow where the survival rate of articles created by junior editors on mobile is 5% greater on each deployed wiki than articles created by other means while the volume of surviving articles stays the same or higher, as measured by a controlled experiment.
        • The Article guidance initiative aims to develop new approaches that support editors in creating initial, well-structured contributions to Wikipedia that align with community policies and content quality. As an initial intervention, a new workflow for article creation was implemented last quarter, based on community-editable outlines that encapsulate the guidance for specific types of articles. In Q4, the goal is to run an A/B test experiment to measure the impact on a set of pilot wikis to evaluate the impact. Since the guidance is community-dependent, the experiment preparations will requires collaboration with the communities of the pilot wikis to adapt the system to their needs.

Nieodzowna wiedza (WE2)

  • Cel: Sprawić, by więcej istotnej wiedzy było dostępne i dobrze zilustrowane we wszystkich językach i tematach. Dyskusja
    • Kontekst celu: Cel ten będzie napędzał rozwój treści, który będzie odpowiadał zarówno zainteresowaniom autorów w poszczególnych tematach i językach, jak i zapotrzebowaniu czytelników na dobrze zilustrowaną istotną wiedzę. Istotna wiedza to zestaw artykułów, które zapewniają szeroki zakres i głębię tematów potrzebnych do tego by Wikipedię w danej wersji językowej uznać za użyteczną. Jest ona definiowana przez społeczności w odniesieniu do przydatności, trafności, przewidywanego czytelnictwa i powiązań między artykułami.
    • Przyjmiemy podejście socjotechniczne, poprawiając skuteczność funkcji, narzędzi i procesów społecznych. Będziemy opierać się na najważniejszych funkcjach produktu, takich jak sugerowane zadania, wyszukiwanie mediów i tłumaczenie treści, ale także ułatwimy uruchamianie i rozwój mniejszych językowych Wikipedii. Będziemy wspierać organizatorów Wikimedia, którzy rekrutują, szkolą i wspierają współtwórców w pracy nad wspólnymi celami dotyczącymi treści poprzez wspólne przedsięwzięcia, takie jak Wikiprojekty i kampanie. (Szacujemy, że co najmniej 300 organizatorów jest aktywnych każdego kwartału). Będziemy również rozwijać relacje z najbardziej odpowiednimi wydawcami, aby usunąć bariery w dostępie do materiałów źródłowych. (Obecnie współpracujemy z ponad 100 najlepszymi na świecie bazami danych dostępnymi wyłącznie w ramach subskrypcji).
    • Aby upewnić się, że nasze interwencje mają pozytywny wpływ na istotną wiedzę, będziemy mierzyć zarówno wzrost treści priorytetowych dla społeczności, jak i jakość tych treści, analizując takie czynniki, jak wskaźniki wycofania zmian oraz liczba cytatów i obrazów.
      • Kluczowy rezultat WE2.1: Do końca 2 kwartału nastąpi wdrożenie po eksperymentach 3 interwencji, które pomogą twórcom poprawić stan istotnych treści na ich Wikipediach.
        • Ten KR podkreśli luki w treści w mechanizmach edycji, takich jak odkrywanie obrazów w Wikipedii, tłumaczenie treści i tworzenie nowych artykułów. Wdrożymy również i przetestujemy interwencję socjotechniczną w celu wsparcia działań związanych z tworzeniem treści dla małych społeczności językowych. Sukces będzie mierzony w ramach każdej hipotezy.
      • Kluczowy wynik WE2.2: Do końca czwartego kwartału stworzyć możliwości platformy niezbędne do potwierdzenia, że jesteśmy w stanie wspierać wizję Abstrakcyjnej Wikipedii na dużą skalę. O sukcesie będziemy wiedzieć, jeśli system będzie generował bogate, wielojęzyczne treści encyklopedyczne przy użyciu Wikidata i generatora języka naturalnego, będzie kontrolowany przez społeczność Wikimedia i zachowa wydajność podczas szerokiego wdrażania.
        • Skoro możemy używać Wikidata do generowania podstawowych treści w postaci zwykłego tekstu w Wikipedii, kolejnym krokiem jest dalsze rozwijanie możliwości platformy, która będzie w stanie obsługiwać Abstract Wikipedia na dużą skalę. Platforma będzie musiała obsługiwać bogate, wielojęzyczne treści, które mogą być kontrolowane przez społeczność i zachowywać wysoką wydajność na dużą skalę. Jest to kamień milowy KR, ponieważ przechodzimy od 0 do 1.
      • Kluczowy wynik WE2.3: Do końca czwartego kwartału wdrożyć wstępną wersję nowej wiki, aby umożliwić społeczności tworzenie artykułów abstrakcyjnych.
        • Ten KR przygotowuje nas do przetestowania możliwości platformy wiki Abstract w przyszłym roku. Nowa, samodzielna wiki będzie zawierała bibliotekę artykułów abstrakcyjnych opartych na Wikifunctions i zapewni możliwości platformy niezbędne do późniejszej integracji artykułów abstrakcyjnych z Wikipedią w przyszłości.
      • Kluczowy wynik WE2.4: Uzgodnienie między WMF a WMDE definicji sukcesu w zakresie ulepszeń infrastruktury technicznej wspierającej krytyczny przypadek użycia Wikidata do końca drugiego kwartału, w tym wskaźników i celów na lata 2025–2026.
        • W sierpniu 2025 r. utworzono zespół WMF Wikidata Platform (WDP) i zatrudniono do niego jednego kierownika produktu i jednego kierownika technicznego. Jako nowy element programu, nad którym od lat pracowali specjaliści ds. technicznych i produktowych odpowiednio w WMF i WMDE, cel ten odzwierciedla nasze zamiary dotyczące przeniesienia odpowiedzialności poprzez uzgodnienie przypadków użycia, zależności i kluczowych kryteriów sukcesu. Ten kluczowy wynik będzie stanowił podstawę wzajemnego zrozumienia zakresu problemu, na którym będziemy pracować przez pozostałą część roku finansowego (do maja 2026).
      • Key result WE2.5: By the end of Q4, our backend replacement has been stood up in parallel to Blazegraph and is capable of supporting the cutover of select users. We define “migration ready” for this KR as capable of supporting the pilot phase of our migration in Q1 of FY26-27.
        • Following the progress made towards defining the success criteria as a part of WE2.4, we are now shifting into execution mode. In the next two quarters, we will outline all of the variables associated with the Blazegraph cutover in a migration plan, determine which are critical for pilot launch, implement them in a new RDF database, and define the migration timeline for all requirements beyond our pilot personas. Our work between now and our target launch of a new WDQS backend (est. July 2026) will be guided by the requirements laid out in this plan.

Doświadczenia konsumentów (WE3)

  • Cel: Czytelnicy z wielu pokoleń angażują się i pozostają zaangażowani w Wikipedię, co prowadzi do wymiernego wzrostu retencji i aktywności darowizn. Dyskusja
    • Kontekst celu: Cel ten skupi się na zatrzymaniu nowych czytelników poprzez innowacyjne formaty treści, głównych odbiorców poprzez wzmocnienie znanych doświadczeń czytelniczych oraz zapewnienie długoterminowej stabilności poprzez pogłębianie więzi z czytelnikami i dywersyfikację sposobów przekazywania darowizn. Obejmie to kontynuację naszych prac nad ułatwieniem odkrywania treści poprzez nowe i bardziej eksperymentalne funkcje, takie jak podsumowania AI lub spersonalizowane królicze nory. Obejmie to również prace nad utrzymaniem i poprawą jakości doświadczeń czytelniczych na głębszych etapach lejka czytelniczego oraz nad badaniem kuratorstwa czytelniczego poprzez listy czytelnicze i inny udział niezwiązany z redakcją. W przypadku darczyńców prace te będą nadal koncentrować się na dywersyfikacji źródeł przychodów z platformy.
      • element listy życzeń Kluczowy rezultat WE3.1: Do końca drugiego kwartału wykazanie znaczącego wzrostu retencji czytelników zalogowanych, mierzonego za pomocą testów A/B jednej funkcji na platformę.
        • Ten KR skupi się na dalszym inwestowaniu w doświadczenia, które optymalizują nowe sposoby przeglądania i uczenia się treści, często poprzez wykorzystanie nowych technologii i formatów - prezentując istniejące treści w nowy i angażujący sposób. W tym roku finansowym chcielibyśmy kontynuować eksperymentowanie z nowymi funkcjami, jednocześnie koncentrując się na skalowaniu udanych eksperymentów na różnych wiki i platformach. Prace w KR obejmą witrynę mobilną i stacjonarną, a także aplikacje na iOS i Androida i skupią się na odkrywaniu treści (przeglądanie punktów wejścia i rekomendacje) oraz adaptowalnych formatach uczenia się (podsumowania wspomagane maszynowo, remiksowanie treści).
        • Obszar zainteresowania listy życzeń: Nowe doświadczenia konsumenckie
      • Kluczowy rezultat WE3.2: Zwiększenie liczby darowizn metodami innymi niż banery lub e-maile o 5% rok do roku na platformę poprzez interwencje produktowe, które sprzyjają pogłębianiu więzi i zmniejszają tarcia dla darczyńców do końca drugiego kwartału.
        • W tym KR będziemy nadal badać nowe punkty wejścia dla darowizn i inne możliwości przekształcania czytelników w darczyńców i zatrzymywania ich poprzez pogłębianie ich więzi z wiki, w tym oferując bardziej spersonalizowane treści. KR skupi się na wprowadzeniu nowych punktów wejścia i iteracji istniejących punktów wejścia w aplikacjach i sieci, we współpracy z zespołem ds. pozyskiwania funduszy.
      • Kluczowy rezultat WE3.3: Do końca drugiego kwartału wykazanie znaczącego wzrostu retencji zalogowanych czytelników, mierzonego za pomocą testów A/B jednej funkcji na platformę.
        • Ten KR skupi się na poprawie doświadczeń związanych z czytaniem i nauką dla obecnych i doświadczonych czytelników, mając na celu zatrzymanie naszych obecnych odbiorców i pogłębienie ich więzi z witryną, aby mogli dowiedzieć się więcej, a także być gotowi i otwarci na podjęcie kroków w kierunku darowizn i edytowania. Prace w tym zakresie będą koncentrować się na poprawie komfortu czytania w sieci i aplikacjach (poprawa czytelności, lepsza nawigacja i odkrywanie), a także na rozwijaniu i iteracji naszej oferty w zakresie selekcji i personalizacji (listy czytelnicze, spersonalizowane sugestie, historia użytkowników i artykułów itp.)
      • Kluczowy wynik WE3.4: Do końca czwartego kwartału usunąć wszystkie zidentyfikowane przeszkody dla wdrożeń małych lokalizacji pamięci podręcznej (PoP), które spełniają nasze obecne standardy jakości usług i bezpieczeństwa zgodnie z naszymi obecnymi wdrożeniami lokalizacji pamięci podręcznej.
        • Ten KR skupi się na udowodnieniu koncepcji, że możemy poprawić wydajność witryny i zmniejszyć opóźnienia dla naszych czytelników poprzez uproszczenie naszej infrastruktury buforowania i usprawnienie procesów wdrażania witryny buforującej poprzez skrócenie podstawowego czasu wdrażania z około jednego roku średnio do maksymalnie kwartału. Skupimy się tutaj na zakończeniu upraszczania, wdrożeniu PoC, przeprowadzeniu przeglądu bezpieczeństwa i podjęciu decyzji, czy kontynuować wdrażanie naszych brzegowych pamięci podręcznych w chmurach publicznych. Zmniejszenie opóźnień może prowadzić do udowodnionego wzrostu liczby odsłon i bardziej zróżnicowanej geograficznie bazy czytelników.
      • Kluczowy rezultat WE3.5: Poprawa identyfikacji darczyńców — zapewnienie, że wszyscy zalogowani czytelnicy, którzy wyrazili zgodę, mogą być identyfikowani na podstawie statusu darczyńcy w celu zapewnienia spersonalizowanej obsługi — do końca 4 kwartału.
        • Wdrożymy strategie identyfikacji darczyńców, aby zapewnić, że wszyscy zalogowani czytelnicy, którzy wyrazili zgodę, mogą być identyfikowani na podstawie statusu darczyńcy, co umożliwi bardziej spersonalizowane i angażujące doświadczenia. W czwartym kwartale priorytetowo potraktujemy działania związane z identyfikacją darczyńców, aby w przyszłości wspierać skuteczniejsze inicjatywy w zakresie personalizacji i aktywizacji.
      • Kluczowy rezultat WE3.6: Sfinalizowanie, opublikowanie i przekazanie strategii dotyczącej doświadczeń czytelników Wikipedii i konsumentów na różnych platformach do końca czwartego kwartału, wraz z określonymi celami i podstawowymi wskaźnikami, opracowanymi we współpracy z interesariuszami i społecznością, które będą wytyczać kierunki naszych działań do 2030 roku.
        • Będziemy kontynuować prace nad strategią konsumencką, z naciskiem na budowanie i komunikowanie strategii zarówno wewnętrznie, jak i ku społeczności, oraz zdefiniujemy i wdrożymy podstawowe wskaźniki dla konsumentów i odpowiednie poziomy bazowe.
      • Key result WE3.7: Increase the number of donations through non-banner or email methods by 10% YoY per platform through product interventions that foster deeper connections and reduce friction for donors by the end of Q4.
        • This KR will see us continue to explore new entry points for donation and other opportunities to convert readers into donors and retain them by deepening their connections to the wikis, including more personalized content. The KR will focus on introducing new entry points and iterating on existing entry points on apps and web, in collaboration with the fundraising team.
      • Key result WE3.8: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for active readers in a test environment, monitoring a guardrail appropriate for the feature.
        • This KR will focus on scaling features that showed promise in improving engaged reader retention (or related indicator metric) across web and apps, based on experiment results from Q1/Q2. This includes scaling of the reading list on web (to drive account creation and internal referral rate), activity tab on iOS (for account creation and retention), and a potential longer production analysis of activity tab on Android (already released) to validate feature retention improvements.
      • Key result WE3.9: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for logged-out casual readers in a test environment, monitoring a guardrail appropriate for the feature.
        • In this KR, we will scale successful experiments that have proven to provide a high value to readers, new and lapsed, who do not currently engage with wiki projects. We will scale improvements focused on logged-out reader experiences that support knowledge seeking- content discovery experiences, visual presentations and modalities for sharing (knowledge, content, topics of interest). This KR spans across mobile web and apps platforms (iOS and Android).
      • Key result WE3.10: By the end of Q4, perform at least one experiment per platform (web and apps) that shows a practically significant improvement in logged-out casual reader retention or another indicator metric over control (with casual reader retention defined as 21-day cumulative retention for web, and 14-day cumulative retention for apps).
        • We are continuing our investment in experiments that convey Wikipedia's value to readers, new and lapsed, who do not currently engage with wiki projects. We will look to test improvements to the logged-out reader experience focusing on content discovery (e.g., Minerva TOC, semantic search, Q&A), visual presentations (e.g., visually engaging link cards), and modalities for sharing (e.g., share action). This KR spans web (mobile and desktop, though with an emphasis on mobile due to the audience) and apps (iOS and Android).

Bezpieczeństwo (WE4)

  • Cel: Nasze systemy domyślnie lepiej chronią konta i prywatne informacje naszych redaktorów, oferując jednocześnie redaktorom i użytkownikom z rozszerzonymi uprawnieniami więcej możliwości zapobiegania nadużyciom i reagowania na nie. Dyskusja
  • Kluczowy rezultat WE4.1: Wdrożenie do końca drugiego kwartału realnego i działającego systemu zgłaszania incydentów we wszystkich naszych wiki, który będzie używany i akceptowany przez społeczności.
    • Zapewnienie bezpieczeństwa i dobrego samopoczucia użytkowników jest podstawowym obowiązkiem naszej platformy. W wielu jurysdykcjach obowiązują przepisy, które wymagają od platform internetowych, takich jak nasza, monitorowania i podejmowania działań przeciwko nękaniu, cyberprzemocy i innym szkodliwym treściom na ich platformie. Niezastosowanie się do tych wymogów może narazić platformy na odpowiedzialność prawną i sankcje regulacyjne.
    • Chcemy umożliwić naszym użytkownikom zgłaszanie bezpośrednich zagrożeń za pomocą łatwego do znalezienia i intuicyjnego mechanizmu zgłaszania, abyśmy mogli dowiedzieć się o takich incydentach i w razie potrzeby podjąć szybkie działania. Jest to krok w kierunku zapewnienia naszym użytkownikom poczucia bezpieczeństwa podczas korzystania z naszej platformy. Robimy to poprzez wdrożenie systemu zgłaszania incydentów na naszych stronach wiki.
  • Kluczowy wynik WE4.2: Zwiększenie precyzji i skuteczności narzędzi przeciwdziałających nadużyciom poprzez wdrożenie 2 ulepszeń do końca drugiego kwartału.
    • My i nasza społeczność musimy lepiej wykrywać i zapobiegać nieautentycznym i złośliwym działaniom w wiki. Zrobimy to poprzez zwiększenie liczby i jakości sygnałów dostępnych na platformie, połączenie tych sygnałów w narzędzia, które udostępnimy użytkownikom z rozszerzonymi uprawnieniami, oraz zidentyfikowanie obszarów, w których możemy bezpiecznie wprowadzić automatyczne ograniczenia dotyczące podejrzanych działań.
    • Widzimy również możliwości poprawy dostępności Wikipedii i naszych innych projektów. Jednym z pomysłów jest na przykład zastąpienie bardzo konwencjonalnego, samodzielnie zarządzanego systemu CAPTCHA, który uniemożliwia użytkownikom zalogowanie się do momentu rozwiązania zagadki, usługą oceny ryzyka, która rzadko kiedy wymaga od użytkownika podjęcia jakichkolwiek działań. Zamiast tego, system będzie po cichu oznaczał konta poziomem podejrzliwości, który będziemy mogli wykorzystać do wyłączenia niektórych funkcji, a status ten będzie widoczny dla użytkowników z zaawansowanymi uprawnieniami, aby ułatwić im pracę.
    • Ogólnie rzecz biorąc, projekty Wikimedia w dużym stopniu opierają się na blokowaniu adresów IP w celu ograniczenia nadużyć ze strony osób o złych zamiarach. Jest to coraz mniej skuteczne w powstrzymywaniu nadużyć i ma negatywny wpływ na użytkowników działających w dobrej wierze, którzy są objęci blokadami adresów IP i zakresów adresów IP. W niniejszym KR dążymy do ulepszenia istniejących możliwości i dostarczenia nowych narzędzi, które umożliwią bardziej precyzyjne i skuteczne blokowanie osób o złych zamiarach oraz zmniejszą szkody uboczne spowodowane blokadami adresów IP i zakresów adresów IP.
    • Aby ocenić naszą skuteczność, przeanalizujemy jakościowe opinie wolontariuszy zaangażowanych w walkę z nadużyciami oraz wskaźniki ilościowe, takie jak wskaźnik stosowania blokad adresów IP, wdrożenie reputacji adresów IP i środków ograniczających opartych na sygnałach przeglądarki, wskaźnik prawdopodobieństwa interakcji z użytkownikami podczas blokady oraz wdrożenie nowych sygnałów w narzędziach do zwalczania nadużyć.
    • Praca w ramach tego KR obejmuje ulepszone wykrywanie i ograniczanie skutków działania pacynek i obejść blokad, ujawnianie informacji o potencjalnych szkodach ubocznych, wzmocnienie wykrywania botów, ujawnianie sygnałów wolontariuszom zajmującym się przeciwdziałaniem nadużyciom, poprawę wydajności interfejsów narzędzi przeciwdziałających nadużyciom, ulepszenie wskaźników związanych z nadużyciami oraz przekazywanie sugestii dotyczących podejrzanej aktywności kont do CheckUserów w celu zbadania.
  • Kluczowy rezultat WE4.3: Zmniejszenie liczby ataków na dużą skalę wymagających interwencji pracownika zespołu SRE o 50% (w porównaniu z rokiem poprzednim) do końca czwartego kwartału.
    • 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ą sprawić, że nasze witryny staną się niedostępne, zalewając naszą infrastrukturę żądaniami lub przytłaczając zdolność naszej społeczności do zwalczania wandalizmu 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, wytrzymywania i łagodzenia lub powstrzymywania takich ataków.
    • W tym roku skupimy się głównie na automatyzacji wykrywania adresów IP i sieci, które regularnie angażują się w ataki przeciwko nam, oraz na zmniejszeniu obciążenia naszych systemów przez te uporczywie szkodliwe podmioty.
  • Kluczowy rezultat WE4.4: Wdrożenie kont tymczasowych w 100% naszych projektów, tak aby ujawnienie danych osobowych naszych niezarejestrowanych redaktorów było dostępne dla mniej niż 0,1% użytkowników do końca drugiego kwartału.
    • Konta tymczasowe mają na celu poprawę prywatności, a tym samym bezpieczeństwa naszych niezarejestrowanych redaktorów, chroniąc ich dane osobowe (adres IP) przed widokiem publicznym i ograniczając dostęp tylko do tych, którzy potrzebują tych danych do celów patrolowania. Oprócz znacznej poprawy bezpieczeństwa użytkowników, projekt ten jest również ważny dla zachowania zgodności z różnymi wymogami regulacyjnymi.
  • Kluczowy rezultat WE4.5: Ocena wpływu generatywnej sztucznej inteligencji na zaufanie i bezpieczeństwo oraz określenie działań produktowych mających na celu wykorzystanie możliwości i zapobieganie zagrożeniom dla projektów Wikimedia do końca trzeciego kwartału.
    • Wykorzystanie sztucznej inteligencji, a w szczególności generatywnej sztucznej inteligencji, szybko rośnie w Internecie. Wraz z upowszechnianiem się sztucznej inteligencji pojawiają się zarówno możliwości, jak i zagrożenia dla zaufania i bezpieczeństwa. Na przykład tworzenie treści jest łatwiejsze i tańsze, ale moderowanie jest bardziej pracochłonne. Podobnie badania można przeprowadzać przy znacznie mniejszym wysiłku, ale halucynacje AI są trudniejsze do zidentyfikowania.
    • Projekt ten ma na celu rozwinięcie oceny wpływu ML/AI na prawa człowieka poprzez ocenę wpływu AI na aspekty zaufania i bezpieczeństwa ekosystemu Wikimedia. Obejmuje to następujące działania:
      • Konsultacje z użytkownikami posiadającymi rozszerzone uprawnienia.
      • Identyfikacja przykładów nadużyć wspomaganych przez generatywną sztuczną inteligencję i potencjalnych środków łagodzących.
      • Identyfikacja możliwości ML w celu zmniejszenia obciążenia użytkowników z rozszerzonymi uprawnieniami.
      • Przeprowadzenie eksperymentów w celu zrozumienia, na czym powinniśmy się skupić, aby osiągnąć jak największy wpływ.
  • Kluczowy rezultat WE4.6: Techniczne egzekwowanie, aby 100% uprawnień umożliwiających użytkownikom podejmowanie działań wrażliwych pod względem bezpieczeństwa lub prywatności mogło być wykonywane wyłącznie przez konta, które włączyły uwierzytelnianie dwuskładnikowe, do końca 4 kwartału.
    • Musimy wzmocnić bezpieczeństwo kont użytkowników w naszych wiki, szczególnie w przypadku użytkowników posiadających zaawansowane uprawnienia. Kluczowym celem jest wymaganie, aby wszelkie działania wrażliwe mogły być podejmowane wyłącznie przez użytkowników, którzy włączyli uwierzytelnianie dwuskładnikowe (2FA). Stworzymy bardziej rozszerzalny system egzekwowania uprawnień, który ominie konieczność audytów i ręcznego egzekwowania 2FA, a także rozszerzy zakres uprawnień wymagających włączenia 2FA na platformie.
    • W ramach tych działań ulepszymy nasze systemy uwierzytelniania i odzyskiwania danych, abyśmy sami (WMF) jak i nasi użytkownicy mogli łatwiej wspierać bardziej rygorystyczne podejście do 2FA. Rozszerzymy ogólną dostępność uwierzytelniania dwuskładnikowego na całej platformie, aby każdy użytkownik mógł je włączyć według własnego uznania i aby zapewnić, że jest ono włączone przed przyznaniem uprawnień wymagających uwierzytelniania. Skupimy się również na zmniejszeniu obciążenia operacyjnego naszych systemów odzyskiwania kont i wsparcia, pomagając usprawnić procesy resetowania i odzyskiwania kont związanych z logowaniem. Zamierzamy również poprawić użyteczność naszego wdrożenia 2FA, oferując użytkownikom więcej opcji zabezpieczenia swoich kont i uniknięcia przypadkowego zablokowania.
  • Key result WE4.7: Publicly conclude our bot detection trial, by the end of Q4.
    • This KR is a focused, one-quarter effort to evaluate the results of this trial, to decide inside WMF about whether to maintain and expand this system across our wikis, and to publicly publish the results of the trial and our path forward.
  • Key result WE4.8: Simplify the patrolling of temporary accounts, by making it quicker to identify and address abuse, by the end of Q4.
    • The purpose of temporary accounts is to continue to safely support participation from good-faith unregistered editors. However, some anti-vandalism workflows became more complicated by the release of temporary accounts. To ensure temporary account vandalism can be sustainably managed, we will make it easier and quicker for patrollers to understand and respond to temporary-account activity, both good- and bad-faith.
      We will surface clusters of related temporary accounts to patrollers, while also exploring other interventions that could improve early identification and rapid response.
  • Key result WE4.9: Empower volunteer investigators to deter and block more inauthentic activity on wikis where they actively review flagged accounts, as measured by a 20% increase in the rate of mitigating actions on those accounts, by the end of Q4.
    • For Q3 and Q4, recognizing the strategic potential that Suggested Investigations has demonstrated, we will invest in deploying new signals independent of bot detection, and will set aside time to prioritize a variety of efficiency and quality-of-life features that have been requested by SI users since its original MVP release.
  • Key result WE4.10: By the end of Q4, we'll increase hCaptcha bot detection coverage from 18% to 100% of account creations and from 18% to 90% of higher risk edits.
    • In Q3, we concluded our hCaptcha trial, during which we enabled hCaptcha during account creation, and later expanded it to include new users on the desktop wikitext editor, on eight large Wikipedias, including English Wikipedia. Based on the results of that trial, we’re now expanding hCaptcha to more editing interfaces and more wikis. Our main priority will be expanding what we currently have to all wikis, but we’ll also focus on new avenues to (discussion tools, uploads), as well as categories of users whose actions will be protected by hCaptcha.
  • Key result WE4.11: By the end of Q4, complete an IRS trial on enwiki with a graduated deployment, reaching at least 50% of logged in users and resulting in 5 new reporting metrics.
    • We are trialing an incident reporting system (IRS) on English Wikipedia that is designed to help less experienced community members more easily report potentially bad behavior to the community-managed place that can best deal with it. For more rare and severe cases, it also provides a form to directly report imminent threats of harm to the WMF Trust and Safety team.
    • This trial will be primarily focused on calibrating the first use case: helping editors report potentially bad behavior, without overloading the system.
    • During the trial, we will focus on monitoring the volume of new reports, checking that reports are routed correctly, and identifying any immediate issues. We will be coordinating closely with all community members to fix bugs if they arise, and to otherwise streamline the process. For example, we are exploring some ways to tighten the user experience and help people more directly submit their reports, which we may deploy and measure during the trial as well.
  • Key result WE4.12: By end of Q4, we will have defined a detection pipeline for classifiers that automatically detect English Wikipedia policy-prohibited content, and evaluated the impact of at least one classifier detecting at least one type of prohibited content, validated against community datasets, on its potential for reducing volunteer workload.
    • We want to support volunteers and UWERs by reducing work needed to remove harmful content from the projects, to enable volunteers to handle more difficult cases.
    • In this quarter, we want to gain experience in defining repeatable processes for building detection pipelines for different types of content, and take first steps to evaluate these pipelines safely on large projects (A/B tests, log-only mode deployments, etc). We will start with a focus on content that should very likely be suppressed, such as threats, or disclosure of personal information.
    • We plan to expand on these initiatives in FY26-27 work as part of an overhaul of anti-abuse tooling that supports UWERs and volunteers in reducing the time to mitigation for bad-faith activity.

Odpowiedzialne korzystanie z infrastruktury (WE5)

  • Cel: Deweloperzy i ponowni użytkownicy uzyskują dostęp do wiedzy w wyselekcjonowanych ścieżkach, zapewniając zrównoważony rozwój naszej infrastruktury i odpowiedzialne ponowne wykorzystanie treści. Dyskusja
    • Kontekst celu: Cel ten skupi się na ustanowieniu ścieżek odpowiedzialnego ponownego wykorzystania treści.
    • Wikimedia hostuje największą kolekcję wiedzy tworzonej przez ludzi w sieci. Dzięki temu nasza infrastruktura wiedzy stała się nieocenionym miejscem docelowym nie tylko dla ludzi, ale także dla automatycznych konsumentów danych. Nasze treści zasilają wyszukiwarki, platformy mediów społecznościowych, handel elektroniczny, a od czasu powstania sztucznej inteligencji są wykorzystywane do trenowania dużych modeli uczenia maszynowego. Konsumenci pozyskują dane poprzez skrobanie stron (Web scraping), korzystanie z interfejsów API i pobieranie treści - często bez podania źródła. W świecie nieuwierzytelnionego ruchu nie możemy wiarygodnie odróżnić jednego użytkownika od drugiego, co znacznie ogranicza naszą zdolność do włączania i egzekwowania odpowiedzialnego korzystania z naszej infrastruktury: Jak możemy nadal umożliwiać korzystanie z naszej społeczności, jednocześnie wyznaczając granice automatycznej konsumpcji treści? Jak możemy kierować użytkowników do preferowanych, obsługiwanych kanałów? Jakich wskazówek potrzebujemy, aby zachęcić do odpowiedzialnego ponownego wykorzystywania treści? Jak możemy dążyć do spójnego doświadczenia deweloperskiego i tworzyć produkty, które spełniają potrzeby zarówno deweloperów-wolontariuszy, pracowników, jak i ponownych użytkowników? Chociaż te pytania nie są nowe, pilna potrzeba ich rozwiązania wzrosła wykładniczo: Od 2024 roku obserwujemy dramatyczny wzrost liczby żądań, przy czym większość tego wzrostu pochodzi z botów skrobiących zbierających dane szkoleniowe dla przepływów pracy i produktów opartych na sztucznej inteligencji. Obciążenie naszej infrastruktury nie jest zrównoważone i zagraża ludzkiemu dostępowi do wiedzy: Musimy działać teraz, aby przywrócić zdrową równowagę, abyśmy mogli skutecznie wspierać projekty Wikimedia i umożliwić trwały sukces naszej misji.
      • Kluczowy rezultat WE5.1: Do końca czwartego kwartału 50% wniosków o dostęp programowy będzie można przypisać znanemu programiście lub aplikacji.
        • Obecnie mamy ograniczone możliwości identyfikacji, kto jest odpowiedzialny za zautomatyzowany ruch i, oprócz stron wiki, ograniczone możliwości kontaktowania się z użytkownikami lub regulowania ich dostępu. Zaobserwowaliśmy znaczny wzrost wolumenu zautomatyzowanego ruchu zewnętrznego, który nie jest dla nas zrównoważony i zagraża ludzkiemu dostępowi do wiedzy. Naszym celem jest zwiększenie odsetka zautomatyzowanego ruchu, który jest przypisany do znanego konta, poprzez wymaganie uwierzytelniania i autoryzacji w oparciu o wielopoziomowe poziomy dostępu dla dużych ilości skrobania i korzystania z API. Pomoże nam to zidentyfikować, kto ponownie wykorzystuje treści na dużą skalę, umożliwiając nam ochronę naszej infrastruktury i poprawę zarządzania w zakresie dozwolonego użytku, przy jednoczesnym skuteczniejszym zaspokajaniu potrzeb wszystkich użytkowników. Zbadamy również, jak lepiej wspierać społeczność techniczną dzięki bardziej spójnemu doświadczeniu deweloperskiemu, które chroni preferencyjny dostęp dla członków społeczności i umożliwia nowe funkcje dla programistów.
      • Kluczowy rezultat WE5.2: Do końca czwartego kwartału 70% punktów końcowych API sieci Wikimedia będzie obsługiwanych przez wspólną infrastrukturę.
        • Naszym celem jest poprawa doświadczenia i trwałości naszych ścieżek deweloperskich poprzez oferowanie bardziej spójnych, stabilnych i łatwych do znalezienia interfejsów API dla wszystkich deweloperów Wikimedia. Uprościmy naszą ofertę API, wprowadzając bardziej scentralizowaną infrastrukturę dla podstawowych możliwości API, co pozwoli nam mieć spójne ścieżki i zarządzanie dla: specyfikacji i dokumentacji OpenAPI, identyfikacji deweloperów i kontroli dostępu, egzekwowania polityki API, routingu, wersjonowania i obsługi błędów. Usprawniając naszą ofertę API, sprawimy, że tworzenie narzędzi, botów, projektów badawczych i funkcji służących misji Wikimedia będzie szybsze, łatwiejsze i przyjemniejsze. Takie podejście wspiera wielopokoleniową przyszłość misji poprzez zmniejszenie kosztów utrzymania infrastruktury API, zwiększenie widoczności i kontroli dostępu w celu zwalczania osób działających w złej wierze oraz wspieranie silniejszej społeczności programistów.
      • Kluczowy wynik WE5.3: Do końca czwartego kwartału opublikowane zostaną nowe ramy atrybucji dla stron internetowych, aplikacji, asystentów głosowych i modeli LLM, które zostaną powiązane ze stronami Wikimedia. Wdrożone zostaną dwa przykłady ponownego wykorzystania, które przyczynią się do wymiernego wzrostu zaangażowania, a jeden zewnętrzny partner ponownie wykorzystujący te materiały przyjmie najlepsze praktyki w zakresie atrybucji.
        • Aby zwiększyć prawidłowe przypisywanie treści do projektów Wikimedia, zapewnimy jasne wytyczne dotyczące najlepszych praktyk, które promują odpowiedzialne ponowne wykorzystanie. Obejmuje to stworzenie ram przypisywania dla kluczowych platform (internet, aplikacje, głos, multimedia) oraz przedstawienie co najmniej dwóch praktycznych przykładów podkreślających wzorcowe zastosowania treści Wikimedia. Przykłady wyników obejmują zachęcanie organizacji medialnych do podawania źródeł obrazów z Wikimedia Commons, wyszukiwarek do skuteczniejszego wyświetlania odpowiednich danych Wikimedia lub asystentów AI do integrowania wiedzy Wikipedii w przejrzysty i odpowiedzialny sposób, który zwiększa zaufanie do ich wiarygodności. Wzmocnienie praktyk przypisywania autorstwa nie tylko zwiększa świadomość społeczną i pobudza zaangażowanie w projekty Wikimedia, ale także pomaga ustanowić odpowiedzialne i nowatorskie sposoby remiksowania wiedzy oraz zapobiega nadużyciom.
      • Kluczowy rezultat WE5.4: Zmniejszenie ruchu generowanego przez scraperów o 20%, mierząc pod względem liczby żądań, i o 30% pod względem przepustowości łącza.
        • Scraping istnieje od zawsze: wyszukiwarki od dziesięcioleci polegają na Wikipedii, aby dostarczać informacje swoim użytkownikom; jednak ostatnio pojawiła się kolejna duża motywacja do skrobania naszych danych: jest to największy wyselekcjonowany, wielojęzyczny zestaw treści wiedzy, jaki można znaleźć w Internecie i jest to podstawowe narzędzie do trenowania dużych modeli językowych. Dotyczy to zarówno naszych treści encyklopedycznych, jak i naszego repozytorium multimedialnego Wikimedia Commons, które jest nieocenione dla modeli uczenia maszynowego generujących obrazy.
        • W rezultacie w ciągu ostatniego roku zaobserwowaliśmy znaczny wzrost ruchu związanego ze scraperami, a także powiązanych zdarzeń związanych ze stabilnością witryny: Aby chronić naszą infrastrukturę, inżynierowie ds. niezawodności witryn musieli w poszczególnych przypadkach wymuszać ograniczanie lub blokowanie crawlerów. Scraping stał się tak widoczny, że nasza przepustowość wychodząca wzrosła o 50% w 2024 roku. Co więcej, niedawna analiza wykazała, że co najmniej 65% naszych najdroższych żądań (tych, których nie możemy obsłużyć z naszych serwerów buforujących i które są zamiast tego obsługiwane z głównych baz danych) jest wykonywanych przez boty.
        • Nasze zasoby obliczeniowe są niezwykle ograniczone w porównaniu do ilości ruchu, jaki generujemy, więc musimy ustalić priorytety, komu tymi zasobami służymy i chcemy faworyzować konsumpcję ludzką, a priorytetowo wspierać projekty Wikimedia i naszych współtwórców za pomocą naszych ograniczonych zasobów.

Przyspieszenie ścieżki do wyników produktu (WE6)

  • Cel: Deweloperzy Wikimedia szybko i pewnie przekazują swoje produkty użytkownikom końcowym. Dyskusja
    • Kontekst celu: Aby skutecznie realizować cztery filary strategiczne, programiści Wikimedia muszą poświęcać swój czas i wysiłek na działania o dużym znaczeniu, które skutkują dostarczaniem wysokiej jakości produktów tak wcześnie, jak to możliwe. Zbyt skomplikowane przepływy pracy, brak standardowych narzędzi i niezrównoważone komponenty systemu utrudniają osiągnięcie tych wyników.
    • Prace te opierają się na rozmachu, z jakim rozwijaliśmy MediaWiki jako platformę i oprogramowanie wspierające jej rozwój i wdrażanie. Prace na ten rok skupią się na zapewnieniu bardziej niezawodnych środowisk programistycznych, uproszczeniu przedprodukcyjnych przepływów pracy oraz zmniejszeniu ryzyka związanego z platformą i infrastrukturą.
      • Kluczowy rezultat WE6.1: Do końca czwartego kwartału liczba błędów / blokad, które wykraczają poza testowe wiki, zostanie zmniejszona o 10%.
        • W 2024 r. deweloperzy musieli powrócić do raz już wykonanej pracy 144 razy, ponieważ wystąpiła sytuacja awaryjna uniemożliwiająca wdrożenie MediaWiki. W wielu z tych przypadków błędy zostały wychwycone po wdrożeniu na testowych wiki, co oznacza, że problem dotarł do potencjalnej grupy miliardów użytkowników. Nie możemy kontrolować faktu, że błędy będą istnieć, ale ich wcześniejsze wykrycie oznaczałoby, że potrzeba mniej heroicznej pracy. Zbudowałoby to również zaufanie deweloperów, że kiedy coś trafi do prawdziwej produkcji, nie będzie pożaru.
        • Wyłapiemy te błędy wcześniej, zapewniając środowiska potrzebne programistom do pewnego dostarczania i testowania ich kodu przez cały cykl rozwoju i wdrażania. Musimy również upewnić się, że te ulepszenia nie pojawią się kosztem szybkości pracy deweloperów.
      • Kluczowy rezultat WE6.2: Do końca czwartego kwartału 4 kroki z listy kontrolnej przeglądu gotowości produkcyjnej można będzie wykonać bez interwencji SRE (zespołu Site Reliability Engineering)
        • Wdrożenie nowej usługi lub funkcji w środowisku produkcyjnym zależy obecnie od listy 24 kroków, z których każdy wymaga zazwyczaj wsparcia ze strony SRE. Stworzyliśmy program ambasadorów SRE, aby interweniować na wcześniejszym etapie cyklu rozwoju i budować potencjał w samych zespołach programistycznych, ale wiele zadań powinno być w pełni samoobsługowych. Obecnie oznacza to pracę, która jest ręczna, powtarzalna, możliwa do zautomatyzowania i skaluje się liniowo wraz z liczbą zespołów programistycznych. Na dłuższą metę nie jest to opłacalne dla zespołu SRE.
        • W przeszłości duża część tej pracy była wykluczana z zespołów programistycznych poprzez utrzymywanie zestawu wspólnych bibliotek i najlepszych praktyk do interakcji z naszą platformą. Zostały one porzucone, gdy przenieśliśmy się do naszej nowej infrastruktury Kubernetes i nie mają bezpośredniego zamiennika. Zapewniając podobne biblioteki, dokumentację i szkolenia, które mają zastosowanie do sposobu, w jaki tworzymy i wdrażamy rzeczy dzisiaj, wierzymy, że możemy zmniejszyć ilość zaangażowania wymaganego od SRE przed wdrożeniem nowej usługi lub funkcji do produkcji.
      • Kluczowy rezultat WE6.3: Do końca czwartego kwartału 100% odsłon Wikipedii będzie obsługiwanych przez Parsoid.
        • Parsoid oferuje rozszerzone możliwości ewolucji wikitekstu i zabezpiecza platformę na przyszłość. Utrzymywanie dwóch parserów jednocześnie nie jest zrównoważone w dłuższej perspektywie, ponieważ zwiększa dług techniczny i złożoność. Ponadto sukces niektórych nowych projektów, takich jak Wikifunctions, zależy od tego, czy Parsoid będzie powszechnie dostępny.
        • Skalujemy wdrażanie do mniejszych projektów i w tym roku będziemy gotowi na Wikipedie. Obsługa wszystkich edycji Wikipedii za pośrednictwem Parsoid jest najważniejszym kolejnym kamieniem milowym. Oprócz samego wdrożenia, praca ta obejmuje również rozwiązywanie problemów z wydajnością i skuteczne informowanie o wpływie na czytelników i redaktorów.
      • Kluczowy rezultat WE6.4: Do końca drugiego kwartału co najmniej dwa zidentyfikowane ryzyka, które zagrażają naszej zdolności do dalszego wdrażania lub skalowania wiki, zostaną złagodzone lub zredukowane do akceptowalnego poziomu
        • Dzięki kilku ukierunkowanym inicjatywom zmniejszymy lub złagodzimy kilka zagrożeń związanych ze skalowalnością, niezawodnością lub bezpieczeństwem, które zidentyfikowaliśmy jako prawdopodobne potencjalne zagrożenie dla rozwoju i zrównoważonego rozwoju naszej platformy i naszych projektów publicznych.
        • Na przykład, będziemy refaktoryzować strukturę podstawowych baz danych Commons, aby zapewnić, że jej rozwój nie będzie ograniczony pojemnością dostępnego sprzętu serwerowego w ciągu najbliższych kilku lat. Będziemy również aktualizować PHP, język programowania napędzający MediaWiki i powiązane usługi, do bardziej nowoczesnej wersji. Inne zidentyfikowane zagrożenia będą prawdopodobnie wymagały wdrożenia dodatkowych środków bezpieczeństwa w celu ochrony i wzmocnienia naszej infrastruktury.
      • Key result WE6.5: By the end of Q4, determine the feasibility of and next steps for scalable cross-wiki code collaboration and logged-in reader support.
        • One of the central features of wikis is collaborative content creation. In the context of the Wikimedia movement, the collaboration needs are very specific to the evolution of the projects and the challenges that arise at the scales that some of the larger projects operate in.
        • Code collaboration (cross-wiki or on-wiki) is a legitimate need and should be accommodated. This is less a single problem and more a problem space that includes several overlapping problems around code (templates & modules primarily) and solving problems in this space requires shared understanding around priorities that are most impactful.
        • With an experimentation mindset, we're exploring a leaner approach to test shared code libraries that could improve cross-wiki collaboration in a small and controlled environment. This means we will go through a phase of technical feasibility and scope exploration to approach the experiment roll-out in small iterations to collect insights that can help us decide how we want to tackle the aforementioned problem. Our intention is to demonstrate our learnings and progress in the Wikimedia Hackathon 2026.
        • Similarly, if we want to improve the experience of logged-in users, we need to know where the performance gains are, what product work will make demands, and what a sustainable approach will look like for this work next FY. Research in this area will set us up for starting platform work quickly next FY.
      • Key result WE6.6: By end of Q4, developers are able to get the results of MediaWiki Core CI in under 10 minutes.
        • Our current median CI cycle time baseline is over 24 minutes while a DevEx industry standard for high performing teams is 10 minutes or less.
        • To bridge this gap, we're planning to optimize the CI workflows, address main bottlenecks such us browser tests by optimizing how we run them, the underlying testing framework and its configuration.
        • By slashing median CI wait times from 24 to 10 minutes we ensure the rapid feedback loop needed to test and fix issues quickly, significantly accelerating iteration speed. Additionally, improving this metric speeds up merge times, shortening the time between a change being ready and being available for deployment, which directly contributes to the top-level OW5 metric of making it "easier and faster to build products".
      • Key result WE6.7: By end of Q1 of 2026-27 fiscal year, developers are able to test MediaWiki code in production within 1 day of it being merged.
        • Currently, on average developers can test their code on production ~4 days after merging. By shrinking this time, developers can test sooner, and by improving test environments they will have more confidence that their tests will result in fewer bugs reaching production.

Sygnały i usługi danych (SDS)

Metryki (SDS1)

  • Cel: Decydenci korzystają z bardziej wiarygodnych i aktualnych wskaźników do podejmowania decyzji dotyczących produktów i strategii Dyskusja
    • Kontekst celu: Wykorzystujemy wskaźniki do podejmowania decyzji dotyczących obszarów, na których Fundacja powinna skoncentrować swoje wysiłki, aby jak najlepiej służyć Ruchowi. Jednak niektóre z naszych kanałów danych są podatne na awarie, co powoduje opóźnienia w dostarczaniu danych. Kiedy pojawiają się problemy z danymi, czas potrzebny na ich zidentyfikowanie i podjęcie rozwiązania jest zbyt długi. Ponadto wiele naszych zbiorów danych nie jest zoptymalizowanych pod kątem łatwego badania trendów i brakuje w nich wymiarów, które okazały się ważne dla interpretacji danych. Problemy te spowalniają i ograniczają naszą zdolność do oceny wskaźników.
    • W roku podatkowym 2025-2026 skoncentrujemy się na konkretnych przypadkach użycia planu rocznego w celu wyeliminowania luk w jakości danych w naszych obecnych potokach, utworzenia infrastruktury i procesów monitorowania i rozwiązywania problemów związanych z jakością danych oraz dostarczenia narzędzi umożliwiających decydentom zrozumienie trendów.
    • Jednym z przykładów zastosowania jest sposób pomiaru ruchu generowanego przez ludzi i boty. Wzrost ruchu automatycznego w ciągu ostatnich kilku lat utrudnił zrozumienie zakresu interakcji ludzi z projektami Wikimedia i ich wkładu w te projekty. Chcemy poprawić naszą zdolność do oceny wzorców ruchu generowanego przez ludzi i boty, które są kluczowymi danymi wejściowymi dla planowania i podejmowania decyzji dotyczących produktów.
      • Kluczowy wynik SDS1.1: Do końca pierwszego kwartału analitycy korzystający ze wskaźników wyświetleń stron mają mieć dostęp do podstawowych miar jakości danych oraz miar wydajności automatycznych heurystyk wykrywania ruchu.
        • Poprzez hipotezy zbadane w tym KR, chcemy zidentyfikować luki w naszej obecnej heurystyce automatycznego wykrywania ruchu i zrozumieć, gdzie nie udaje im się prawidłowo skategoryzować ruchu związanego z odsłonami. Te spostrzeżenia pozwolą na ulepszenie potoków, które generują i klasyfikują metryki odsłon. Ponadto zdefiniujemy wskaźniki jakości danych, aby monitorować i mierzyć poprawę dokładności danych.
        • Ten KR położy podwaliny pod kolejny KR koncentrujący się na wdrożeniu niezbędnych ulepszeń potoku zidentyfikowanych tutaj. Wskaźniki jakości danych ustalone w tej fazie posłużą jako punkty odniesienia do oceny skuteczności tych przyszłych ulepszeń.
      • Kluczowy wynik SDS1.2: Do końca pierwszego kwartału dane dotyczące historii treści Mediawiki będą dostępne w postaci pliku eksportowanego z gwarancją cotygodniowej dostawy (SLO). Dane w eksportowanym pliku będą zgodne z danymi z dotychczasowego potoku eksportowego XML Dumps 1.
        • Celem KR 1.4 na rok finansowy 2024/25 było usunięcie zależności od aktualizowanych co miesiąc zbiorów danych mediawiki_wikitext_history i mediawiki_wikitext_history_current dla 3 najbardziej istotnych potoków danych i zapewnienie alternatywnego zbioru danych z gwarantowanymi tygodniowymi SLO.
        • Chociaż KR 1.4 na rok finansowy 2024/2025 pomógł złagodzić problemy z niezawodnością najbardziej istotnych zależnych potoków, pozostały potoki z niepewnym źródłem danych wejściowych. Należy je również przenieść, podobnie jak źródło danych wejściowych oparte na plikach, do samego zbioru danych historii wikitext.
      • Kluczowy wynik SDS1.3: Do końca drugiego kwartału wykrywanie botów obejmie 1 dodatkowy sygnał i będzie generować automatyczne alerty dotyczące anomalii.
        • W całej Fundacji zespoły podejmują decyzje dotyczące produktów i finansowania w oparciu o umiejętność rozróżnienia między czytelnikami ludzkimi a automatycznym ruchem. Platforma danych jest centralnym repozytorium sygnałów wykrywania botów i analizy wsadowej. Dzięki hipotezom, które opracowaliśmy w pierwszym i drugim kwartale, planujemy wprowadzić nowe sygnały wykrywania botów, aby udoskonalić naszą analizę automatycznego ruchu, a także sprawić, by proces wprowadzania nowych sygnałów był wydajny i powtarzalny.
      • Kluczowy wynik SDS1.4: Do końca drugiego kwartału decydenci będą mieli jasny obraz aktualnego stanu wiedzy wynikającej z naszych wskaźników organizacyjnych. O sukcesie będziemy mogli mówić, jeśli przygotujemy prezentację na posiedzenie Rady, która umieści analizę naszych wskaźników zarówno w kontekście ekosystemu Wikimedia, jak i szerszych trendów internetowych oraz wyzwań rynkowych.
        • Wnioski płynące z naszych wskaźników organizacyjnych są wykorzystywane do podejmowania niezliczonych decyzji w całej Fundacji, w tym decyzji dotyczących sposobu tworzenia naszych produktów, alokacji zasobów infrastrukturalnych i pozyskiwania funduszy. Jednocześnie krajobraz internetowy ewoluuje, a automatyczny ruch ma szczególny wpływ na nasze wskaźniki. Celem kierownictwa Fundacji jest przystąpienie do grudniowego posiedzenia Rady z jasnym opisem zagrożeń i możliwości związanych z ekosystemem Wikimedia, popartym rzetelną analizą wskaźników wewnętrznych i trendów zewnętrznych. Możemy opowiedzieć tę historię, gromadząc spostrzeżenia, wskaźniki i dane, które z całą pewnością mówią nam o:
          • Trendach w naszych wewnętrznych pomiarach czytelnictwa (odsłonach stron)
          • Trendach w ekosystemie naszych współtwórców
          • Trendach z danych zewnętrznych i benchmarków
          • Wnioskach z zewnętrznych i wewnętrznych badań oraz z zaufanych projektów naukowych
      • Key result SDS1.5: By the end of FY25-26 Q4, analytics bot detection will incorporate 2 signals calibrated against 1 trusted classification.
        • In Q1/Q2, SDS1.3 addressed the big gap in incident detection time and analyzed additional signals for bot detection. We learned that:
          • Modern and feasible signals come with a number of caveats and uncertainties that need to be expressed in our metrics.
          • Evaluating the quality of our model, as well as doing robust analysis of signals to enable future iteration, will require labeled data, trusted by definition and preferably sourced from independent systems (formerly called “ground truths”).

We will need knowledge and calibration from third-parties that specialize in this domain to be able to quantify our current state and prioritize future improvements.

        • In Q3/Q4, we will follow that with three main deliverables:
          • Extend our pageview metric to incorporate a numerical confidence score in addition to the existing labels, computed from at least 2 new signals, which will allow analysts to quantify and convey the nuances of those signals.
          • Curate trusted labels, preferably sourced from a third-party that specializes in this domain, and use it to evaluate our current performance and better understand the new signals.
          • Operationalize a client-side signal, which remains the most promising internally developed detection method.
      • Key result SDS1.6: Deliver a Movement Insights report on a regular basis, with consistent coverage across readership, contributors, and content thematic areas. We’ll know we’re successful when we’ve established the following by the end of Q4:
        • A consistent delivery cadence
        • Most valuable content for our stakeholders
        • Areas for future automation
        • Today, critical signals about the health of the Wikimedia Movement are fragmented across systems and teams. Readership trends, contributor health, brand perception, SEO/AEO, and competitor intelligence are monitored independently, without a consistent process or systems to aid in interpreting them together. We have existing monthly metric monitoring processes but they don’t address the scope and focus that is needed by executive decision-makers. The Movement Trends Brief is a concise, recurring intelligence brief that provides leadership and product teams with a shared understanding of how the Wikimedia movement is evolving week over week. Rather than describing everything that happened, this communication answers the following questions consistently:
          • What meaningfully changed in the past week/2 weeks?
          • Have we learned anything new about existing trends that we’re questioning?
          • Why does it matter now?
          • What requires attention or action?
        • The brief is designed to support situational awareness and provide a forum to present deeper analysis. It surfaces early signals, connects related trends across various data sources, and creates an entry point to inform decision-making.

Platforma eksperymentalna (SDS2)

  • Cel: Menedżerowie produktu mogą szybko, łatwo i pewnie ocenić wpływ zmian funkcji produktu w Wikipedii. Dyskusja
    • Kontekst celu: Aby umożliwić i przyspieszyć podejmowanie decyzji opartych na danych dotyczących rozwoju funkcji produktu, menedżerowie produktu potrzebują platformy eksperymentalnej, w której mogą definiować funkcje, wybierać grupy użytkowników poddawanych badaniu i sprawdzać pomiary wpływu. Przyspieszenie czasu od uruchomienia do analizy ma kluczowe znaczenie, ponieważ skrócenie czasu uczenia się przyspieszy eksperymentowanie, a ostatecznie również innowacje. Jako bariery dla szybkości zidentyfikowaliśmy ręczne zadania i niestandardowe podejścia do pomiarów. Idealnym scenariuszem jest sytuacja, w której menedżerowie produktu mogą przejść od uruchomienia eksperymentu do odkrycia przy niewielkiej lub żadnej ręcznej interwencji ze strony inżynierów i analityków.
    • Skupiamy się na Wikipedii w następnym roku podatkowym, ponieważ to właśnie tam zespół Core Experiences jest zainteresowany eksperymentami (strategia organizacyjna zakłada podwojenie naszej uwagi na Wikipedii), a także dlatego, że pozwala nam to skupić się i wyraźniej zasygnalizować, z którymi zespołami i projektami się angażujemy. Inne zespoły korzystały z komponentów platformy eksperymentalnej i mogą nadal to robić, ale to wykorzystanie nie będzie przedmiotem tego celu.
      • Kluczowy rezultat SDS2.1: Do końca drugiego kwartału umożliwić zakończenie co najmniej 2 pełnych cykli eksperymentalnych z wykorzystaniem platformy eksperymentalnej.
        • W miarę jak organizacja coraz większy nacisk kładzie na podejmowanie decyzji dotyczących produktów w oparciu o dane, musimy zapewnić wszystkim zespołom produktowym dostęp do eksperymentów, a nie tylko tym, które posiadają specjalistyczne umiejętności. Zespoły produktowe potrzebują wspólnych standardów, narzędzi i infrastruktury, które umożliwią im:
          • Szybkie testowanie pomysłów wśród naszej globalnej bazy użytkowników
          • Pomiar wpływu zmian w produktach za pomocą standardowych wskaźników
          • Przejrzystą wymianę wyników z interesariuszami naszego ruchu
        • Dlaczego zmieniamy podejście z koncentracji na liczbie „zespołów, które wdrożyły rozwiązanie” na „zakończone eksperymenty”:
        1. Strategiczne dostosowanie: Jest to podstawowy wskaźnik sukcesu platformy.
        2. Podejście oparte na danych: Nasze badania użytkowników (w toku) wskazują na zróżnicowany stopień gotowości zespołów w całej organizacji, ale wiemy, że zespół ds. stron internetowych potwierdził zainteresowanie dwoma konkretnymi eksperymentami.
        3. Optymalizacja zasobów: Wdrożenie naszej platformy MVP będzie wymagało intensywnego wdrożenia, dlatego w najbliższym czasie bardziej efektywne będzie skupienie się na możliwościach eksperymentowania niż na szeroko zakrojonych działaniach obejmujących wiele zespołów.
        4. Koncentracja na przyszłości: Informacje zwrotne z pełnych cykli eksperymentów będą bardziej skuteczne w ulepszaniu naszej platformy niż wnioski wyciągnięte z częściowego lub niepełnego wdrożenia. W miarę zbliżania się do ogólnego wdrożenia, skupienie się na zakończeniu eksperymentów pozwala uniknąć inwestycji w tymczasowe rozwiązania, które wymagałyby ponownego opracowania.
        • Prowadzimy badania użytkowników w celu określenia potrzeb i wymagań różnych zespołów: ankiety i wywiady zaplanowano na drugą połowę maja 2025, aby doprecyzować potrzeby zespołu produktowego. Po zakończeniu badań stworzymy kalendarz eksperymentów, który będzie można wykorzystać do ustalenia kolejnych celów KR i priorytetów.
      • Key result SDS2.2: Before the end of Q3, results for at least one web experiment can be analyzed and viewed in GrowthBook.
        • After a long and arduous process, we finally made a decision to integrate GrowthBook as a third-party experimentation solution that offers experiment flagging, automated analysis, and dashboarding, with support for guardrail metrics. Experiment Platform intends to replace the UI to define and deploy experiments (1) and the experiment analytics pipeline (5) with GrowthBook.
        • Because of the risks associated with this integration, the Experiment Platform Team believes that GrowthBook should be integrated as an experiment analytics pipeline first because it's non-disruptive and because it's the greatest source of risk.
        • The architectural decisions we made during FY24/25 SDS2 and GrowthBook’s modularity allow us to replace parts of the Experimentation Lab out of order, i.e. WMF staff can define and deploy experiments with xLab UI while analyzing them with GrowthBook. Further, we can run the current experiment analytics pipeline and GrowthBook’s in parallel, which allows for side-by-side comparisons as well as User Acceptance Testing in real-world scenarios.
      • Key result SDS2.3: By the end of Q4, all new Test Kitchen experiments are configured in GrowthBook.
        • After having enabled WMF staff to use GrowthBook for analyzing experiment results, the Experiment Platform team held a design sprint to assess options for experiment configuration. The decision was to use GrowthBook as the source of truth for experiment configuration but keep Test Kitchen UI (TKUI) as the source of truth for instrument configuration.
          In making GrowthBook the source of truth for experiment configuration, we aim to:
          • Reduce coordination when running an experiment
          • Enable more frequent and repeatable experimentation
          • Clearly delineate between instruments and experiments
          • Move toward a mental model centered on metrics rather than instruments
      • Key result SDS2.4: At least 14 out of 20 product teams have used Test Kitchen to inform a strategic decision for an OKR initiative, by the end of Q4.
        • The work done under SDS2.1 revealed a critical insight: building an experiment platform is not enough — Product & Tech teams face some barriers to adoption. Even though teams see value, they often lack time, infrastructure, instrumentation, or confidence to begin. In addition to this, they may encounter technical blockers that will need to be addressed by thoughtful partnership.
        • KR SDS2.4 shifts our focus from building to scaling adoption. By continuing to partner with teams as they onboard onto the platform, overcoming technical barriers and providing hands-on migration support, we aim to consolidate experimentation onto Test Kitchen as the unified platform for product teams, enabling fast, self-service testing cycles that reduce dependence on engineering and analytics support.
        • This KR was planned after we decided to split SDS2.2 in two pieces of work, which is why the numbering was affected. SDS2.3 is an upcoming KR that is sequential to GrowthBook for Experiment Analytics.

Przyszli odbiorcy (FA)

Przyszli odbiorcy (FA1)

  • Cel: Fundacja Wikimedia zostanie wyposażona w zalecenia dotyczące strategicznych inwestycji, które pomogą naszemu ruchowi służyć nowym odbiorcom w zmieniającym się Internecie. Dyskusja
    • Kontekst celu: Ze względu na ciągłe zmiany w technologii i zachowaniach użytkowników online (np. rosnąca preferencja do uzyskiwania informacji za pośrednictwem aplikacji społecznościowych, popularność krótkich filmów wideo, wzrost generatywnej sztucznej inteligencji), ruch Wikimedia stoi przed wyzwaniami związanymi z przyciąganiem i zatrzymywaniem czytelników i współtwórców. Zmiany te przynoszą również możliwości służenia nowym odbiorcom poprzez tworzenie i dostarczanie informacji na nowe sposoby. Jednak jako ruch nie mamy jasnego, opartego na danych obrazu korzyści i kompromisów różnych potencjalnych strategii, które moglibyśmy zastosować, aby sprostać wyzwaniom lub wykorzystać nowe możliwości. Na przykład, czy powinniśmy
      • Inwestować w duże nowe funkcje, takie jak chatboty?
      • Wnieść wiedzę Wikimediów i ścieżki wkładu do popularnych platform innych firm?
      • Coś innego?
    • Aby zapewnić, że Wikimedia stanie się zjawiskiem wielopokoleniowym, przetestujemy hipotezy, aby lepiej zrozumieć i zalecić obiecujące strategie - dla Wikimedia Foundation i ruchu Wikimedia - w celu przyciągnięcia i utrzymania przyszłych odbiorców.
      • Kluczowy rezultat FA1.1: W wyniku eksperymentalnych spostrzeżeń i zaleceń Future Audiences, do końca trzeciego kwartału co najmniej jeden cel lub kluczowy rezultat należący do zespołu spoza Future Audiences będzie obecny w projekcie planu rocznego na następny rok.
        • Wikimedia Foundation śledzi od roku 2020 zewnętrzne trendy, które mogą wpłynąć na naszą zdolność do służenia przyszłym pokoleniom konsumentów i twórców wiedzy oraz pozostania kwitnącym ruchem wolnej wiedzy dla przyszłych pokoleń. Future Audiences, mały zespół badawczo-rozwojowy, będzie
          • Przeprowadzać szybkie, ograniczone czasowo eksperymenty (co najmniej 3 eksperymenty w roku podatkowym), aby zbadać sposoby radzenia sobie z tymi trendami.
          • W oparciu o spostrzeżenia z eksperymentów, przedstawi rekomendacje dotyczące nowych inwestycji nieeksperymentalnych, które WMF powinna realizować - tj. nowych produktów lub programów, które muszą zostać podjęte przez pełny zespół lub zespoły - podczas naszego regularnego rocznego okresu planowania.
        • Ten kluczowy rezultat zostanie osiągnięty, jeśli co najmniej jeden cel lub kluczowy rezultat, który jest własnością zespołu spoza Future Audiences i jest napędzany przez rekomendację Future Audiences, pojawi się w projekcie planu rocznego na następny rok podatkowy.

Wideo społecznościowe (FA2)

  • Cel: Młodzi (<25 lat) ludzie uwielbiają, uczą się, angażują i udostępniają treści z Wikipedii na platformach, na których lubią spędzać czas online. Dyskusja
    • Kontekst celu: Eksperymenty Future Audiences z krótkimi filmami wideo w tym roku podatkowym pokazały, że możemy dotrzeć do młodszych odbiorców na tych platformach, ale nasze dane dotyczące kondycji marki pokazują, że nasze obecne inwestycje nie są wystarczające, aby przeciwdziałać spadkowi świadomości i sympatii do Wikipedii wśród odbiorców w wieku Gen-Z.
    • Aby zapewnić skuteczne dotarcie i zaangażowanie tego pokolenia, uważamy, że będziemy musieli zaangażować się w różne taktyki i znacznie zwiększyć nasze zaangażowanie w takich obszarach, jak marketing płatny i influencerski, kampanie kreatywne, reagowanie na trendy i zwiększanie poziomu eksperymentowania na tych kanałach.
    • Oczekujemy, że wyzwania, przed którymi stoimy, będą wymagały większych inwestycji, które pomogą nam je przezwyciężyć, szczególnie w zakresie komunikacji i marketingu w celu zwiększenia zaangażowania, a także współpracy między zespołami w zakresie tworzenia nowych produktów i doświadczeń mających na celu zwiększenie obecności marki i treści Wikipedii na tych platformach.
      • Kluczowy rezultat FA2.1: Wygenerowanie 9 500 000 wyświetleń krótkich materiałów wideo we wszystkich posiadanych kanałach do końca pierwszego półrocza.
        • W tym roku osiągnęliśmy zasięg około 1 miliona wyświetleń w ciągu 3 miesięcy od uruchomienia krótkich filmów na kanałach @Wikipedia na TikToku, Instagramie i YouTube. Na początku przyszłego roku podatkowego spodziewamy się większej liczby obserwujących na naszych kanałach własnych i większej wiedzy na temat skutecznych / angażujących treści, które możemy zastosować w praktyce, aby dotrzeć do jeszcze większej liczby widzów.
        • Wyznaczając ambitny cel w pierwszej połowie roku, mamy nadzieję osiągnąć bardziej znaczący wpływ, pozwolić na stworzenie nowych strategii/procesów ułatwiających pracę i być w stanie zabiegać o dodatkowe zasoby, aby osiągnąć ten cel.
      • Kluczowy wynik FA2.2: Zwiększenie liczby obserwujących poza platformą TikTok z poziomu średniego (100–250 tys. obserwujących) do poziomu makro (250 tys.–1 mln obserwujących) do końca roku finansowego 2025/2026 (czerwiec 2026).
        • Obecnie znajdujemy się w średniej kategorii TikToka (100–250 tys. obserwujących), a naszym celem jest osiągnięcie kategorii makro (250 tys.–1 mln obserwujących) do końca roku finansowego 2025/2026 (czerwiec 2026). Kategorie te – mikro, średnia i makro – są standardowymi punktami odniesienia w branży pod względem wielkości i zasięgu odbiorców. Aby to osiągnąć, udoskonalimy naszą strategię treści, aby lepiej przyciągać obserwujących z pokolenia Z i zwiększyć naszą ogólną widoczność poprzez zarządzanie społecznością. Wyniki za pierwsze półrocze będą podstawą do wprowadzenia zmian taktycznych w drugim półroczu, aby przyspieszyć wzrost i osiągnąć ten kamień milowy.
      • Kluczowy rezultat FA2.3: Uruchomienie poza platformą produktu ukierunkowanego na nowe metody uczenia się / konsumpcji mediów przez przyszłych odbiorców i wprowadzenie go na rynek poprzez wspólną kampanię brandingową i marketingową.
        • Zespół Future Audiences zazwyczaj pracuje nad eksperymentami na małą skalę z minimalnym/organicznym marketingiem. W tym roku chcielibyśmy zarezerwować czas na bardziej rozbudowany nowy produkt + kampanię marketingową skierowaną do młodszych odbiorców poza platformą.

Wsparcie produktowe i inżynieryjne (PES)

Wsparcie produktowe i inżynieryjne (PES1)

  • Cel: Zespoły produktowe i inżynieryjne WMF staną się bardziej efektywne dzięki ulepszonym procesom, wspierając pozytywną zmianę w naszej kulturze. Dyskusja
    • Kontekst celu: Cel ten dotyczy uczynienia sposobów pracy Wikimedia Foundation szybszymi, inteligentniejszymi i lepszymi. Chodzi o to, jak pracujemy. Oznacza to mniej tarć i przeszkód (nieefektywności i błędów) w procesach oraz szybsze osiąganie efektów. Ten cel dotyczy również uczenia się sposobów pracy, które można zastosować w całym zespole a nawet organizacji.
      • Kluczowy rezultat PES1.1: Do końca drugiego kwartału nastąpi zdefiniowanie SLO dla 6 usług produkcyjnych w oparciu o rubrykę priorytetyzacji, która ma na celu zmaksymalizowanie naszej wiedzy na temat definiowania i wykorzystywania SLO do podejmowania świadomych decyzji dotyczących ustalania priorytetów pracy związanej z niezawodnością przez zespoły interesariuszy.
        • Cel poziomu usług (SLO) to porozumienie między zespołami interesariuszy w sprawie docelowego poziomu usług (niezawodności/wydajności), nad którym zespoły współpracują, aby go osiągnąć (i nieznacznie przekroczyć). Pomaga on na przykład określić, kiedy niezawodność lub wydajność powinny być traktowane priorytetowo przez zespół programistów lub co stanowi problem. Zespoły muszą dbać o identyfikację tego, co jest natychmiastowe (alarmowanie/reagowanie na incydenty/krytyczne błędy), a co nie. Celem jest zmniejszenie tarć między funkcjami poprzez negocjowanie celów i informowanie o wspólnych i jasnych priorytetach.
      • Kluczowy wynik PES1.2: Do końca drugiego kwartału sygnały społeczności (w tym lista życzeń) wpłyną na WMF, aby nadać priorytet co najmniej 5 strumieniom pracy nad produktem w trzecim i czwartym kwartale.
        • Naszym celem jest identyfikowanie i docenianie sytuacji, w których zespoły ustalają priorytety pracy na podstawie opartych na dowodach wniosków społeczności.
        • Dwie planowane hipotezy koncentrują się wyłącznie na liście życzeń. Mają one na celu poprawę zaufania, usprawnienie procesów i zwiększenie udziału pracowników i wolontariuszy. Kolejna hipoteza to eksperyment mający na celu sprawdzenie, czy z village pump itp. napływa wystarczająca ilość wartościowych sygnałów i czy sztuczna inteligencja może wesprzeć nasze działania w zakresie gromadzenia sygnałów.
      • Kluczowy rezultat PES1.3: Fundacja włączy do planu rocznego dwa eksperymenty międzywydziałowe na wczesnym etapie: zweryfikowane przez naszych zewnętrznych konsumentów, darczyńców i współpracowników.
        • Praca ta polega na tworzeniu eksperymentów i procesów eksperymentalnych do przyjęcia w całej naszej organizacji.
        • Fundacja wzmacnia kulturę eksperymentowania między zespołami, włączając dwa zweryfikowane eksperymenty na wczesnym etapie do swojego rocznego planowania. Inicjatywa ta wspiera współpracę wykraczającą poza zespoły działu Produktu i Technologii, zachęcając do większej innowacyjności z innymi działami w organizacji (takimi jak Komunikacja i Rozwój). Poprzez zasiewanie niesprawdzonych, nowszych pomysłów i usprawnianie procesów eksperymentowania, zespoły zwiększają produktywność i skalę oddziaływania. Sukces jest mierzony poprzez ukończenie dwóch eksperymentów między działami rocznie, zintegrowanie ich z przyszłymi pracami OKR i zwiększenie przyjęcia praktyk eksperymentalnych. Przykładami wyników są nowe prototypy zwiększające rozwój i produktywność nowych edytorów, a także eksperymentalne funkcje, które pogłębiają więź czytelników i darczyńców z Wikipedią. Jedną z konkretnych zidentyfikowanych możliwości jest połączenie eksploracji małych funkcji w celu uczczenia 25. urodzin Wikipedii.
      • Key result PES1.4: By the end of Q4, we'll see a 10% adoption rate increase for Codex among P&T teams.
        • As a standardized UI library, Codex vastly reduces both the maintenance burden of creating custom UI components, as well as the time needed for implementing product UIs. Codex also provides a shared vocabulary for talking about design and implementation, which increases efficiency between Design & Engineering.
        • Codex will lose utility if adoption doesn’t increase and Codex isn’t widely used, and currently it is not being adopted or widely used in some places because the tooling isn't ready for some use cases. It may also need more prominent advertising/awareness. This work is a priority because teams must be able to adopt Codex organically, and currently not all can without blockers to adoption being addressed first.
        • We're anticipating that this will mean:
          • Discovery - What do different teams show us is blocking them? What are the use cases and blockers about which we are not yet aware?
          • Improvement - Example: We know that Codex PHP 1.0 will unblock server-side adoption.
          • Metrics deep dive - Example: What do the baseline metrics established in Q1 tell us about where organic adoption is not working (and are there lessons from OOUI adoption in years past)?
        • The KR will focus on tracking “official” usage (i.e. adoption that follows the documented guidance) separately from partial or piecemeal usage, e.g. when teams use only part of a component or just the CSS. The latter type of adoption incurs a higher maintenance cost than out-of-the-box component usage.
      • Key result PES1.5: 20% of service SLOs result in an impactful decision made by the end of Q4.
        • Service Level Objectives (SLOs) are a tool used to determine priorities based on data from service reliability. For instance, whether a down service needs immediate attention. SLOs work most effectively when ownership is clear, and everyone is using them. To make this happen we need to shift development culture toward adopting SLOs for every service. Building on the last few quarters of creating SLOs and testing them with service teams, we've identified an opportunity to clarify the value of SLOs, so that we can continue to spread this culture.
          • We have 19 SLOs currently.
          • We want to incentivize SLOs for services that would be most likely to leverage them. If we get ~3-4 (~20% 0f 19) "impactful decisions" from our current crop, great, but we anticipate we'll need to make more. The denominator will increase, but that further incentivizes targeting the right services.
          • Q4 is the end of the timebox because we want more than one cycle of data, and each quarter is a cycle. It also gives us space to shore up tooling, pilot SRE-alerting, etc.
        • Success looks like:
          • Impactful decision = “is this service currently reliable enough, or do we need to prioritize work to fix it” -- that is, it's as much a decision to find an error and say it's OK not to prioritize it, as it is to find an error and prioritize correcting it.
          • We want decisions to be diverse (e.g. Architectural vs Organizational vs Implementation; or affirmative vs deciding not to do something), because this is about spreading the value of SLOs and shifting culture. All the same type of decision or all from the same team doesn't accomplish that, even if it's good.
          • Even if we don't meet the KR target, we hypothesize that we'll have learned valuable information about why (e.g. we're targeting the wrong services).
          • Important: 80% of our SLOs not having an impactful decision is not a failure state for those, because most of the time services should not be failing.
      • Key result PES1.6: 20% of critical unowned services, according to a risk analysis framework, get owners committed by the end of Q4.
        • Clear code and service ownership is critical to ensuring the Wikimedia Foundation’s technical infrastructure remains reliable, scalable, and secure. Addressing current gaps in ownership will improve accountability, enhance cross-team collaboration, fast-track effective decision-making, and reduce risks to platform stability, security and sustainability. Additionally, it will provide greater clarity for Wikimedia affiliates and volunteers, helping them understand who is responsible for maintaining and supporting key services.
          • We estimate there are ~20 critical services without owners.
          • We think we can assign 4 owners over 4 months during Q3/4. The first 2 months or so will be setting ourselves up for success with prep work.
          • We plan to develop a risk analysis framework to determine criticality, as part of hypothesis work under this KR.
      • Key result PES1.7: By the end of Q4, 85% of wishes have a response within 10 working days, and a monthly update is posted on the work we committed to implement.
        • Having revamped Wishlist triage in the first half of the year, we want to consistently demonstrate that volunteers are getting responses to their Wishes plus a monthly update consisting of what’s coming, what’s pending or blocked, and what’s being scoped. We will judge the metric by measuring response time on a rolling average over a month, and aim to sustain that for at least a month.

Hipotezy

Q1

Pierwszy kwartał (Q1) rocznego planu WMF obejmuje okres od lipca do września.

Hipotezy: Doświadczenia Wiki (WE)

[ Kluczowe rezultaty WE ]

Dyskusja

Skrócona nazwa Zawartość Q1 Szczegóły i dyskusja
WE1.1.1 Jeśli poprosimy nowych (lub nowszych) wolontariuszy wklejających tekst z zewnętrznej strony o potwierdzenie, czy to oni są autorami treści, które zamierzają dodać, odnotujemy ≥10% spadek odsetka nowych treści edytowanych przez nowych (lub nowszych) wolontariuszy, które są cofane na podstawie WP:NPA (i powiązanych zasad).
WE1.1.2 Jeśli udostępnimy wstępną wersję beta sugerowanej edycji „Popraw ton”, będziemy mogli sprawdzić, czy ten nowy format sugerowanych edycji jest skutecznym sposobem na zwiększenie liczby konstruktywnych edycji nowych użytkowników bez zwiększania obciążenia moderatorów/recenzentów.
WE1.1.3 Jeśli wdrożymy nowy tryb sugestii skierowany do starszych użytkowników w edytorze wizualnym (mobilnym i stacjonarnym) jako funkcję beta z co najmniej trzema nowymi sugestiami edycji, dowiemy się, jakie zmiany należy wprowadzić przed oceną doświadczeń nowych (lub nowszych) wolontariuszy w ramach kontrolowanego eksperymentu.
WE1.1.4 Jeśli wdrożymy funkcję sprawdzania odnośników w en.wiki w ramach kontrolowanego eksperymentu, zauważymy ≥10% wzrost liczby konstruktywnych edycji publikowanych przez nowych (lub nowszych) wolontariuszy i dowiemy się, czy wśród patrolujących i moderatorów istnieje wystarczające poparcie, aby umożliwić szersze stosowanie tej funkcji.
WE1.1.5 Jeśli przetestujemy system progresji za pomocą prototypów projektowych z nowymi użytkownikami, będziemy mogli zidentyfikować, jakie rodzaje kamieni milowych, wskazówek i uznania są postrzegane jako najbardziej motywujące, a następnie wykorzystać te spostrzeżenia do sfinalizowania projektu przyszłych eksperymentów pilotażowych w wiki.
WE1.1.6 Jeśli zbadamy najważniejsze bariery techniczne, społeczne i behawioralne oraz czynniki sprzyjające edycji mobilnej w Internecie poprzez badania użytkowników i analizę danych, wygenerujemy co najmniej 3 praktyczne wnioski, które wypełnią kluczowe luki w wiedzy i wzmocnią naszą zdolność do pewnego ustalania priorytetów inwestycji w produkty na drugą połowę roku finansowego 2025/2026 i kolejne lata.
WE1.2.1 Jeśli stworzymy proof-of-concept dla wyświetlania danych dotyczących współpracy na wiki, będziemy mogli zebrać opinie od co najmniej 30 edytorów, z których 70% uzna tę funkcję za przydatną i pomocną w rozwoju współpracy.
WE1.3.1 Jeśli wykorzystamy potrzeby zidentyfikowane w poprzednich badaniach i projektach oraz udostępnimy wczesne makiety X najbardziej wpływowych modułów moderatora, będziemy mogli zmodyfikować stronę główną pod kątem działań moderacyjnych.
WE1.3.2 Jeśli zmodyfikujemy stronę startową dla nowych użytkowników, aby warunkowo wyświetlać moduły moderatora, będziemy mogli udowodnić wykonalność wykorzystania strony startowej dla moderatorów.
WE1.4.1 Jeśli wprowadzimy szereg ulepszeń wskazanych w T396489, zmniejszymy liczbę powolnych zapytań dotyczących ostatnich zmian o X procent w dużych wiki. Dzięki temu narzędzia moderatora będą mogły wdrażać moduły strony głównej w tych wiki bez specjalnych obaw o wydajność bazy danych. T400696
WE2.1.1 Jeśli zaprosimy native speakerów z małych wiki poprzez baner CentralNotice na popularnej Wikipedii w ich regionie do udziału w SuggestedEdits i innych funkcjach wzrostu, będziemy mogli ocenić, czy takie podejście przyciąga nowych native speakerów i czy używają oni tych narzędzi do edycji w celu ulepszenia ważnych treści.
WE2.1.2 Jeśli opracujemy i udostępnimy sugestie tłumaczeń dostosowane do potrzeb nowych redaktorów, będziemy mogli sprawdzić, czy takie podejście daje lepsze wyniki tłumaczenia w porównaniu z naszym obecnym podejściem.

Odnosi się to do znanych wyzwań, przed którymi stają nowi redaktorzy, w stosunku do których istnieje większe prawdopodobieństwo usunięcia artykułów ich autorstwa. Kierując ich do tłumaczenia łatwiejszych treści, chcemy zapewnić mniej przytłaczające i bardziej przystępne wprowadzenie do procesu tłumaczenia. Dobre artykuły i sekcje mogą charakteryzować się ograniczoną złożonością pod względem formatowania i ogólnej długości.

WE2.1.3 Jeśli dowiemy się więcej o doświadczeniach redaktorów podczas tworzenia nowych artykułów i sekcji (w tym o motywacjach, trudnościach i reakcjach na nowe pomysły dotyczące lepszego wsparcia), odkryjemy potrzeby i zachowania użytkowników, które dostarczą praktycznych informacji i strategii dla działów produktu, projektowania i inżynierii w celu poprawy doświadczeń związanych z tworzeniem artykułów.
WE2.1.4 Jeśli poprzez warsztaty partycypacyjne lub wywiady zbadamy, w jaki sposób trzy średniej wielkości Wikipedie podchodzą do luk w wiedzy i jej znaczenia, odkryjemy robocze definicje lub koncepcje ramowe „wiedzy niezbędnej”, które są istotne dla każdej społeczności.
WE2.2.1 Jeśli będziemy śledzić wdrażanie Parsoida i zintegrujemy Wikifunctions w większości Wikisłowników i niektórych Wikipediach o małym natężeniu ruchu, uzyskamy testy potrzebne do solidnego wdrożenia w większych wiki.
WE2.2.2 Jeśli umożliwimy Wikifunctions generowanie tabel HTML, stylów i linków, za pomocą funkcji wyświetlającej tabelę koniugacji zademonstrujemy jej zdolność do generowania nowej wiedzy w Wikisłownikach, wykraczającej poza proste konwersje.
WE2.2.3 Jeśli dodamy obsługę encji Wikidata w osadzonych wywołaniach funkcji, udostępnimy ponad 200 nowych funkcji, które mogą generować kompleksowe zdania przy użyciu encji Wikidata, dzięki czemu funkcje będą łatwiejsze w użyciu w projektach Wikimedia.
WE2.2.4 Jeśli opracujemy plan architektury dotyczący lokalizacji treści abstrakcyjnych i ich interakcji z Wikipedią, będziemy lepiej przygotowani do wdrożenia platformy Abstract Wikipedia w celu zwiększenia dostępności wysokiej jakości treści encyklopedycznych.
WE2.2.5 Jeśli zdefiniujemy i rozpowszechnimy wśród zespołów ds. produktów i technologii potrzeby produktowe dotyczące cytatów wymaganych dla treści abstrakcyjnych, będziemy w stanie prowadzić prace międzyprojektowe w ramach Wikipedii w celu dostarczania informacji o pochodzeniu dołączanych do treści abstrakcyjnych, co ma kluczowe znaczenie dla pomyślnego wdrożenia tych treści w różnych wiki.
WE2.2.6 Jeśli uczynimy format wewnętrznych żądań backendu bardziej wyrazistym i zwięzłym, będziemy mogli zwiększyć stabilność systemu, wspierając tym samym szersze wdrożenie.
WE2.2.7 Jeśli udostępnimy prototypowe fragmenty wykorzystujące Wikidata i wywołania Wikifunctions do generowania fragmentów w języku naturalnym, pokażemy gotowość do realizacji projektu i będziemy gotowi do wykorzystania go do szkolenia sztucznej inteligencji, dzięki czemu ludzie nie będą musieli zbytnio zastanawiać się nad funkcjami.
WE2.2.8 Jeśli zapewnimy import stwierdzeń Wikidata z kwalifikatorami, możliwe będzie generowanie wieloaspektowych faktów (faktów wymagających więcej niż tylko podmiotu/orzeczenia/wartości do wyrażenia), które obejmują około 50% treści encyklopedycznych w Wikidata.
WE2.2.9 Jeśli zapewnimy buforowanie pobranych encji Wikidata, skrócimy o co najmniej 50% średni czas działania funkcji opartych na treści Wikidata, zmniejszając liczbę przekroczeń limitu czasu i frustrację użytkowników.
WE2.2.10 Jeśli udostępnimy komponent leksemów Wikidata w interfejsie użytkownika Wikifunctions, użytkownicy będą mogli identyfikować i wybierać odpowiednie leksemy bez opuszczania platformy/Wikifunctions, co ograniczy konieczność przełączania się między kontekstami i umożliwi szybsze i skuteczniejsze tworzenie funkcji związanych z językiem.
WE2.2.11 Jeśli uwzględnimy uwagi społeczności Dagbani dotyczące użyteczności integracji Wikifunctions z Wikipedią, zauważymy, że redaktorzy napotkają mniej lub nie napotkają żadnych krytycznych problemów z użytecznością podczas wstawiania funkcji do artykułu podczas testów.
WE3.1.1 Jeśli przeprowadzimy testy A/B ulepszonej wersji funkcji przeglądania w kartach w aplikacji na iOS, zauważymy 5% wzrost wielodniowego użytkowania wśród użytkowników kart.
WE3.1.3 Jeśli udostępnimy użytkownikom nowy sposób przeglądania odpowiednich treści graficznych lub wideo na stronach artykułów, odnotujemy co najmniej 3% wzrost współczynnika klikalności wśród użytkowników, którym zostanie przedstawiona ta funkcja.
WE3.1.4 Jeśli przedstawimy czytelnikom kilka koncepcji poruszania się po sieci wiedzy w wiki, otrzymamy listę priorytetowych koncepcji do dalszego rozwoju.
WE3.1.5 Jeśli zapewnimy czytelnikom internetowym możliwość wyświetlenia tłumaczenia maszynowego treści Wikipedii niedostępnych w ich języku, dowiemy się, czy wzrosła aktywność czytelnicza, mierzona jako 3% wzrost interakcji ze stronami, przyciągając czytelników do wiki w lokalnym języku, co może potencjalnie zwiększyć lokalną aktywność edytorską. Zostanie to zapewnione w ramach kontrolowanego testu A/B przez okres nie dłuższy niż 6 miesięcy w 13 edycjach wikipedii, które wyraziły wcześniej zgodę, przy użyciu otwartych usług tłumaczenia maszynowego już dostępnych dla redaktorów Wikipedii.
WE3.2.1 Jeśli będziemy współpracować z działem pozyskiwania funduszy, opracujemy bardziej angażujące, zintegrowane i spersonalizowane slajdy dla darczyńców w podsumowaniu roku na iOS, mierzone za pomocą testów użytkowników. Następnie w drugim kwartale zostanie sformułowana hipoteza, aby ocenić, czy ulepszone podsumowanie roku przyniosło o 5% więcej darowizn niż podsumowanie roku 2024.
WE3.2.2 Jeśli zachęcimy czytelników aplikacji na Androida na rynkach, na których nie prowadzimy kampanii fundraisingowych, do skonfigurowania opcjonalnego, dostosowywalnego (kwota i częstotliwość) przypomnienia o darowiznach w oparciu o ich korzystanie z Wikipedii, odnotujemy 5% wzrost darowizn w menu aplikacji na tych rynkach.
WE3.2.3 Jeśli przeprowadzimy test A/B na zalogowanych użytkownikach, aby wyświetlić subtelne warianty punktu wejścia do darowizn zarówno na urządzeniach mobilnych, jak i stacjonarnych, zaobserwujemy 2% wzrost liczby darowizn za pośrednictwem ścieżek testowych w porównaniu ze ścieżkami kontrolnymi.
WE3.3.1 Jeśli dodamy elementy spersonalizowane wymagające niewielkiego lub średniego wysiłku, o które prosili użytkownicy iOS w roku 2024–2025, do podsumowania roku 2025, odnotujemy 3% wzrost satysfakcji w porównaniu z rokiem poprzednim, mierząc ją za pomocą testów użyteczności lub testów beta.
WE3.3.2 Jeśli rozszerzymy istniejącą zakładkę „Edytuj” w systemie Android o spersonalizowane centrum aktywności, które będzie zawierało informacje na temat czytania i udziału w działaniach innych niż edycja, odnotujemy 5% wzrost wielodniowego zaangażowania w zakładkę w porównaniu z wersją oryginalną.
WE3.3.3 Jeśli wprowadzimy co najmniej jeden awatar do odblokowania w aplikacji na Androida dla posiadaczy kont — zdobyty poprzez znaczące działania czytelników, takie jak zapisanie określonej liczby artykułów — zwiększymy wielokrotne zaangażowanie z powiązanymi działaniami przez zalogowanych użytkowników o 10% w ciągu wielu dni.
WE3.3.4 Jeśli damy zalogowanym czytelnikom możliwość zapisywania artykułów na prywatnej liście do przeczytania, spodziewamy się wzrostu zaangażowania na stronie, mierzonego 5-procentowym wzrostem ruchu wewnętrznego dla czytelników korzystających z tej funkcji oraz statystycznie istotnym wzrostem dla wszystkich użytkowników.
WE3.3.5 Jeśli przeprowadzimy badanie użytkowników, które pozwoli czytelnikom internetowym gromadzić/pilnować treści z Wikipedii, co najmniej 10% uczestników zapisze co najmniej dwa różne rodzaje treści (np. artykuły, fragmenty, multimedia) do kolekcji.
WE3.4.1 Jeśli będziemy pracować nad wdrożeniem hybrydowego rozwiązania PoP/CDN, pozwoli nam to uruchomić zarówno pełne PoP, jak i mini PoP (fizyczne i w chmurze) w zależności od potrzeb, tworząc podstawę dla wdrożenia prototypowego mini PoP w przyszłości.
WE3.6.1 Jeśli przeprowadzimy test A/A dotyczący wskaźnika retencji użytkowników wylogowanych, ustalimy podstawowy wskaźnik retencji, który będziemy mogli wykorzystać w kolejnych kwartałach.
WE3.6.2 Jeśli stworzymy i opublikujemy definicję zalogowanego czytelnika, będziemy mogli wykorzystać tę definicję we wszystkich zespołach i hipotezach związanych z WE 3.3 KR.
WE3.6.3 Jeśli zaangażujemy społeczności w rozmowy na temat zmieniających się potrzeb czytelników oraz zmieniającego się charakteru wiedzy w Internecie, będziemy mogli wspólnie skupić się na tym, jak służyć czytelnikom i współpracować nad tym, czy i jak przetestować nasze różne pomysły (w tym dotyczące multimediów, wyszukiwania i odkrywania oraz uczenia maszynowego).
WE3.6.4 Jeśli zbadamy różne motywacje, zachowania i potrzeby stojące za tym, kiedy, dlaczego i w jaki sposób czytelnicy korzystają z Wikipedii i innych platform wiedzy, uzyskamy wyniki, które będziemy mogli wykorzystać do kształtowania i rozwoju naszej strategii konsumenckiej.
WE4.1.1 Jeśli stworzymy prototyp minimalnie funkcjonalnego, nieawaryjnego przepływu i będziemy utrzymywać otwartą pętlę informacji zwrotnej podczas jego opracowywania z użytkownikami posiadającymi rozszerzone uprawnienia, grupy te będą wspierać rozszerzone wdrożenie tego przepływu. Project page
WE4.2.1 Jeśli ujawnimy poziom ryzyka hCaptcha związanego z tworzeniem kont zaufanym funkcjonariuszom, skrócimy czas potrzebny do identyfikacji nieuczciwych użytkowników i zwiększymy liczbę wykrytych nieuczciwych kont utworzonych na platformie. Sukces hipotezy można zmierzyć, analizując wskaźnik blokad zastosowanych wobec kont, zgodność poziomów ryzyka hCaptcha i blokad kont ogółem oraz jakościowe opinie funkcjonariuszy.
WE4.2.2 Jeśli wygenerujemy sugestie dochodzeń do podjęcia przez użytkowników z dostępem CheckUser, zauważymy skrócenie czasu potrzebnego do identyfikacji kont nieuczciwych użytkowników oraz wzrost liczby zidentyfikowanych kont nieuczciwych użytkowników. O sukcesie będziemy wiedzieć, gdy zauważymy regularne korzystanie z funkcji „Sugerowane dochodzenia”, wzrost liczby środków zaradczych zastosowanych wobec kont zidentyfikowanych dzięki sugerowanym dochodzeniom oraz na podstawie jakościowych opinii przekazanych w ankietach.
WE4.2.3 Jeśli przeanalizujemy dane z testów tworzenia kont hCaptcha, zrozumiemy proces tworzenia kont, skuteczność testów i wyników hCaptcha oraz będziemy dysponować danymi niezbędnymi do dalszego wdrażania hCaptcha podczas tworzenia kont.
WE4.2.4 Jeśli wdrożymy UserInfoCard we wszystkich wiki, umożliwimy funkcjonariuszom i moderatorom skuteczniejsze identyfikowanie i ograniczanie kont nieuczciwych użytkowników. Project page
WE4.2.5 Jeśli przeprowadzimy badania, skonsultujemy się ze społecznościami i zbadamy rozwiązania techniczne, będziemy w stanie zdefiniować zestaw ustrukturyzowanych powodów blokowania, które będą mogły być stosowane we wszystkich wiki WMF.
WE4.2.6 Jeśli opracujemy możliwość wdrożenia klastrów opartych na OpenSearch na platformie danych, zespoły inżynierów ds. funkcji produktu będą mogły opracować systemy integrujące tę funkcję, charakteryzujące się dużą autonomią, odpornością i izolacją od innych systemów opartych na wyszukiwaniu. Pierwszym i głównym użytkownikiem tego systemu będzie usługa IPoid.
WE4.2.7 Jeśli wdrożymy integrację hCaptcha Enterprise w kilku produkcyjnych wersjach Wikipedii w ramach pilotażowego programu, będziemy mogli zebrać dane na temat skuteczności i wartości hCaptcha Enterprise w zakresie przeciwdziałania nadużyciom, wykrywania botów, użyteczności i dostępności.
WE4.3.1 Jeśli zintegrujemy obsługę nowych plików cookie Edge Uniques z requestctl, naszym silnikiem reguł brzegowych dla SRE zwalczających nadużycia, będziemy w stanie lepiej chronić się przed atakami DDoS i ponownym wykorzystaniem treści.
WE4.4.1 Jeśli uda nam się wprowadzić ulepszenia na podstawie opinii uzyskanych w ramach pilotażu i wdrożyć konta tymczasowe we wszystkich projektach, będziemy w stanie ograniczyć dostęp do danych osobowych (adresów IP) niezarejestrowanych użytkowników we wszystkich naszych projektach do mniej niż 0,1% wszystkich (zarejestrowanych) użytkowników. Project page
WE4.4.2 Jeśli będziemy komunikować się z odpowiednimi interesariuszami ruchu (w tym społecznościami wiki i globalnymi funkcjonariuszami) w sposób jasny i terminowy, będziemy w stanie wdrożyć określone rozwiązania we wszystkich pozostałych wiki, zmniejszyć nakład pracy na rzeczy wykryte w ostatniej chwili i uniknąć cofania wdrożenia.
WE4.4.3 Jeśli ułatwimy patrolującym filtrowanie działań i przeglądanie aktywności kont tymczasowych na podstawie ich adresów IP, umożliwi to pomyślne wdrożenie kont tymczasowych we wszystkich wiki.
WE4.4.4 Jeśli umożliwimy cofnięcie dostępu do ujawniania adresów IP kont tymczasowych zgodnie z polityką dostępu do ujawniania adresów IP i udostępnimy tę funkcję w większej liczbie miejsc, umożliwimy pomyślne wdrożenie kont tymczasowych we wszystkich wiki.
WE4.5.1 Jeśli przeprowadzimy badania jakościowe w celu zidentyfikowania przykładów nadużyć ze strony osób o złych intencjach wspomaganych przez generatywną sztuczną inteligencję (takich jak spam, nękanie, długotrwałe nadużycia, nieujawnione płatne edycje lub kampanie dezinformacyjne), będziemy w stanie ocenić ryzyko dla naszych modeli społecznościowych i wygenerować pomysły na ograniczenie różnych rodzajów nadużyć wspomaganych przez generatywną sztuczną inteligencję.
WE4.6.1 Jeśli zautomatyzujemy proces synchronizacji kont w Zendesk w celu resetowania haseł, zmniejszy to obciążenie działu T&S i pozwoli mu obsłużyć więcej przychodzących wniosków o resetowanie 2FA.
WE4.6.2 Jeśli będziemy wspierać i zachęcać użytkowników do rejestrowania wielu czynników uwierzytelniających, użytkownicy z włączoną funkcją 2FA będą rzadziej blokować dostęp do własnych kont.
WE4.6.3 Jeśli zezwolimy wszystkim użytkownikom z potwierdzonym adresem e-mail na włączenie funkcji 2FA dla swoich kont, ale nie będziemy aktywnie informować użytkowników o tej zmianie, obciążenie naszego działu pomocy technicznej pozostanie na zrównoważonym poziomie.
WE5.1.1 Jeśli używamy różnych backendów pamięci masowej dla sesji uwierzytelnionych i anonimowych, będziemy w stanie chronić Sessionstore przed atakami DDoS i scrapersami o dużej przepustowości, nie przeciążając go anonimowymi sesjami tworzonymi w celu zapobiegania CSRF na stronach uwierzytelniających. T398814
WE5.1.2 Jeśli zmienimy pliki cookie sesji MediaWiki na format strukturalny z podpisem kryptograficznym, będziemy mogli wykorzystać obecność sesji jako czynnik ochrony przed scraperami, umożliwiając zaufaną weryfikację sesji na obrzeżach sieci w sposób wydajny i wysoce skalowalny. T398815
WE5.1.3 Jeśli stworzymy rozwiązanie ograniczające szybkość dla bramki API przy użyciu lokalnego środowiska programistycznego opartego na Kubernetes, będziemy mogli określić najlepszą opcję do przetestowania z ruchem produkcyjnym, porównując wydajność i funkcjonalność co najmniej trzech różnych usług ograniczających szybkość. T398913
WE5.2.1 Jeśli przeprojektujemy interfejs użytkownika REST API Sandbox, aby lepiej odpowiadał potrzebom informacyjnym programistów, poprawimy przejrzystość dokumentacji, co zostanie potwierdzone w testach użyteczności.
WE5.2.2 Jeśli przekierujemy wszystkie API pod rest.php przez centralną bramę, odblokujemy środki scentralizowanego zarządzania API i będziemy mogli rozpocząć spójne mierzenie ruchu REST API i wzorców użytkowania, aby uzyskać informacje, które będą podstawą przyszłych decyzji i działań.
WE5.2.3 Jeśli wdrożymy pulpity monitorowania i alarmy dla REST API MediaWiki, będziemy mogli wykazać zrównoważony, użyteczny i powtarzalny sposób poprawy widoczności zachowania naszych systemów i szybszego wykrywania problemów, zwłaszcza podczas krytycznych modyfikacji.
WE5.3.1 Jeśli rozszerzymy i usprawnimy wytyczne dotyczące atrybucji UX, aktualizując jednocześnie wszelkie istniejące wytyczne, stworzymy podstawowy zestaw ulepszonych wytycznych gotowych do wewnętrznego testowania i iteracyjnego udoskonalania w celu przygotowania ich do szerszego publicznego użytku.
WE5.3.2 Jeśli stworzymy prezentację pokazującą korzyści z przypisywania autorstwa Wikipedii do treści ponownie wykorzystywanych przez osoby trzecie i ich użytkowników końcowych, będziemy mogli wesprzeć WME4.1 i WME4.2, umożliwiając co najmniej jednemu dodatkowemu partnerowi ponownego wykorzystania wyrażenie zgody na pojawienie się w studium przypadku lub demonstracji dotyczącej przypisywania autorstwa do końca pierwszego kwartału.
WE5.4.1 Jeśli zapewnimy, że większość żądań internetowych otrzyma unikalny plik cookie, łatwiej będzie zidentyfikować boty i sfałszowane żądania.
WE5.4.2 Jeśli stworzymy skalowalny sposób identyfikacji znanych klientów, będziemy mogli zezwolić na wyjątki od ogólnych limitów szybkości dla botów o zweryfikowanym pochodzeniu i przejść do systematycznego egzekwowania naszych zasad.
WE5.4.3 Jeśli zreorganizujemy filtrowanie żądań tekstowych w CDN w oparciu o podejście oparte na listach dozwolonych/zablokowanych, będziemy mogli egzekwować bardziej rygorystyczne ogólne limity szybkości dla botów i usprawnić filtrowanie ruchu.
WE5.4.4 Jeśli opracujemy ujednoliconą strategię pomiaru, umożliwimy ocenę wieloletniej strategii „odpowiedzialnego korzystania z infrastruktury” oraz zdefiniujemy plan działania, który będzie wytyczał kierunki rozwoju wskaźników i możliwości raportowania.
WE6.1.1 Jeśli przeniesiemy codzienne kompilacje obrazów na serwer wdrożeniowy i dodamy aktualizacje obrazów uruchamiane przez wybrane działania wdrożeniowe, odkryjemy ograniczenia i ustalimy podstawowy czas potrzebny do przeprowadzenia bardziej ciągłych wdrożeń.
WE6.1.3 Jeśli dodamy farmy wiki do środowiska testowego przed połączeniem, umożliwi to zespołom programistycznym pracującym nad produkcją, które wymagają wielu wiki do testowania swoich poprawek w izolacji, większą pewność przed produkcją i zmniejszy liczbę wykrytych błędów.
WE6.2.1 Jeśli przejrzymy i opublikujemy naszą listę kontrolną gotowości do produkcji, która jasno określa warunki wstępne, jakie musi spełnić usługa, aby została uznana za gotową do produkcji, wraz z zadaniami, które można wykonać samodzielnie, dostosujemy oczekiwania SRE i zespołów programistów, poprawiając ogólną wydajność operacyjną i skalowalność.
WE6.2.2 Jeśli ogłosimy utworzenie bibliotek Golang i nodejs, które wyodrębnią wiele żmudnych zadań dla programistów, zareagują oni, przekazując swoje opinie i wyrażając zainteresowanie.
WE6.2.3 Jeśli stworzymy listę kontrolną/arkusz roboczy, programiści będą mogli w pełni przygotować się do przeglądu projektu trwałości danych.
WE6.3.1 Jeśli w pierwszym kwartale wdrożymy co najmniej 70 Wikipedii o niskim natężeniu ruchu, z wyłączeniem wiki obsługujących różne wersje językowe, zwiększymy nasze zaufanie do ostatecznego wdrożenia w 10 najpopularniejszych wiki, które będą miały większy wpływ na liczbę odsłon obsługiwanych przez Parsoid.
WE6.4.1 Jeśli wdrożymy tabelę rozdzielającą linki Commons w osobnym klastrze, zwiększymy szanse na utrzymanie zrównoważonego wzrostu bazy danych Commons. T398709
WE6.4.2 Jeśli my (SRE) zapewnimy pomoc zespołom inżynierów MediaWiki – poprzez stworzenie dokumentacji, przygotowanie niezbędnej infrastruktury (np. pakietów PHP, obrazów kontenerów) oraz oferowanie wskazówek i przeglądów – będą oni mogli z pewnością rozpocząć produkcyjną aktualizację PHP 8.3 na początku drugiego kwartału. T360995
WE6.4.3 Jeśli zaczniemy wymagać fizycznego drugiego czynnika (klucza bezpieczeństwa sprzętowego) do logowania SSH przez użytkowników z podwyższonymi uprawnieniami systemowymi, zmniejszymy ryzyko, że zainfekowany laptop spowoduje poważne naruszenie bezpieczeństwa.
WE6.4.4 Jeśli ujednolicimy nasze domeny, obsługując wszystkie wyświetlenia stron w witrynach MediaWiki za pośrednictwem domeny kanonicznej, zmniejszymy złożoność platformy i ryzyko związane z optymalizacją pod kątem wyszukiwarek (SEO), eliminując przekierowania do subdomen mobilnych. Realizację tego zadania mierzy się poprzez zmniejszenie liczby przekierowań dla odwiedzin mobilnych w domenach kanonicznych ze 100% do 0%. T214998
WE6.4.5 If the MediaWiki Engineering Team actively monitor and fix issues in MediaWiki related to the PHP 8.3 upgrade, the SRE team will be unblocked to proceed with the PHP 8.3 upgrade by the start of Q2. T360995
Hipotezy: Usługi sygnałów i danych (SDS)

[ Kluczowe rezultaty SDS ]

Dyskusja

Skrót hipotezy Tekst Q1 Szczegóły i dyskusja
SDS1.1.1 Jeśli przeanalizujemy skuteczność heurystyki automatycznego wykrywania ruchu w naszych zestawach danych dotyczących wyświetleń stron, będziemy w stanie opracować wskaźniki jakości danych opisujące ich wydajność i określić potrzebę dalszych inwestycji w tę heurystykę.
SDS1.2.2 Jeśli przeniesiemy proces zrzutu XML z obecnej infrastruktury „Dumps 1” do potoku danych wykorzystującego potoki treści MediaWiki, będziemy w stanie zagwarantować SLO i wyłączyć eksport XML oparty na „Dumps 1”.
SDS1.2.3 Jeśli przeprowadzimy przegląd i weryfikację SLO dla historii treści MediaWiki oraz platformy zdarzeń / bramki zdarzeń, będziemy mogli zweryfikować klientów, wskaźniki i zależnych interesariuszy oraz zidentyfikować ulepszenia, które mogą być konieczne dla SLO, co pomoże nam wyjaśnić wszelkie luki w naszych tygodniowych gwarancjach dostaw.
SDS2.1.1 Jeśli będziemy ściśle współpracować z zespołami przeprowadzającymi eksperymenty, dowiemy się, jak uczynić system bardziej samoobsługowym w przyszłości oraz jakie wyzwania koncepcyjne lub techniczne mogą napotkać.
SDS2.1.2 Jeśli uda nam się wdrożyć lepsze debugowanie rejestrowania zdarzeń, zespoły produktowe będą wiedzieć, że ich eksperymenty gromadzą dane o zdarzeniach zgodnie z oczekiwaniami, co zwiększy zaufanie właścicieli eksperymentów.
SDS2.1.3 Jeśli poprawimy rejestrowanie i obserwowalność komponentu platformy eksperymentalnej służącego do testów A/B (xLab) oraz powiązanych części MediaWiki, będziemy w stanie ustalić podstawowe parametry wydajności systemu i reagować na niepowodzenia związane z eksperymentami.
SDS2.1.4 Jeśli raz w miesiącu będziemy dzielić się historiami i wynikami eksperymentów w całej organizacji (podczas spotkań Product Ops, spotkań zespołu projektowego i prezentacji między zespołami), stworzymy organiczne przyjęcie platformy eksperymentalnej.
SDS2.1.5 Jeśli poinformujemy użytkowników, że ich instrument, jeśli został utworzony w xLab, zawiera zestaw atrybutów, które zmieniają kategorię ryzyka, zniechęcimy użytkowników instrumentów do nadmiernego gromadzenia danych i zwiększymy przejrzystość w zakresie kombinacji atrybutów wymagających przeglądu prywatności.
Hipotezy dotyczące przyszłych odbiorców (FA)

[ FA - Kluczowe rezultaty ]

Dyskusja

Skrót hipotezy Tekst Q1 Szczegóły i dyskusja
FA1.1.1 Jeśli 1) zaoferujemy zbierającym media na innych platformach (takich jak Letterboxd, Goodreads i RateMyMusic) sposoby wzbogacenia ich zbiorów o wiedzę dostępną wyłącznie w Wikipedii lub 2) zaoferujemy tym zbierającym media interesujące treści, które można udostępniać w mediach społecznościowych, będziemy w stanie zwiększyć zasięg Wikipedii poza platformą.
FA2.1.1 Jeśli w pierwszym kwartale zbudujemy nasze wewnętrzne zdolności do tworzenia krótkich treści wideo (poprzez zwiększenie liczebności naszego zespołu oraz audyt i identyfikację możliwości zwiększenia wydajności naszego obecnego procesu produkcji), będziemy w stanie wykorzystać wnioski wyciągnięte z treści stworzonych w roku finansowym 2024-2025 i osiągnąć wyższy zasięg treści wyprodukowanych w drugim kwartale roku finansowego 2025-2026 w porównaniu z rokiem poprzednim.
Hipotezy dotyczące wsparcia produktu i inżynierii (PES)

[ Kluczowe rezultaty PES ]

Dyskusja

Skrót hipotezy Tekst Q1 Szczegóły i dyskusja
PES1.1.1 Jeśli wesprzemy xLab, Charts i ToneCheck w definiowaniu wskaźników SLI (Service Level Indicators) w Prometheus i wdrożymy te Service Level Objectives (SLO) w Pyrra, poznamy ograniczenia i skrajne przypadki naszych narzędzi w wielu złożonych scenariuszach, a także wyjaśnimy, jakie iteracje są potrzebne dla szablonu SLO, co pomoże nam lepiej wspierać 6 planowanych SLO dla KR.
PES1.1.2 Jeśli przetestujemy dwa zestawy pulpitów alertów SLO, dowiemy się, jak trudne byłoby wdrożenie odpowiednich narzędzi, które pozwoliłyby właścicielom usług jasno zrozumieć ich zobowiązania, a także to, czy musimy przejść na inne narzędzie, które oferuje tylko jeden widok konkretnego SLO. Jeden pulpit nawigacyjny będzie służył do sporządzania raportów kwartalnych (w których ustalane są rzeczywiste umowy dotyczące poziomu usług dla budżetu błędów), a mniejszy, dynamiczny pulpit (zwany „rolowanym”) będzie służył do codziennych operacji i alertów.
PES1.1.3 Jeśli będziemy nadal wspierać grupę Abstract Wikipedia w opracowywaniu SLO (Service Level Objectives) dla projektu Wikifunctions, dowiemy się, jak zdefiniować listę celów SLO (wraz ze wskaźnikami poziomu usług) dla złożonej funkcji, która jest obecnie dodawana do krytycznego przepływu pracy użytkownika: renderowania artykułów Wiki. Dowiemy się również, jak prawidłowo wizualizować powiązane budżety błędów i ostrzegać o nich za pomocą pulpitów nawigacyjnych i monitorów udostępnianych przez SRE.
PES1.1.4 Jeśli będziemy wspierać grupę Data Platform w przeglądaniu i iteracji celów poziomu usług (SLO) dla projektu MediaWiki Content History, dowiemy się, jak wykorzystać SLO do wspierania odpowiedzialności za usługi, gdy usługi przetwarzania wsadowego i strumieniowego są koordynowane w celu aktualizacji zbioru danych, zapewniając jego spójność i dostępność dla użytkowników końcowych.
PES1.2.1 Jeśli stworzymy 3 ukierunkowane ulepszenia do listy życzeń, zachęcimy o 30% więcej unikalnych uczestników do udziału w liście życzeń
PES1.2.2 Jeśli w ciągu 72 godzin (w tym odrzucenie, wyjaśnienie, oznaczenie usług nieobsługiwanych itp.) dokonamy selekcji zgłoszonych życzeń i przypiszemy im opiekuna (np. kierownika produktu, itp.), poprzez porównanie nowych życzeń z tabelą opiekunów i przypisanie „kategorii opiekuna” do najbardziej odpowiedniego zespołu produktowego lub osoby, opiekunowie (np. menedżerowie produktu) będą w stanie ocenić życzenia i odpowiedzieć na nie w ciągu 10 dni lub mniej.
PES1.2.3 Jeśli przeprowadzimy pilotażowe działania mające na celu identyfikację sygnałów płynących od społeczności, uwzględnimy więcej opinii wolontariuszy w naszych działaniach związanych z ustalaniem priorytetów w oparciu o informacje od społeczności.
PES1.2.4 Jeśli w pierwszym kwartale przeprowadzimy pilotażowy proces kwartalnego przeglądu życzeń i sygnałów płynących od społeczności z udziałem trzech zespołów, zaangażujemy menedżerów produktu do uwzględnienia sygnałów płynących od społeczności w ich kwartalnych i rocznych procesach planowania.
PES1.3.1 Jeśli do końca pierwszego kwartału skoordynujemy trzy sesje planowania funkcjonalnego z działem komunikacji i zespołami produktowymi w celu uzgodnienia komunikatów, potrzeb kreatywnych i harmonogramów kampanii dla inicjatyw WP25, sfinalizujemy briefy kreatywne dla wszystkich trzech eksperymentów kampanii (25YiR, Easter Eggs, WikiRun).
PES1.3.2 Jeśli utworzymy komitet sterujący z przedstawicielami działu projektowania i inżynierii funkcji, będziemy w stanie zdefiniować podstawowe wskaźniki dotyczące wkładu w Codex: świadomość, wykorzystanie, jakość wkładu i ilość. Wnioski z oceny tych podstawowych wskaźników pomogą nam określić plan działania na rzecz zjednoczenia wzrostu i dywersyfikacji bazy współpracowników Codex.

Q2

Drugi kwartał (Q2) rocznego planu WMF obejmuje okres od października do grudnia.

Hipotezy dotyczące Doświadczenia Wiki (WE)

[ WE - kluczowe rezultaty ]

Dyskusja

Skrócona nazwa hipotezy Tekst dla Q2 Szczegóły i dyskusja
WE1.1.1 Jeśli przeanalizujemy z góry ustalony zestaw wskaźników wyprzedzających na ≥2 tygodnie po rozpoczęciu testu Paste Check A/B, będziemy w stanie zidentyfikować, które aspekty całościowego doświadczenia wymagają dostosowania lub zbadania, zanim będziemy mogli z całą pewnością ocenić wpływ tej funkcji.
WE1.1.4 Jeśli wdrożymy funkcję sprawdzania referencji (Reference Check) w en.wiki w ramach kontrolowanego eksperymentu, zauważymy ≥4% wzrost liczby konstruktywnych edycji publikowanych przez nowych (lub nowszych) wolontariuszy i dowiemy się, czy wśród patrolujących i moderatorów istnieje wystarczające poparcie, aby umożliwić szersze stosowanie tej funkcji.
WE1.1.7 Jeśli przeanalizujemy z góry ustalony zestaw wskaźników wyprzedzających ≥2 tygodnie po rozpoczęciu testu A/B sprawdzającego ton, będziemy w stanie zidentyfikować, które aspekty całościowego doświadczenia wymagają dostosowania lub zbadania, zanim będziemy mogli z całą pewnością ocenić wpływ tej funkcji.
WE1.1.8 Jeśli zastosujemy model Tone Check do opublikowanych artykułów, dowiemy się, czy możemy zidentyfikować ≥10 000 problemów związanych z tonem (każdy z wynikiem prawdopodobieństwa 0,8 lub wyższym), które są potrzebne do stworzenia wysokiej jakości (dokładność ≥ 70%) puli sugestii, które pomogą redaktorom poprawić ton artykułów.
WE1.1.10 Jeśli przeprowadzimy wywiady z około 10 doświadczonymi wolontariuszami z en.wiki i fr.wiki, którzy piszą filtry nadużyć (oraz inne gadżety/skrypty/szablony/powiadomienia o edycjach) w celu automatyzacji procesów patrolowania/moderowania, zidentyfikujemy co najmniej 3 wzorce/potrzeby, które pomogą ukształtować propozycję wartości tworzonych przez społeczność kontroli edycji.
WE1.1.11 Jeśli przeprowadzimy ankietę wśród ≥500 osób, które odniosły sukces jako nowicjusze[i], i uzyskamy wysokiej jakości dane reprezentatywne dla szerszej populacji osób, które odniosły sukces jako nowicjusze w projektach, będziemy w stanie zidentyfikować ≥4 praktyczne wnioski, które możemy wykorzystać do ustalenia priorytetów dotyczących aspektów procesu wdrażania nowych edytorów, które należy poprawić.
WE1.1.12 Jeśli umożliwimy ≥3 wolontariuszom ocenę po ≥30 przykładowych edycji, dla każdego z 10 nowych języków, do których zamierzamy rozszerzyć Tone Check, dowiemy się, jak często wolontariusze zgadzają się z przewidywaniami modelu i będziemy mogli zdecydować, do których nowych wiki zwrócić się w sprawie wdrożenia Tone Check.
WE1.1.13 Biorąc pod uwagę, że rozszerzyliśmy funkcję „Dodaj link” na 100% nowych wolontariuszy w angielskiej Wikipedii, poprawi się konstruktywna aktywizacja i retencja nowych użytkowników, co zwiększy liczbę konstruktywnych edycji dokonywanych przez nowych wolontariuszy o ≥4%.
WE1.2.3 Jeśli zlikwidujemy wymóg posiadania uprawnień organizatora wydarzeń, aby korzystać z funkcji rejestracji wydarzeń w małych i średnich wiki z użyciem narzędzia Event Organizer, to do końca roku finansowego w małych i średnich wiki powstanie co najmniej X dodatkowych wydarzeń*.
  • w oczekiwaniu na obliczenie wartości bazowej/docelowej.
WE1.2.4 Jeśli wprowadzimy co najmniej 2 ulepszenia do MVP Collaborative Contributions, to dzięki rejestracji wydarzeń powstanie więcej możliwości współpracy.
WE1.2.5 Jeśli na początku drugiego kwartału ustalimy jedną strategię wdrożenia rejestracji wydarzeń w Wikimedia Commons, będziemy mogli przetestować ją z organizatorami co najmniej jednej dużej kampanii i umożliwić korzystanie z tej funkcji pięciu lokalnym organizatorom.
WE1.3.3 Jeśli uruchomimy eksperyment mający na celu udostępnienie panelu moderatora nowym redaktorom, 10% użytkowników, którzy go odwiedzą, zrobi to przez dwa tygodnie z rzędu.
WE1.4.1 Jeśli wprowadzimy ulepszenia określone w T396489, zmniejszymy liczbę powolnych zapytań dotyczących ostatnich zmian o co najmniej 30% w dużych wiki, co umożliwi zespołowi Community Tech wdrożenie Watchlist Labels bez przeciążania bazy danych ostatnich zmian.
WE1.4.3 Jeśli wprowadzimy ostatnie zmiany i listę obserwowanych, będziemy mogli określić podstawowy poziom częstotliwości kliknięć na strony.
WE1.5.1 Jeśli wdrożymy pulpit nawigacyjny do analizy 7 wskaźników dotyczących edytorów i ujednolicimy obliczanie co najmniej jednego wskaźnika za pomocą dbt, umożliwimy edytorskim zespołom produktowym samodzielne uzyskiwanie informacji na temat wskaźników i opracujemy standard przechowywania logiki obliczania wskaźników.
WE1.5.2 Jeśli w drugim kwartale ustalimy, jakie działania moderacyjne uwzględnić w definicji moderatora, zespół Movement Insights będzie mógł opracować wskaźnik miesięcznej aktywności moderatorów w trzecim i czwartym kwartale.
WE2.1.3 Jeśli dowiemy się, jakie są doświadczenia redaktorów podczas tworzenia nowych artykułów i sekcji (w tym motywacje, problemy i ich reakcje na nowe pomysły dotyczące lepszego wsparcia), odkryjemy potrzeby i zachowania użytkowników, które dostarczą praktycznych informacji i strategii, które pomogą w ulepszeniu procesu tworzenia artykułów w zakresie produktu, projektowania i inżynierii.
WE2.2.12 Jeśli wdrożymy Wikifunctions w wiki, które mają włączoną funkcję Parsoid, będziemy mogli kontynuować testowanie, czy system pozostaje wydajny i użyteczny w coraz szerszych wdrożeniach.
WE2.2.13 Jeśli udostępnimy funkcję tabeli koniugacji społeczności Wikisłownika, uzyskamy cenne informacje zwrotne na temat korzystania z tej funkcji oraz wgląd w profile naszych użytkowników, które będziemy mogli wykorzystać przy przyszłych wdrożeniach.
WE2.2.14 Jeśli przyjrzymy się pracy społeczności Databox nad wykorzystaniem Wikidata do tworzenia infoboksów i zbadamy, czy Wikifunctions może być pomocne, będziemy w stanie zidentyfikować pierwsze eksperymenty z wykorzystaniem Wikifunctions w infoboxach.
WE2.2.15 Jeśli uświadomimy społeczności możliwość tworzenia i tłumaczenia komunikatów o błędach w Wikifunctions, zauważymy wzrost liczby pomocnych komunikatów o błędach.
WE2.2.16 Jeśli zaprezentujemy społeczności dostępne funkcje semantyczne, zauważymy wzrost funkcji gramatycznych o 50%.
WE2.2.17 Jeśli udostępnimy niestandardowy komponent do przeglądania stwierdzeń Wikidata w Wikifunctions, użytkownicy będą mogli lepiej zrozumieć dane pobierane z Wikidata i poczują się mniej nimi przytłoczeni.
WE2.2.18 Jeśli uda nam się zapobiec dziesięciokrotnym skokom zużycia pamięci, koordynator będzie w stanie lepiej obsługiwać obiekty Wikidata, wspierając użyteczność Wikifunctions jako platformy dla Abstrakcyjnej Wikipedii.
WE2.2.19 Jeśli umożliwimy użytkownikom udostępnianie bezpośrednich linków do konkretnych wywołań funkcji — w tym ich danych wejściowych — współautorzy będą mogli łatwiej odtwarzać, weryfikować i omawiać zachowanie funkcji, co z kolei przyspieszy debugowanie, usprawni procesy testowania i wesprze wspólne rozwiązywanie problemów w całej społeczności Wikifunctions.
WE2.3.1 Jeśli sfinalizujemy decyzję o utworzeniu nowej wiki i wspólnie ze społecznością ustalimy jej nazwę, będziemy mogli szerzej poinformować naszych interesariuszy o utworzeniu tej nowej wiki i przygotować się do logistycznych aspektów potencjalnej zmiany nazwy produktu.
WE2.3.2 Jeśli zdefiniujemy MVP dla prototypu Abstract wiki, który obejmuje minimalne doświadczenie niezbędne do przetestowania naszych możliwości back-endowych i NLG oraz pozwala nam na iteracyjne projektowanie, będziemy w stanie zaplanować i uruchomić prototyp na żywo w trzecim kwartale.
WE2.3.3 Jeśli zaczniemy rozmawiać ze społecznością i badać potencjalne projekty dotyczące doświadczeń użytkowników Abstract wiki, będziemy mogli kontynuować prace w trzecim kwartale.
WE2.4.1 Jeśli zbierzemy przykłady zastosowań Wikidata i WDQS od zespołów WMDE i WMF, będziemy mogli określić wymagania produktowe dotyczące ulepszeń infrastruktury.
WE2.4.2 Jeśli stworzymy zbiorcze zestawienie kluczowych wskaźników wydajności (KPI) wraz z istniejącymi celami poziomu usług (SLO) dla Wikidata i WDQS, będziemy w stanie sformułować i śledzić kryteria sukcesu dla ulepszeń infrastruktury technicznej wspierającej krytyczne zastosowania Wikidata.
WE2.4.3 Jeśli w ciągu kwartału uda nam się ocenić i porównać alternatywne rozwiązania dla Blazegraph przy użyciu kryteriów realistycznych z punktu widzenia produkcji, będziemy w stanie podjąć decyzję o migracji w oparciu o dane i opracować konkretny plan działania wraz z harmonogramem i wymaganiami dotyczącymi zasobów.
WE3.1.1 Jeśli przeprowadzimy test A/B ulepszonej wersji funkcji przeglądania w kartach, zauważymy 5-procentowy wzrost wielodniowego użytkowania wśród użytkowników kart.
WE3.1.3 Jeśli zapewnimy użytkownikom nowy sposób przeglądania odpowiednich treści graficznych na stronach artykułów i przetestujemy go na podgrupie niezalogowanych czytelników za pomocą testu A/B w zestawie wiki, zauważymy co najmniej 3% współczynnik klikalności wśród użytkowników, którym zostanie zaprezentowana ta funkcja.
WE3.1.4 Jeśli przedstawimy czytelnikom kilka koncepcji dotyczących poruszania się po sieci wiedzy w wiki, otrzymamy listę priorytetowych koncepcji do dalszego rozwoju.
WE3.1.5 Jeśli damy czytelnikom możliwość przeglądania tłumaczonych maszynowo treści Wikipedii, które nie są dostępne w ich języku, dowiemy się, czy wzrośnie aktywność czytelnicza, mierzona jako 3% wzrost interakcji ze stroną, przyciągając czytelników do lokalnej wersji Wikipedii i potencjalnie zwiększając lokalną aktywność edytorską. Będzie to realizowane w ramach kontrolowanych testów A/B przez okres nie dłuższy niż 6 miesięcy w 13 wersjach Wikipedii, które wyraziły wcześniej zgodę, z wykorzystaniem otwartych usług tłumaczenia maszynowego już dostępnych dla redaktorów Wikipedii.
WE3.1.6 Jeśli stworzymy prototyp wyszukiwania semantycznego i pytań i odpowiedzi w artykułach, dostarczony jako interfejs demonstracyjny, który kontrastuje obecne podejście z nowymi podejściami eksploracyjnymi, zespoły Reader będą mogły dokonać jakościowej oceny działania każdego podejścia w różnych ścieżkach użytkowników i wykryć luki lub możliwości dalszej iteracji.
WE3.1.7 Jeśli przeanalizujemy istniejące badania dotyczące sposobu, w jaki czytelnicy korzystają z narzędzi wyszukiwania i nawigacji w Wikipedii oraz sposobu, w jaki korzystają z zewnętrznych wyszukiwarek w celu znalezienia informacji w Wikipedii, będziemy w stanie przedstawić zespołom ds. czytelników co najmniej trzy praktyczne zalecenia i wnioski, które pomogą im określić zakres minimalnego produktu (MVP) w zakresie wyszukiwania i odkrywania informacji, aby zaspokoić oczekiwania i potrzeby czytelników.
WE3.1.8 Jeśli ocenimy dwa prototypy wyszukiwania semantycznego (wyszukiwanie w języku naturalnym, pytania i odpowiedzi) z udziałem zewnętrznych uczestników, dowiemy się, czy użytkownicy dostrzegają wartość ulepszonych narzędzi wyszukiwania, i będziemy mogli przedstawić zespołom Readers zalecenia dotyczące dalszych działań związanych z MVP wyszukiwania i odkrywania.
WE3.1.9 Jeśli w ramach badania jakościowego pokażemy 10–20 okazjonalnym czytelnikom Wikipedii koncepcje projektowe o wysokiej wierności dotyczące wyszukiwania treści za pomocą wyszukiwania semantycznego, zauważymy pozytywne nastawienie do tej funkcji i zyskamy pewność potrzebną do kontynuowania prac nad MVP wyszukiwania i odkrywania, które opiera się na krótkich fragmentach tekstów napisanych przez ludzi w odpowiedzi na zapytania wyszukiwania.
WE3.1.10 Jeśli w ramach niekontrolowanego badania użytkowników pokażemy 10 przypadkowym czytelnikom prototyp nowej funkcji przeglądania obrazów, odkryjemy co najmniej jedno ulepszenie UX, które będzie można wprowadzić w przyszłych wersjach tej funkcji.
WE3.1.11 Jeśli złagodzimy zasadę dopasowania słów kluczowych w wyszukiwarce, będziemy mogli lepiej obsługiwać zapytania w języku naturalnym i umożliwić działowi produktu ocenę tej funkcji oraz uwzględnienie jej podczas projektowania, ustalania priorytetów i realizacji zadań w obszarze wyszukiwania semantycznego.
WE3.1.14 If we launch an A/B test of a version of the mobile site which introduces navigation that opens all sections by default, we will see early indicators that signal towards an increase in session length (will report on full A/B test results in Q3) T409163
WE3.2.5 Jeśli wprowadzimy w systemie Android funkcję „Podsumowanie roku”, która podkreśla wpływ użytkowników i zawiera zintegrowane wiadomości od darczyńców, wywołamy nowe zachowania związane z darowiznami — i odnotujemy 5-procentowy wzrost w menu aplikacji w porównaniu z rokiem 2024.
WE3.2.6 Jeśli sprawimy, że slajdy dla darczyńców w podsumowaniu roku dla iOS będą bardziej zintegrowane i spersonalizowane, odnotujemy 5-procentowy wzrost darowizn w porównaniu z rokiem 2024.
WE3.3.3 Jeśli wprowadzimy co najmniej jeden awatar do odblokowania w aplikacji na Androida dla posiadaczy kont — zdobyty dzięki znaczącym działaniom czytelników, takim jak zapisanie określonej liczby artykułów — zwiększymy powtarzalne zaangażowanie związane z powiązanymi działaniami przez zalogowanych użytkowników o 10% w ciągu kilku dni.
WE3.3.4 Jeśli damy zalogowanym czytelnikom możliwość zapisywania artykułów na prywatnej liście do przeczytania, spodziewamy się wzrostu zaangażowania na stronie, mierzonego 5-procentowym wzrostem wewnętrznego ruchu przekierowań dla czytelników korzystających z tej funkcji oraz statystycznie istotnym wzrostem dla wszystkich użytkowników.
WE3.3.6 Jeśli udostępnimy dane dotyczące wnioskowania o tematyce artykułów za pośrednictwem usługi spełniającej uzgodnione wymagania dotyczące skalowalności i dostępności, a także wszelkie niezbędne uzupełnienia danych, stworzymy podstawy techniczne niezbędne do obsługi przyszłych spersonalizowanych doświadczeń czytelników, które będą opierać się na tych danych.
WE3.3.7 Jeśli wykorzystamy możliwości przetwarzania platformy danych do agregowania dostosowanych wskaźników edytorskich i danych dotyczących wpływu oraz udostępnimy zagregowane dane za pośrednictwem odpowiednich usług z określonymi poziomami SLO, będziemy mogli ulepszyć przyszłe wersje podsumowania roku WE3.3.1 i karty aktywności WE3.3.2.
WE3.3.9 Jeśli opublikujemy podsumowanie roku w systemie Android i przeprowadzimy test A/B, oferując zaangażowanym użytkownikom nagrodę za zapisanie niestandardowej listy artykułów do późniejszego zapoznania się, odnotujemy 1% wzrost ogólnego wskaźnika retencji aplikacji wśród czytelników, którym zaoferowano nagrodę, w porównaniu z tymi, którzy jej nie otrzymali.
WE3.3.10 Jeśli przeprowadzimy test A/B wymagający posiadania konta w celu wyświetlenia spersonalizowanych statystyk czytania w podsumowaniu roku, zauważymy 1% wzrost ogólnego wskaźnika retencji użytkowników, którzy musieli posiadać konto, w porównaniu z tymi, którzy nie musieli go posiadać.
WE3.3.11 Jeśli przeprowadzimy test A/B ulepszonej wersji zakładki „Aktywność” w systemie iOS, która podkreśla czytanie, edytowanie i inne zachowania związane z uczestnictwem, zauważymy 5% wzrost liczby wielodniowych wizyt zalogowanych czytelników w tej zakładce w porównaniu z wersją prototypową.
WE3.4.1 Jeśli będziemy dążyć do wdrożenia hybrydowego punktu obecności (PoP/CDN), pozwoli nam to uruchomić zarówno pełne punkty PoP, jak i mini punkty PoP (fizyczne i w chmurze) zgodnie z potrzebami, tworząc podstawę do wdrożenia prototypowego mini punktu PoP w przyszłości.
WE3.5.1 Jeśli działy Produkt i Technologia oraz Pozyskiwanie funduszy wspólnie ocenią i udokumentują techniczne podejścia do identyfikacji darczyńców na naszych platformach, będziemy w stanie zaproponować krótko- i długoterminowe rozwiązanie, które zapewni równowagę między prywatnością, wykonalnością i skutecznością. To wspólne zrozumienie pomoże ujednolicić proces podejmowania decyzji, umożliwi stałą identyfikację darczyńców na różnych platformach, a także pozwoli na bardziej ukierunkowane eksperymenty w zakresie przyszłych funkcji związanych z pozyskiwaniem funduszy.
WE3.6.3 Jeśli zaangażujemy społeczności w rozmowy na temat zmieniających się potrzeb czytelników oraz ewoluującego charakteru wiedzy w Internecie, będziemy mogli wspólnie skupić się na tym, jak służyć czytelnikom i współpracować nad tym, czy i jak przetestować nasze różne pomysły (w tym dotyczące multimediów, wyszukiwania i odkrywania oraz uczenia maszynowego).
WE3.6.4 Jeśli zbadamy różne motywacje, zachowania i potrzeby związane z tym, kiedy, dlaczego i w jaki sposób czytelnicy korzystają z Wikipedii i innych platform wiedzy, będziemy w stanie zaproponować priorytetowe obszary i konkretne inicjatywy w ramach strategii konsumenckiej.
WE3.6.5 Jeśli działy Produktu i Technologii oraz Pozyskiwania Funduszy będą współpracować nad wspólną strategią dywersyfikacji możliwości przekazywania darowizn na platformie oraz zarządzania i doceniania czytelników, którzy przekazują darowizny, ustalimy jasne, spójne cele i wskaźniki powiązane z naszymi strategiami konsumenckimi i pozyskiwania funduszy.
WE3.6.6 Jeśli opracujemy ujednoliconą strategię pomiarową, umożliwimy ocenę wieloletniej strategii konsumentów i określimy plan działania, który będzie wytyczał kierunki rozwoju wskaźników i możliwości raportowania.
WE4.1.1 Jeśli stworzymy prototyp minimalnie funkcjonalnego przepływu niebędącego sytuacją awaryjną i utrzymamy otwartą pętlę informacji zwrotnej podczas opracowywania go wraz z użytkownikami posiadającymi rozszerzone uprawnienia, wówczas grupy te będą wspierać rozszerzone wdrożenie tego przepływu.
WE4.1.3 Jeśli do końca października zaktualizujemy 7 wersji Wikipedii (francuską, niemiecką, hiszpańską, węgierską, włoską, polską i portugalską), zakończymy fazę 1 wdrażania nowego stopki prawnej w odpowiedzi na wymagania DSA.
WE4.1.4 Jeśli wdrożymy MVP systemu zgłaszania incydentów w co najmniej 15 wiki, koncentrując się na większych, złożonych społecznościach, będziemy mogli obserwować, jak jest on wykorzystywany zgodnie z zamierzeniami społeczności, i zademonstrujemy działający model zgłaszania incydentów niebędących sytuacjami kryzysowymi.
WE4.1.5 Jeśli opracujemy schemat postępowania w przypadku zgłaszania nadużyć na stronach wiki, które nie posiadają ustalonych procedur postępowania w takich sytuacjach, zachęci to do wdrożenia systemu zgłaszania incydentów na takich stronach i zapewni użytkownikom tych stron jasną i realną ścieżkę wsparcia.
WE4.2.3 Jeśli przeanalizujemy dane z testu tworzenia kont hCaptcha, zrozumiemy proces tworzenia kont, skuteczność łamigłówek i wyników hCaptcha oraz uzyskamy dane niezbędne do dalszego wdrażania hCaptcha w procesie tworzenia kont.
WE4.2.5 Jeśli przeprowadzimy badania, skonsultujemy się ze społecznościami i zbadamy rozwiązania techniczne, będziemy w stanie zdefiniować zestaw ustrukturyzowanych powodów blokowania, które będą mogły być stosowane we wszystkich wiki WMF.
WE4.2.6 Jeśli rozwinie się możliwość wdrażania klastrów opartych na OpenSearch na platformie danych, zespoły inżynierów ds. funkcji produktów będą mogły opracowywać systemy integrujące tę funkcję, charakteryzujące się dużą autonomią, odpornością i izolacją od innych systemów opartych na wyszukiwaniu. Pierwszym i głównym użytkownikiem tego systemu będzie usługa IPoid.
WE4.2.7 Jeśli wdrożymy integrację hCaptcha Enterprise w kilku produkcyjnych wersjach Wikipedii w ramach pilotażowego programu testowego, będziemy mogli zebrać dane dotyczące skuteczności i wartości hCaptcha Enterprise w zakresie przeciwdziałania nadużyciom, wykrywania botów, użyteczności i dostępności.
WE4.2.8 Jeśli sprawimy, że proxy hCaptcha będzie gotowe do użycia w produkcji poprzez poprawę jego dostępności i obserwowalności, w pierwszym kwartale zapewnimy bardziej stabilną i niezawodną usługę dla Wikipedii w produkcji.
WE4.2.9 Jeśli zintegrujemy SDK hCaptcha z natywnymi aplikacjami mobilnymi, ocenimy wrażenia użytkowników aplikacji natywnych i ocenimy włączenie wyzwań hCaptcha jako część API tworzenia kont, będziemy mieli wystarczającą wiedzę, aby podjąć decyzję o dalszym wdrożeniu hCaptcha dla API tworzenia kont.
WE4.2.11 Jeśli włączymy hCaptcha do wykrywania botów w scenariuszach edycji o wyższym ryzyku, zobaczymy, że hCaptcha może ograniczyć automatyczne nadużycia.
WE4.2.16 Jeśli skonsultujemy się z odpowiednimi zespołami WMF, będziemy w stanie opracować uzgodniony plan zarządzania bardziej szczegółowym dostępem użytkowników do danych niepublicznych oraz wesprzeć wdrożenie niepublicznych zasad w obrębie oprogramowania ochronnego.
WE4.2.17 Jeśli przeanalizujemy przykłady z życia wzięte i przeprowadzimy wywiady z checkuserami, aby zidentyfikować co najmniej 2 sygnały potencjalnego nadużycia na podstawie prototypu historii redaktora, zespół ds. bezpieczeństwa i integralności produktu będzie mógł później włączyć te sygnały do funkcji sugerowanych dochodzeń, mając większą pewność, że sygnały te będą miały wartość.
WE4.3.2 Jeśli zastosujemy odciski palców JA4H, które podsumowują zachowanie klienta HTTP, będziemy w stanie lepiej identyfikować i kategoryzować ruch botów.
WE4.4.1 Jeśli uda nam się wprowadzić ulepszenia w oparciu o opinie uczestników programu pilotażowego i wdrożyć tymczasowe konta we wszystkich projektach, będziemy w stanie chronić dane osobowe (adresy IP) niezarejestrowanych użytkowników we wszystkich naszych projektach, tak aby były one dostępne dla mniej niż 0,1% wszystkich (zarejestrowanych) użytkowników.
WE4.4.2 Jeśli będziemy komunikować się z odpowiednimi interesariuszami ruchu (w tym społecznościami wiki i globalnymi funkcjonariuszami) w sposób jasny i terminowy, będziemy w stanie wdrożyć zmiany we wszystkich pozostałych wiki, zmniejszyć nakład pracy wykryty w ostatniej chwili i uniknąć cofania wdrożenia.
WE4.4.5 Jeśli zmniejszymy trudności, z jakimi borykają się patrole w identyfikowaniu osób wykorzystujących tymczasowe konta do niszczenia treści, będziemy w stanie zapobiec wzrostowi aktów wandalizmu poprzez zmniejszenie wskaźnika przywracania zmian we wszystkich wiki z tymczasowymi kontami.
WE4.4.6 Jeśli wycofamy rozszerzenie LiquidThreads, odblokujemy konta tymczasowe wdrożone we wszystkich projektach, które obecnie korzystają z tego rozszerzenia.
WE4.6.1 Jeśli zautomatyzujemy proces synchronizacji kont w Zendesk w celu resetowania haseł, zmniejszy to obciążenie działu T&S i pozwoli mu obsłużyć więcej przychodzących wniosków o resetowanie 2FA.
WE4.6.3 Jeśli pozwolimy wszystkim użytkownikom z potwierdzonym adresem e-mail na włączenie 2FA dla swoich kont, ale nie będziemy aktywnie informować użytkowników o tej zmianie, obciążenie naszego działu pomocy technicznej pozostanie na zrównoważonym poziomie.
WE4.6.4 Jeśli będziemy kontynuować prace nad poprawą komfortu użytkowania naszego systemu 2FA i dodamy obsługę kluczy dostępu, więcej użytkowników zarejestruje wiele czynników uwierzytelniających i będzie lepiej chronionych przed utratą dostępu do konta.
WE4.6.5 Jeśli zaprojektujemy i stworzymy ogólne ramy określające wymagania, które muszą spełniać członkowie lokalnej lub globalnej grupy, wykorzystamy te ramy do egzekwowania od członków grupy temporary-account-ip-viewer spełnienia istniejących wymagań zasad.
WE4.6.6 Jeśli zbadamy, w jaki sposób użytkownicy z rozszerzonymi uprawnieniami (UWER) korzystają ze skryptów użytkownika, będziemy w stanie zaproponować plan, który społeczność UWER mogłaby poprzeć, aby wprowadzić jedną lub więcej istotnych zmian technicznych, które w znaczący sposób zabezpieczyłyby system skryptów użytkownika.
WE4.6.7 Jeśli ocenimy wrażenia użytkowników i zmiany techniczne wymagane w przypadku natywnych aplikacji mobilnych w celu dostosowania procesu logowania mobilnego do platformy internetowej, poprzez zbadanie alternatywnych mechanizmów, takich jak OAuth, możemy określić wykonalność integracji, mając na celu zapewnienie użytkownikom bezpieczniejszych i spójniejszych wrażeń.
WE4.6.8 Jeśli będziemy monitorować wpływ formularzy Zendesk i MediaWiki, które stworzyliśmy w pierwszym kwartale, będziemy mogli zaproponować działania techniczne na kolejne kwartały, które pozwolą lepiej zautomatyzować pozostałą część procesu odzyskiwania kont.
WE5.1.2b Jeśli zintegrujemy wiele metod identyfikacji i uwierzytelniania programistów w bramie API, będziemy mogli przypisać odpowiedni limit szybkości do każdego żądania, poprzez prawidłową identyfikację żądań pochodzących od różnych grup użytkowników.
WE5.1.3b Jeśli przeprowadzimy próbę ograniczenia przepustowości na co najmniej 3 trasach bramy REST, pozwoli nam to zweryfikować wykonalność ograniczenia przepustowości w odniesieniu do zużycia zasobów i zdefiniować wstępny zestaw limitów, które można by wprowadzić przy minimalnym wpływie na użytkowników.
WE5.1.4b Jeśli zweryfikujemy proponowane mechanizmy segmentacji użytkowników API przy użyciu szerszych zestawów danych i ręcznej weryfikacji zidentyfikowanych grup, będziemy w stanie sfinalizować kohorty użytkowników, udoskonalić metodologie stosowane do obliczeń i lepiej zrozumieć ich skuteczność.
WE5.1.5 Jeśli będziemy współpracować z zespołem platformy MediaWiki w zakresie identyfikacji ruchu i ograniczania przepustowości, będziemy mogli wdrożyć ograniczenia przepustowości do testów próbnych w środowisku produkcyjnym, wspierając zespół platformy w tworzeniu i wdrażaniu tej funkcji.
WE5.2.1b Jeśli nawiążemy współpracę z potencjalnymi użytkownikami nowego REST API Explorer, pomoże nam to zidentyfikować kluczowe informacje dotyczące użyteczności, które wskazują, czy nowy projekt jest łatwy w użyciu i zgodny z modelem mentalnym programistów.
WE5.2.2b Jeśli przekierujemy Action API przez centralną bramę API, będziemy mogli zacząć konsekwentnie mierzyć ruch i wzorce użytkowania, aby uzyskać informacje, które pomogą nam w podejmowaniu przyszłych decyzji i działań.
WE5.2.4 Jeśli wdrożymy standardowe wzorce dokumentacji dla 2 interfejsów API, będziemy mogli udoskonalić wytyczne dotyczące treści, zrozumieć potrzeby właścicieli interfejsów API w zakresie przyjęcia wytycznych oraz oszacować nakład pracy wymagany do wdrożenia wytycznych w pozostałych dokumentach dotyczących interfejsów API Wikimedia.
WE5.2.5 Jeśli spróbujemy zdefiniować i zastosować reguły sprawdzania poprawności specyfikacji OpenAPI do interfejsów API REST MediaWiki, pokażemy, jak programowo egzekwować wytyczne dotyczące stylu API, żeby poprawić jakość i spójność interfejsów API publikowanych w Wikimedia i naszych społecznościach.
WE5.2.6 If we introduce access controls to the sitemap API to only allow trusted bots, we can improve strategic alignment and reduce the risk of abusive scraping. phab:T406921
WE5.3.1 Jeśli rozszerzymy i usprawniamy wytyczne dotyczące atrybucji UX, jednocześnie aktualizując wszelkie istniejące wytyczne, stworzymy podstawowy zestaw ulepszonych wytycznych gotowych do wewnętrznego testowania i iteracyjnego udoskonalania, aby przygotować je do szerszego publicznego wykorzystania.
WE5.3.1b Jeśli opublikujemy i będziemy udoskonalać projekt wytycznych dotyczących doświadczeń użytkownika oraz wersje demonstracyjne, stworzymy podstawowe ramy gotowe do wewnętrznych testów i iteracyjnego udoskonalania, aby przygotować je do szerszego publicznego użytku.
WE5.3.2 Jeśli stworzymy prezentację pokazującą korzyści płynące z przypisywania Wikipedii do treści ponownie wykorzystywanych przez osoby trzecie i ich użytkowników końcowych, możemy wesprzeć WME4.1 i WME4.2, umożliwiając co najmniej jednemu dodatkowemu partnerowi ponownie wykorzystującemu treści wyrażenie zgody na pojawienie się w studium przypadku lub demonstracji dotyczącej przypisywania autorstwa do końca pierwszego kwartału.
WE5.4.2b Jeśli stworzymy skalowalny sposób identyfikacji znanych klientów, będziemy mogli dopuścić wyjątki od ogólnych limitów szybkości dla botów o zweryfikowanym pochodzeniu i przejść do systematycznego egzekwowania naszych zasad.
WE5.4.5 Jeśli zaczniemy egzekwować limity szybkości dostosowane do różnych klas poszczególnych klientów, zmniejszymy obciążenie naszej infrastruktury związane z indeksowaniem.
WE5.4.6 Jeśli do końca drugiego kwartału sklasyfikujemy N najpopularniejszych robotów jako znane boty, będziemy mogli ograniczyć ilość zasobów, które wykorzystują.
WE5.4.7 Jeśli ustalimy standardowe zestawy dozwolonych rozmiarów miniatur w naszej infrastrukturze multimedialnej i wstępnie wygenerujemy te technicznie najdroższe, jednocześnie ograniczając szybkość generowania różnych rozmiarów obrazów, zmniejszymy obciążenie infrastruktury obsługującej multimedia.
WE6.1.2 Dodanie wikifarm do środowiska testowego przed scalaniem umożliwi zespołom programistycznym pracującym nad produkcją, które potrzebują wielu wiki do testowania swoich poprawek w izolacji, uzyskanie większej pewności przed produkcją i zmniejszenie liczby wykrytych błędów.
WE6.2.1 Jeśli zweryfikujemy i opublikujemy naszą listę kontrolną gotowości produkcyjnej, która jasno określa warunki wstępne, jakie musi spełniać usługa, aby można ją było uznać za gotową do produkcji, wraz z zadaniami, które można wykonać samodzielnie, zharmonizujemy oczekiwania między zespołami SRE a zespołami programistycznymi, poprawiając naszą ogólną wydajność operacyjną i skalowalność.
WE6.2.2 Jeśli ogłosimy stworzenie biblioteki Golang i nodejs, która ułatwi programistom wiele żmudnych zadań, zareagują oni, przekazując swoje opinie i wyrażając zainteresowanie.
WE6.2.4 Jeśli zastosujemy i aktywnie wesprzemy przegląd projektu dotyczący trwałości danych, możemy zidentyfikować utarte ścieżki prowadzące do etapu produkcyjnego.
WE6.3.2 Jeśli opracujemy nowe wskaźniki, ulepszymy infrastrukturę pamięci podręcznej Parsoid i wdrożymy ją w dwóch dziesięciu czołowych Wikipediach, opracujemy kryteria wydajności dla struktury zaufania, które pomogą zweryfikować naszą gotowość do wdrożenia w innych dużych wiki i wykazać naszą zdolność do obsługi dużego ruchu na dużą skalę.
WE6.3.3 Jeśli wdrożymy istotne ulepszenia obsługi wariantów językowych i pomyślnie wdrożymy Parsoid w co najmniej 3 wiki z wariantami językowymi w drugim kwartale, zidentyfikujemy i rozwiążemy kluczowe wyzwania techniczne niezbędne do pewnego wdrożenia we wszystkich pozostałych wiki z wariantami językowymi.
WE6.4.6 Jeśli SRE zapewni wsparcie zespołom inżynierów MediaWiki – poprzez zarządzanie wydajnością i ruchem, przygotowanie i przegląd zmian konfiguracyjnych oraz współpracę w zakresie badania i rozwiązywania problemów – wspólnie zakończymy aktualizację PHP 8.3 w drugim kwartale i opracujemy zestaw zaleceń mających na celu zminimalizowanie zależności od SRE w przyszłych aktualizacjach. T360995
WE6.4.7 Jeśli przeniesiemy co najmniej 90% wszystkich użytkowników z globalnym dostępem root do korzystania z klucza SSH wspieranego sprzętowo w celu uzyskania dostępu do serwerów produkcyjnych Wikimedia, zmniejszymy ryzyko, że zainfekowany laptop spowoduje poważne naruszenie bezpieczeństwa.
WE6.4.8 Jeśli zespół inżynierów MediaWiki będzie aktywnie monitorował i naprawiał problemy w MediaWiki związane z aktualizacją PHP, umożliwi to zespołowi SRE zakończenie aktualizacji produkcyjnej PHP 8.3 do listopada 2025. T360995
Hipotezy dotyczące Usług sygnałów i danych (SDS)

[ Kluczowe rezultaty - SDS ]

Dyskusja

Skrócona nazwa hipotezy Tekst dla Q2 Szczegóły i dyskusja
SDS1.2.1 Jeśli przeniesiemy proces tworzenia zrzutów XML z obecnej infrastruktury „Dumps 1” do potoku danych wykorzystującego potoki treści MediaWiki, będziemy mogli zagwarantować realizację celów SLO i wyłączyć eksport XML oparty na „Dumps 1”.
SDS1.2.2 Jeśli przeprowadzimy przegląd i przeanalizujemy SLO dla historii treści MediaWiki oraz platformy wydarzeń / bramy wydarzeń, będziemy mogli zweryfikować klientów, wskaźniki i zależnych interesariuszy oraz zidentyfikować ulepszenia, które mogą być potrzebne dla SLO, co pomoże nam wyjaśnić wszelkie luki w naszych tygodniowych gwarancjach dostaw.
SDS1.3.1 Jeśli wprowadzimy sygnały po stronie klienta i zweryfikujemy je w porównaniu z logami żądań sieciowych po stronie serwera, znajdziemy dodatkowe wzorce botów, które można scharakteryzować.
SDS1.3.2 Jeśli przyjmiemy obecny rozkład botów i ludzi jako punkt odniesienia i stworzymy automatyczne alerty dotyczące zmian w tym rozkładzie, skrócimy czas wykrywania kolejnych nieprzewidzianych wzorców ruchu automatycznego z tygodni do minut.
SDS1.3.3 Jeśli zautomatyzujemy mechanizm uzupełniania danych dla żądań internetowych i zastosujemy go do logów z maja, skrócimy czas naprawy przyszłych incydentów z miesięcy do dni i rozwiążemy problem „wzrostu liczby odsłon w maju”.
SDS1.3.4 Jeśli stworzymy regularny, zoperacjonalizowany proces audytu wewnętrznego wyników klasyfikacji botów, zbudujemy zaufanie do naszych rozwiązań i będziemy w stanie przewidywać zmiany we wzorcach ruchu, które nie są wykrywane automatycznie.
SDS1.3.5 Jeśli przeanalizujemy podstawowy sygnał po stronie klienta i włączymy go do naszych heurystyk, wykryjemy dodatkowe wzorce botów w platformie danych.
SDS1.3.6 Jeśli zaimportujemy, przeanalizujemy i włączymy do naszej heurystyki reputację IP Spur.us, wykryjemy dodatkowe wzorce botów w platformie danych.
SDS1.3.7 Jeśli zaimportujemy, przeanalizujemy i włączymy do naszej heurystyki jeden sygnał brzegowy, wykryjemy dodatkowe wzorce botów w platformie danych.
SDS1.4.1 Jeśli potwierdzimy istniejącą analizę trendów w ekosystemie Wikimedia – liczbę odsłon, wskaźniki dotyczące autorów i czytelników, ruch itp. – będziemy mogli z pewnością poprzeć najważniejsze punkty dyskusji dotyczące naszych najważniejszych spostrzeżeń dotyczących ruchu.
SDS1.4.2 Jeśli potwierdzimy istniejącą analizę trendów w ekosystemie Wikimedia – liczbę odsłon, wskaźniki dotyczące autorów i czytelników, ruch itp. – będziemy mogli z pewnością poprzeć najważniejsze punkty dyskusji dotyczące naszych najważniejszych spostrzeżeń dotyczących ruchu.
SDS2.1.1 Jeśli będziemy ściśle współpracować z zespołami przeprowadzającymi eksperymenty, dowiemy się, jak sprawić, by system był w przyszłości bardziej samoobsługowy oraz jakie wyzwania koncepcyjne lub techniczne mogą nas napotkać.
SDS2.1.2 Jeśli uda nam się wdrożyć lepsze debugowanie rejestrowania zdarzeń, zespoły produktowe będą miały pewność, że ich eksperymenty gromadzą dane o zdarzeniach zgodnie z oczekiwaniami, co zwiększy zaufanie właścicieli eksperymentów.
SDS2.1.3 Jeśli poprawimy rejestrowanie i obserwowalność komponentu systemu testów A/B (xLab) platformy eksperymentalnej oraz powiązanych z nim części MediaWiki, będziemy w stanie ustalić podstawowe parametry wydajności systemu i reagować na awarie związane z eksperymentami.
SDS2.1.4 Jeśli raz w miesiącu będziemy dzielić się historiami i wynikami eksperymentów w całej organizacji (podczas spotkań zespołu operacyjnego ds. produktowych, spotkań zespołu projektowego i prezentacji między zespołami), stworzymy naturalne środowisko dla platformy eksperymentalnej.
SDS2.1.5 Jeśli poinformujemy użytkowników, że ich instrument, jeśli został utworzony w xLab, zawiera zestaw atrybutów, które zmieniają kategorię ryzyka, zniechęcimy użytkowników narzędzi do nadmiernego gromadzenia danych i zwiększymy przejrzystość w zakresie tego, jakie kombinacje atrybutów wymagają przeglądu pod kątem prywatności.
SDS2.1.6 Jeśli zespół ds. rozwoju zajmie się wdrożeniem dwóch przypadków użycia (jeden z testem A/B, żeby lepiej zrozumieć możliwości grupowania, a drugi z długoterminowym wdrożeniem, żeby dowiedzieć się więcej o obsłudze wskaźników podobnych do KPI) w Experiment Lab, to będziemy mogli sprawdzić, czy spełnione są wymagania, żeby zastąpić nasze niestandardowe ustawienia eksperymentów w GrowthExperiments.
Hipotezy dotyczące przyszłych odbiorców (FA)

[ Kluczowe rezultaty - FA ]

Dyskusja

Skrócona nazwa hipotezy Tekst dla Q2 Szczegóły i dyskusja
FA1.1.4 [Kontynuacja z poprzedniego roku finansowego] Jeśli stworzymy nową wersję Wikipedii na platformie Roblox, dowiemy się, czy może to być skuteczny sposób na zaprezentowanie naszej marki młodszym odbiorcom (pokolenie Alpha).
FA1.1.2 Jeśli stworzymy centralną platformę dla nowych doświadczeń związanych z Wikipedią na itch.io, będziemy mogli zdobyć ponad 50 zainteresowanych osób spoza Wikipedii, które będą nam przekazywać swoje opinie, co pomoże nam dowiedzieć się, co sprawdza się w grach, a co nie.
FA2.2.1 Jeśli zainwestujemy w zarządzanie społecznością na platformach krótkich filmów, to do końca drugiego kwartału (grudzień 2025 r.) odnotujemy 30-procentowy wzrost w ujęciu kwartalnym udziału nowych widzów w serwisie TikTok, a na wszystkich platformach krótkich materiałów wideo uzyskamy łącznie 50 000 interakcji (polubień i komentarzy) dotyczących komentarzy marki pozostawionych pod treściami zewnętrznymi, co pomoże nam zwiększyć widoczność i zaangażowanie odbiorców, do których obecnie nie docieramy.
FA2.2.2 Jeśli opracujemy i uzyskamy zatwierdzenie wewnętrznej strategii programu partnerstwa z twórcami Wikipedii oraz materiałów do udostępniania na zewnątrz (w tym zarysu naszej wartości dla twórców, kryteriów partnerstwa, procesu zawierania umów oraz sposobu wyświetlania treści twórców w kanałach własnych i twórców), będziemy w stanie ustanowić solidną strategię dotyczącą twórców, która pomoże nam dotrzeć z naszymi treściami wiedzy do nowych odbiorców w mediach społecznościowych.
Hipotezy w dziedzinie wsparcia produktu i inżynierii (PES)

[ Kluczowe rezultaty - PES ]

Dyskusja

Skrócona nazwa hipotezy Tekst dla Q2 Szczegóły i dyskusja
PES1.1.5 Jeśli wdrożymy cele poziomu usług (SLO) dla historii treści MediaWiki i Wikifunctions do Sloth/Pyrra, wprowadzimy do produkcji 2 dodatkowe SLO.
PES1.1.6 Jeśli przetestujemy Sloth przy użyciu danych retroaktywnych z istniejących SLO, zrozumiemy, czy Pyrra lub Sloth (lub coś innego) jest odpowiednim narzędziem dla naszego podejścia opartego na stałych oknach budżetu błędów. Dowiemy się, jak wspierać właścicieli usług poprzez samoobsługowe podejście do wskaźników SLO i wykorzystywać je w procesie podejmowania decyzji.
PES1.2.4 Jeśli w pierwszym kwartale przeprowadzimy pilotażowy proces kwartalnego przeglądu życzeń i sygnałów społeczności z udziałem trzech zespołów, zaangażujemy menedżerów produktu do włączenia sygnałów społeczności do ich kwartalnych i rocznych procesów planowania.
PES1.2.5 Jeśli dodamy możliwość filtrowania i sortowania życzeń w rozszerzeniu Wishlist do ulepszeń umożliwiających kategoryzację za pomocą tagów i głosowania, te 3 ulepszenia zwiększą liczbę unikalnych uczestników Wishlist o co najmniej 30%.
PES1.3.3 Jeśli stworzymy co najmniej 5 ciekawych interwencji na platformie, które będą się pojawiać na podstawie interakcji użytkowników, określimy, jakie będą czynniki wyzwalające dla strony portalu i gadżetu Birthday Mode. Testy użyteczności pokażą nam, które interwencje tworzą pozytywne skojarzenia z naszą marką. Ta hipoteza ma być sprawdzona do końca października, kiedy to odbędzie się WikiCon North America.
PES1.3.4 Jeśli stworzymy wciągającą stronę internetową poświęconą historii, teraźniejszości i przyszłości Wikipedii, we współpracy z członkami działu komunikacji, mającą na celu zaangażowanie odbiorców w wieku 18-34 lat w obszarach docelowych kampanii, spowoduje to większe powiązanie z Wikipedią poprzez udostępnianie w mediach społecznościowych i inne działania online. Przyczyni się to do osiągnięcia celu komunikacyjnego, jakim jest zwiększenie rozpoznawalności marki o 10 punktów procentowych, a jednocześnie pozwoli nam stwierdzić, czy dynamiczne podejście do treści poprawia sympatię do marki.

Q3

The third quarter (Q3) of the WMF annual plan covers January-March 2026.

Wiki Experiences (WE) Hypotheses

[ WE Key Results ]

Dyskusja

Hypothesis shortname Q3 text Details & Discussion
WE1.1.3 If the Editing Team makes an initial set of edit suggestions available within VE via a URL parameter and invites ≥10 newcomers and patrollers to offer feedback about it, we will learn what improvements would need to be made before running a controlled experiment to evaluate the intervention's impact.
WE1.1.4 If we deploy Reference Check at en.wiki through a controlled experiment, we will see a ≥4% increase in the constructive edits new(er) volunteers publish and learn whether there is sufficient support among patrollers and moderators to enable the feature more widely.
WE1.1.12 If we enable ≥3 volunteers to evaluate ≥30 sample edits each, for each of the 10 new languages we are seeking to scale Tone Check to, we will learn how often volunteers agree with model predictions and be able to decide which new wikis to approach about deploying Tone Check to.
WE1.1.14 If we prompt new(er) volunteers to consider the tone they are writing in when an AI model detects them using non-neutral language, then we will see a ≥4% decrease in the percentage of new content edits new(er) volunteers publish that are reverted on the grounds of WP:NPOV (and related policies).
WE1.1.17 If we develop a task generation engine for the Revise Tone structured task, integrate our recent learnings about which content to include or filter out, and provide pipelines that automatically refresh the task list, we'll enable a qualitative evaluation of the tasks generated and an A/B experiment that tests whether this type of task helps newcomer editors to make more constructive edits.
WE1.1.18 If we analyze a pre-predetermined set of leading indicators ~2 weeks after the start of the Revise Tone Structured Task A/B test, we will be able to identify what – if any – facets of the end-to-end experience need to be adjusted or investigated before we can be confident evaluating the impact of the feature.
WE1.1.19 If we enable people on mobile web to edit any article section, regardless of which edit icon they first tap, then the newcomer mobile edit abandonment rate will decrease by #% because they will be able to more more easily locate the content they tapped edit seeking to change.
WE1.1.20 If the Growth team scales the “Add a Link” task to at least 10 additional Wikipedias, then we can complete leading indicator analysis to confirm that the task is performing as expected and identify any wikis that may require further review.
WE1.1.21 If we deploy the new Add-a-Link model version to both newly onboarded wikis and wikis currently using Add-a-Link, then the Growth team will be able to roll out Add-a-Link as a structured task to wikis where it did not previously exist, and wikis that already had the task will receive an updated model with fresher training data and improved offline performance.
WE1.1.22 If we improve the initial “Welcome to Wikipedia” verification email, the percentage of new accounts that verify their email address will increase. This would allow Growth to re-engage these accounts through follow up emails and ensure they receive talk page notifications.
WE1.1.23 If we prompt readily available GenAI models to generate and rank a set of edit suggestions for a diversified sample of 150 English Wikipedia articles, then we will learn what types of editing tasks these generic models can produce at scale and gain a rough, anecdotal understanding of the usefulness of these suggestions. This early signal will help us assess whether some task types could plausibly be generated at scale with generic models (with or without fine-tuning), or whether they would require more specialized approaches - ultimately helping us validate whether pursuing this "single model many suggestions" direction is worthwhile.
WE1.1.24 If we prompt new(er) volunteers pasting text from an external site to confirm whether they wrote the content they are attempting to add, then we will see a ≥4% increase in the percentage of new content edits new(er) volunteers publish that are reverted on the grounds of WP:COPYVIO (and related policies).
WE1.2.6 If we develop a goal-setting feature via Event Registration, then more collaborations will be created via Event Registration.
WE1.3.3 If we launch an experiment to surface a moderator dashboard to newer editors, 10% of contributors who visit it do so two weeks in a row.
WE1.3.4 If we deploy the Revert Risk filter to 150+ additional Wikipedias that currently lack damaging/goodfaith models, then we will see an increase in moderator patrol counts for contributors who use the personal moderator dashboard compared to those who don't get access to the dashboard.
WE1.5.1 If we implement a dashboard to explore 7 contributor metrics and standardize the calculation of at least one metric using dbt then we can enable contributor product teams to self-serve metric insights and develop a standard for storing metric calculation logic.
WE1.5.3 If Data Engineering productionizes a data product of edit types by the end of Q3, then the 6 moderator actions that are "Complicated" to measure will become "Simple", allowing Movement Insights to define a monthly active moderator metric as a next step.
WE1.5.4 If we produce a prototype dashboard with active moderator metrics that are currently available, then we will be able to produce a full dashboard by end of Q4.
WE1.6.1 If we introduce custom watchlist labels, we expect the labels to be used by 5% of users with more than 100 pages on their watchlist in the first month.
WE2.2.13 If we socialize the availability of the conjugation table function with the Wiktionary community, we will gather early signals about editor understanding and usability that can guide future improvements.
WE2.2.20 If we roll Wikifunctions out to wikis that have Parsoid enabled, we will be able to continue testing whether the system remains performant and usable in increasingly broad rollouts.
WE2.2.21 If we allow a limited set of reentrant functions in the evaluator, it will be possible to increase reliance on evaluated implementations, thereby leveraging the most performant part of the backend.
WE2.2.22 If we write an explicit interpreter for the composition language, the orchestrator will be more performant, and further performance-enhancing features will be easier to implement.
WE2.2.23 If we enable contributors to reuse whole composition blocks across functions, we will reduce repetitive work and significantly speed up the creation of new implementations, especially for similar linguistic functions.
WE2.2.24 If we define a clear documentation structure and entry points, function creators will more easily find relevant guidance and experience less friction when creating functions.
WE2.2.25 If we systematically identify the biggest friction points in the function creation experience, we can surface a small set of high-impact improvements that make creating and iterating on functions more efficient.
WE2.2.26 If we introduce a lightweight, local reference solution (via pop-ups) for Abstract Wikipedia, we can establish an initial citation mechanism to inform whether more complex solutions are necessary.
WE2.3.4 If we build and release an initial version of the Abstract Wikipedia platform, we can demonstrate the technical feasibility of the ecosystem working across multiple languages.
WE2.3.5 If we engage with a small number of under-resourced Wikipedia language communities with a concrete example of abstract content, we can validate whether content created outside their local wiki is acceptable and identify conditions needed for adoption.
WE2.3.6 If we design how Abstract Wikipedia content is surfaced and presented within local Wikipedias, and how local communities make integration decisions, we can socialize the proposal, reach agreement, and confidently plan Q4 development work.
WE2.5.1 If we deploy the Blazegraph candidate replacement in eqiad and augment existing evaluation work with production WDQS traffic-replay analysis, then we will confirm that the new backend performs comparably, supports real-world SPARQL queries, and is ready for limited live-traffic exposure once the surrounding ecosystem (UI, monitoring, onboarding, and real-time index update pipeline) is prepared.
WE2.5.2 If we define access guidelines for the Wikidata platform, we will better be able to control the load put on WDQS servers at the time of our backend migration.
WE2.5.3 If we define a cohort of user personas to test our new backend system, we will be prepared for the pilot and subsequent phases of the Blazegraph cutover.
WE2.5.4 If we produce a migration plan in a single document, we will be able to align upon and drive the execution of all aspects of the migration.
WE2.5.5 If we optimize the Wikidata Revert Risk model for low-latency inference and deploy it in a stable, scalable manner on LiftWing, then the Wikimedia Enterprise team will be able to integrate revert risk signals into their product pipeline, enabling customers to receive timely, high-quality model outputs.
WE3.1.8 If we evaluate 2 semantic search prototypes (natural language search, Q&A) with external participants, we can learn whether users see value in improved search tools, and provide the Readers teams with a recommendation on how to move forward with a search and discovery MVP.
WE3.1.12 If we collect a benchmark dataset consisting of a set of representative queries and annotations of relevant search results, we will be able to perform offline (i.e. without user studies) search evaluation of the quality of search results of different search models.
WE3.1.15 If we test hybrid search MVPs that blend keyword, natural-language, and meaning-based queries, in the Android app, we will rapidly identify the approach and design patterns that increases total search engagement by 10% without a negative impact on satisfaction, latency, or retention
WE3.1.16 If we define requirements for a Q&A model, we will produce model outputs to share with the community for feedback that we can incorporate into a production experiment.
WE3.1.17 If Search provides a production-ready (stable, performant) vector search infrastructure which supports semantic query processing — including a MediaWiki endpoint, then ML and Research will be able to generate embeddings and integrate their models with the system, enabling the MVP’s embedding-powered retrieval.
WE3.1.18 If we deploy a Qwen3 embeddings inference service that is compatible with our existing OpenSearch stack, then Mobile Apps can experiment with generating article-chunk and query embeddings through Qwen3, which should outperform the embeddings produced by OpenSearch’s built-in models.
WE3.3.6 If we make article topic inference data available via a service that meets agreed-upon scalability and availability requirements, plus any necessary data backfills, then we will have established the technical foundation necessary to support upcoming personalized reader experiences that depend on this data.
WE3.4.1 If we work towards a hybrid point of presence (PoP/CDN) deployment, it will allow us to bring up both full PoPs and mini PoPs (physical and cloud) as required, laying the foundation for a prototype mini PoP deployment in the future.
WE3.5.2 If we offer donors a badge acknowledging their status, at least 70% of donors who opt-in will report positive sentiment on a linked survey.
WE3.6.5 If Product & Technology and Fundraising collaborate on a shared strategy to diversify on-platform donation opportunities and steward and recognize readers who donate, we will set clear, aligned goals and metrics tied to our consumer and fundraising strategies.
WE3.6.6 If we develop a unified measurement strategy, we will enable evaluation of the consumers’ multi-year strategy and define a roadmap to guide metric development and reporting capabilities.
WE3.6.7 If we run a secondary A/A test on retention rate for logged-out users, we will begin to establish seasonal trends for retention rate that we can use for future quarters
WE3.6.8 If we systematically compare the information seeking needs and behaviors of 1) new and infrequent English Wikipedia readers and non-readers with those of 2) current English Wikipedia readers by simultaneously surveying both populations, we will be able to identify key insights about the demographic characteristics, online information needs, and online platforms used by these audiences, identifying potential opportunities for growing our readership as well as potential threats to our existing readership.
WE3.8.1 If we add additional modules to the activity tab and scale it to all users, we’ll see a 5% increase in overall iOS app account creation compared to before release
WE3.9.1 If we update the Wikipedia iOS app’s visual foundations, component defaults, and navigation behaviours to align with Apple’s Liquid Glass design language—while clearly defining design and behaviour for high-priority fallbacks across OS versions—then downstream engineering implementation will be clearer, lower-risk, and the app will feel more platform-native when Apple forces user switchover
WE3.10.1 If we user test a design prototype of the Explore Feed built with lightweight personalization, clear freshness cues, and repeatable Wikipedia-native patterns (e.g., topical rabbit holes, time-bound highlights, and interactive elements), casual reader participants will report understanding of the proposed feed’s purpose, reach an “aha” moment faster, and show a stronger intent for daily use. The visual design we recommend moving forward with will be described as digestible and aligned with the Wikimedia movement.
WE4.1.3 If we update 6 Wikipedias (English, French, German, Spanish, Italian, Polish) by the end of Q2, we will complete phase 1 of the new Legal Footer roll-out in response to DSA requirements.
WE4.2.5 If we conduct research, consult with communities, and investigate technical solutions, we will be able to define a set of structured block reasons that can be used across all WMF wikis.
WE4.6.8 If we monitor the impact of the Zendesk and MediaWiki forms we built in Q1, then we can propose technical interventions for future quarters that would better automate the rest of the account recovery process.
WE5.1.3c If we roll out rate limiting to all APIs routed through the gateway, we will be able to reduce the number of anonymous API requests that reach our backend infrastructure, by limiting requests based on user classes that give higher limits to authenticated and community users.
WE5.1.5 If we improve the sustainability and reliability of our OAuth 2.0 implementation, we will be able to convince more developers to use OAuth and support the migration of the Wikipedia mobile apps, by increasing confidence that it can be relied upon for high profile applications.
WE5.1.5b If we improve the developer experience for creating and managing OAuth 2.0 clients, we will be able to increase the number of applications that use OAuth 2.0, by deprecating OAuth 1.0 for new applications and promoting OAuth 2.0 as the preferred option for API authentication.
WE5.2.2c If we reroute all APIs currently going through the API Gateway through the common gateway, we will be able to fully deprecate the historic API Gateway and ensure consistency for all community facing Wikimedia HTTP/web APIs
WE5.2.6 If we introduce access controls to the sitemap API to only allow trusted bots, we can improve strategic alignment and reduce the risk of abusive scraping.
WE5.2.8 If we create dedicated API modules for all API extensions and self-contained functionality within MediaWiki Core, we will enable enforcement for higher quality documentation with independent management and versioning.
WE5.2.9 If we have better separation of concerns for API registration and spec definition processes, we will simplify the complexity of API management and create a better developer experience for API authors.
WE5.2.10 If we conduct a listening tour specifically focused on v2 API consolidation and feature gaps, we will be able to move more quickly with a v2 implementation.
WE5.2.11 If we experiment and establish processes for standardizing documentation currently in the API Portal, we can consolidate sources of information and improve documentation consistency.
WE5.3.1b If we publish and iterate on the draft UX guidelines and demos, we will establish a core framework ready to be internally tested and iteratively refined to be prepared for broader public use.
WE5.3.2b If we establish a partner pilot program to experiment with Wikimedia attribution, we can show mutually beneficial impacts of attribution by reusers to drive engagement and contributions to Wikimedia.
WE5.4.6 If by the end of Q2 we've classified the top N spiders as known bots, we can constrain the amount of resources they're using.
WE5.4.8 If we start enforcing rate limits tailored to different classes of individual clients for media files, we will reduce the burden of crawling on our infrastructure.
WE5.4.9 If we add ip-reputation data on residential proxies to our bot detection, it will improve our ability to block scrapers
WE5.4.10 If we stop allowing generation of non-standard thumbnail sizes, it will reduce the strain on our backend media serving infrastructure
WE5.4.11 If we identify two high-confidence signals from the December 2025 scraping/DDoS incidents and deliver them to SRE, then SRE will be able to develop more effective automated mitigation rules for future similar incidents.
WE5.4.12 If we are able to attest where and from whom a request for an image is originated, we can make more informed decisions about rate-limiting them
WE6.1.2 If we add wikifarms to a pre-merge testing environment this will enable development teams building against production who require multiple wikis to test their patches in isolation giving them greater pre-production confidence and result in fewer defect escapes.
WE6.1.3 If we resolve the top 5 flaky Selenium tests over the next 90 days, we will increase developer confidence in automated browser testing as a valuable part of the pre-deployment workflow.
WE6.2.4 If we apply, and actively support the Data Persistence design review, we may identify paved pathways to production
WE6.2.5 By collaborating with the SLO group and gathering feedback from teams currently working with them, will help us not only identify gaps and improvements for the Production Readiness checklist, but also adapt it in such a way to directly facilitate SLO adoption and onboarding
WE6.2.6 By piloting the production readiness checklist on the hCaptcha proxy service against launch and high-importance items, we will identify untracked technical debt and create a visible work backlog, which will demonstrate the framework's value, while shaping a repeatable process for consistent adoption across services.
WE6.2.7 By collaboratively refining the production readiness checklist with SRE input and contributions, we will ensure it addresses real operational needs, build shared ownership, and create a practical tool that teams see value in adopting.
WE6.2.8 By analysing feedback from our collaboration with the SLO group, hCaptcha proxy pilot, and SRE collaboration, we will identify which checklist items and process steps require clearer guidance or supporting resources, and determine the next steps for streamlining the framework to make adoption achievable before the December break.
WE6.2.9 If we adopt node.js service-utils, we will be able to release, in a tested way, either of: service-mesh routing or OpenTelemetry publishing.
WE6.3.2 If we develop new metrics, improve Parsoid's cache infrastructure, and deploy on two "top-ten" wikipedias, we will develop performance criteria for the confidence framework, which will help validate our readiness for deployment to other large wikis and demonstrate our ability to handle high-traffic volumes at scale.
WE6.3.3 If we implement critical Language Variant support improvements and successfully deploy Parsoid to at least 3 Language Variant wikis in Q2, we will identify and resolve the key technical challenges necessary to confidently roll out to all remaining Language Variant wikis.
WE6.3.4 If we QA, identify, triage, and fix bugs within the reading experience across platforms for Parsoid Read Views, we will maintain the quality of the reading experience and unblock further scaling across wikis
WE6.3.5 If we target a Time To First Byte (TTFB) metric of <= 110% of legacy for parser cache hits and <= 150% of legacy for parser cache misses, we can deploy to all Wikipedias except for Chinese and English by the end of Q3 with no performance complaints. This will help validate our readiness for deployment on English Wikipedia, preparing us to handle high-traffic volumes at scale by understanding our cache capacity.
WE6.4.4 If we unify our domains by serving all page views on MediaWiki sites through a canonical domain, then we will reduce platform complexity and SEO risks by eliminating the mobile-subdomain redirect. Completion is measured by decreasing redirects for mobile visits on canonical domains from 100% to 0%.
WE6.4.7 If we migrate at least 90% of all users with global root access to use a hardware-backed SSH key for accessing Wikimedia production servers, we will reduce the risk that a compromised laptop will cause a severe security breach.
WE6.4.8 If the MediaWiki Engineering Team actively monitors and fixes issues in MediaWiki related to the PHP upgrade, this will enable the SRE team to complete the production PHP 8.3 upgrade by November 2025.
Signals & Data Services (SDS) Hypotheses

[ SDS Key Results ]

Dyskusja

Hypothesis shortname Q3 text Details & Discussion
SDS1.5.1 If we create a regular, operationalized internal audit process for bot classification outputs, we will build trust in our solutions and anticipate changes in traffic patterns that are not automatically detected.
SDS1.5.2 If we deploy a Test Kitchen instrument with 100% sampling and a request identifier, we'll be able to capture all requests regardless of whether or not they sent client-side events and analyze them for bot behavior.
SDS1.5.3 If we analyze the basic client-side signal and incorporate it into our heuristics, we will detect additional bot patterns in the Data Platform.
SDS2.2.4 If Product Safety and Integrity reviews GrowthBook and FerretDB, we will be able to identify, then mitigate and/or address any material risks before production rollout.
SDS2.2.5 If we update Test Kitchen JS and PHP SDKs with methods to log experiment exposure, we will not need to treat all events as exposure events, which will improve performance of experiment assignment queries in GrowthBook and yield more accurate experiment results.
SDS2.4.2 If we safely expand traffic enrolment through monitored stress testing, we will increase statistical power for Reader team experiments, shortening experiment timelines and improving decision confidence.
Future Audience (FA) Hypotheses

[ FA Key Results ]

Dyskusja

Hypothesis shortname Q3 text Details & Discussion
FA1.1.1 If we build a central hub for new Wikipedia experiences on itch.io, then we’ll be able to grow an audience of >50 interested non-Wikipedians giving us feedback, which will help us learn what works and what doesn’t in games.
FA1.1.2 If we create and test 3 different app-based content discovery features as short experiments, we can share recommendations with the Apps team about how to effectively engage with and retain a new generation of apps users
FA1.1.3 If we create 4 TikTok filters and publish them on our TikTok account, we will be able to learn how well we can incentivize creation of Wikipedia content off-platform.
FA1.1.6 If we create 3 different potential previews for Wikipedia links shared on Discord, we can align internally on our measurement and execution strategy and collaborate with Discord's ProdEng team.
FA2.2.1 If we invest in community management across short-video platforms, then by the end of Q2 (December 2025) we will see a 30% QoQ increase in the percentage of views from New Viewers on TikTok — and across all SFV platforms, we’ll earn 50,000 total engagements (likes and reply comments) on brand comments left on external content, which will help us increase visibility and drive engagement with audiences we’re not currently reaching.
FA2.2.2 If we develop and get sign-off on a Wikipedia Creator Partnerships Program internal strategy and external shareables (inclusive of an outline of our value to creators, partnership criteria, contracting process, and how creator content will show up across owned and creator channels), we will be able to establish a robust creator strategy that will help us reach new audiences across social media with our knowledge content.
Product and Engineering Support (PES) Hypotheses

[ PES Key Results ]

Dyskusja

Hypothesis shortname Q3 text Details & Discussion
PES1.3.5 If we build community configuration for Easter Eggs, and leverage Reader Experience full time for code review, we’ll be able to launch on Feb 15 and track impact of the project.
PES1.3.6 If we create bespoke social media posts for 25 Years of Wikipedia (25YoW), we can achieve similar success with social impressions as Comms’ existing templates, and prove we can support Comms’ by increasing their capacity. Benchmarking will be off of Truth Collective posts about the same project.
PES1.4.1 If we meet with 4-5 teams that are not primarily using Codex (including, but not limited to, teams primarily using OOUI), we will be able to document blockers to those teams adopting Codex for current and future projects.
PES1.4.2 If we make Codex PHP easier to use and stable enough to do a 1.0 release, then teams will adopt Codex PHP for server-generated UIs. This will increase Codex PHP usage from 3 projects to 5.
PES1.5.1 If we upgrade Sloth from a prototype to a replacement for Pyrra, by onboarding existing services, we can converge on a unified set of SLO dashboards, refine our alerts, and streamline the SLO onboarding experience.
PES1.5.2 If we continue to onboard SLI metrics for Wikifunctions and MediaWiki Content History, and check metrics for WikiData Query Service and EditCheck, we will debug issues with both dashboard reporting and service-owner engagement on loud-but-unaddressed SLO reports.

Q4

The fourth quarter (Q4) of the WMF annual plan covers April-June 2026.

Wiki Experiences (WE) Hypotheses

[ WE Key Results ]

Dyskusja

Hypothesis shortname Q4 text Details & Discussion
WE1.3.3 If we launch an experiment to surface a moderator dashboard to newer editors, 10% of contributors who visit it do so two weeks in a row.
WE1.5.1a If we add new metrics to the Contributors dashboard using DBT we will enable contributor product teams to get more actionable insights into editing trends
WE1.5.5 If we automate updates of DBT models with Airflow on a fixed schedule, we will allow Movement Insights to build analyses and reports on those models using up-to-date information.
WE1.5.6 If we document workflows and establish per-team default output locations and access controls for dbt models, we will allow dbt usage to scale across team members in Movement Insights and other teams.
WE1.5.7 If we extend the MAM dashboard as specified, then we will have a more complete picture of moderator pipeline health that can inform decisions in the Contributor strategy.
WE1.6.1 If we introduce custom watchlist labels, we expect the labels to be used by 5% of users with more than 100 pages on their watchlist in the first month.
WE1.7.2 By testing a design prototype of the in-app webview editing flow with newcomers on the mobile apps, we will identify the highest-risk friction points that could cause abandonment before publishing - specifically around context shift, editor comprehension, and edit attribution - so that we can prioritize what must be resolved before this approach can successfully onboard new editors at scale.
WE1.7.4 If we prompt readily available GenAI models to generate and rank a set of edit suggestions for a diversified sample of 150 English Wikipedia articles, then we will learn what types of editing tasks these generic models can produce at scale and gain a rough, anecdotal understanding of the usefulness of these suggestions. This early signal will help us assess whether some task types could plausibly be generated at scale with generic models (with or without fine-tuning), or whether they would require more specialized approaches - ultimately helping us validate whether pursuing this "single model many suggestions" direction is worthwhile.
WE1.7.5 If we replace the unstructured Copyedit task with the Revise Tone structured task in a controlled experiment, then the task completion rate for Revise Tone edits made by junior editors will be higher than the completion rate for edits made through the Copyedit task.
WE1.7.6 If we test 2 structured workflows via design prototypes that align contribution opportunities with what readers arrive motivated to learn, and frame contributions as ways to act on curiosity or share knowledge they already possess, then concept testing will help us identify approaches that inspire readers to imagine themselves as contributors.
WE1.7.7 If we present an exit survey to users with ≤100 cumulative edits who abandon mobile editing sessions after spending ≥2 seconds in either the mobile visual or source editor, we will discover patterns in the reasons behind this behavior and be able to decide what interventions we will prioritize to increase the mobile web edit completion rate.
WE1.7.8 If we present junior contributors who enter the mobile VisualEditor with immediately actionable edit suggestions, then the proportion of edit sessions that result in someone publishing a constructive edit will increase by ≥10%.
WE1.7.9 If we publish a proposal on-wiki to enable VisualEditor by default for newcomers on mobile web at en.wiki, we will define the steps needed to make this happen.
WE1.8.2 If we improve the logged out edit warning, the account creation rate among newcomers on mobile exposed to the warning will increase by at least 2% relative to the control group.
WE1.8.3 If we improve the account creation form, the registration completion rate among mobile users who land on the form will increase by at least 2% relative to the control group.
WE1.8.4 If we add a user account button to the header on mobile web, then the number of new accounts created on mobile will increase by at least 2% relative to the control group.
WE1.8.5 If we surface Reading Lists to logged-out readers on mobile web, the registration rate will increase by at least 2% relative to the control group.
WE1.9.2

If we introduce key questions about factors that impact editor motivations [i] into the 2026 Community Insights survey, by the end of Q4 we will be able to provide ≥5 research insights which can inform our Contributors strategy implementation, with a focus on editor progression and recognition.

[i] Defined through the lens of competence (ability to use tools and resources), autonomy (ability to navigate the platform and make informed decisions), and relatedness (ability to join the community, feel supported and valued).

WE1.9.3 If we co-design guidance for mobile-first onboarding with at least two affiliates, by the end of June we will be able to identify which gaps are perceived by organizers as most detrimental to the retention of mobile-first newcomers.
WE1.10.3 If we work with a few selected communities to customize the Article Guidance workflow for their wikis, editors will get guidance that’s tailored to each community’s content and policies.
WE1.10.5 If we complete all path-to-production requirements for the Article Guidance A/B test (including security review, legal consultation, instrumentation, community outline review and translation, and experiment configuration) we will launch the experiment for it to run to completion before the end of Q4 and start generating statistically meaningful data on the impact of Article Guidance on the 30-day survival rate of articles created by junior editors.
WE2.2.13 If we socialize the availability of the conjugation table function with the Wiktionary community, we will gather early signals about editor understanding and usability that can guide future improvements.
WE2.3.7 If we identify and address small but frequent friction points in contribution workflows together with early contributors, we can support and sustain the engaged core community that is building the foundational building blocks for Abstract Wikipedia.
WE2.3.8 If we implement the capabilities for article-level opt-in integration of Abstract Wikipedia content into local Wikipedias, we can demonstrate how the model works in practice and be ready to engage pilot communities in Q1.
WE2.3.9 If we implement basic instrumentation for Abstract Wikipedia (in addition to existing MediaWiki instrumentation), we will better understand how users interact with Abstract Wikipedia and identify areas for improvement.
WE2.3.10 If we support displaying images from Commons in Abstract articles via Wikifunctions, we enable communities to incorporate visual elements commonly used in Wikipedia articles.
WE2.3.13 If we build an analytical capability to map content availability, production, and consumption against a flexible topic taxonomy, then we'll have greater visibility to content trends that we can derive insights from.
WE2.3.16 If the Rust evaluator is brought to feature parity with the Node evaluator and the Node evaluator phased out, we will eliminate a huge maintenance burden and free up engineering resources.
WE2.5.4 If we produce a migration plan in a single document, we will be able to align upon and drive the execution of all aspects of the migration.
WE2.5.6 If we develop the capability to automate output comparison between WDQS v1 and v2 for selected sets of queries, we will be able to improve confidence in the correctness of the new service.
WE2.5.7 If we assemble a plan for messaging about our migration, we will experience a smoother transition to the new endpoints by aligning with the Wikidata community on when to expect changes and how to prepare for them.
WE2.5.8 If we start to build the decoupled architecture described in our design doc, we should be able incrementally deliver value throughout the quarter and stand by a service that is able to support the pilot cohort by FY27 Q1.
WE3.1.15 If we test hybrid search MVPs that blend keyword, natural-language, and meaning-based queries, in the Android app, we will rapidly identify the approach and design patterns that increases total search engagement by 10% without a negative impact on satisfaction, latency, or retention.
WE3.1.16 If we define requirements for a Q&A model, we will produce model outputs to share with the community for feedback that we can incorporate into a production experiment.
WE3.1.17 If Search provides a production-ready (stable, performant) vector search infrastructure which supports semantic query processing — including a MediaWiki endpoint, then ML and Research will be able to generate embeddings and integrate their models with the system, enabling the MVP’s embedding-powered retrieval.
WE3.3.6 If we make article topic inference data available via a service that meets agreed-upon scalability and availability requirements, plus any necessary data backfills, then we will have established the technical foundation necessary to support upcoming personalized reader experiences that depend on this data.
WE3.4.1 If we work towards a hybrid point of presence (PoP/CDN) deployment, it will allow us to bring up both full PoPs and mini PoPs (physical and cloud) as required, laying the foundation for a prototype mini PoP deployment in the future.
WE3.5.3 If we implement consent-based donor segment storage in MediaWiki and establish a reliable CiviCRM → MW sync, Product and Fundraising will be able to successfully identify and differentiate donor segments on-platform across web and apps by the end of the quarter.
WE3.5.5 If we offer logged-out donors on mobile web a persistent Thank You badge by default that triggers a brief delightful interaction upon tap (C), then we will see a 1% improvement in 21-day cumulative retention rate compared to having a badge with a simple popover message (B), and users who do not get a badge at all post-donation (A). We will also track whether a larger percentage of donors in group (C) tap on the badge again in at least one future return session compared to those in (B), to inform whether playful interactions create a re-engagement loop.
WE3.6.9 If we coordinate across identified stakeholders, we will gather the necessary information on development needs, dependencies, and timeline to create a decision brief on the consumer strategy measurement plan that gets signed off by all relevant stakeholders.
WE3.6.10 If we run an A/A test on retention rate for logged-in readers, we will establish a baseline for retention rate we can use for future quarters.
WE3.6.11 If we analyze existing data to see what user factors or actions correlate with retention, we can document our understanding of what product interventions/levers might increase retention.
WE3.6.12 If we experiment with measuring whether increasing the amount of translated Wikipedia content leads to a direct increase in pageviews, we will be able to make a recommendation on future strategic investment into translations.
WE3.7.2 If we roll out the new “heart” donate button design to all projects with a header donate link on desktop, based on the positive results of the previous clickthrough rate experiment, the total number of donations coming from that entry point will not decrease.
WE3.8.2 If we provide reading lists on web as an opt-in beta feature, as well as opt-in all new user accounts, at least 50% of users will rate the feature as useful when surveyed.
WE3.8.3 If we add a temporary 25th Birthday reading challenge widget on the apps that motivates users to meet a reading goal, we'll see a 5% higher conversion rate from casual (2-week return) to active (2-day returned) for users who joined the challenge in the first 14 days, compared to our baseline of 16.8%.
WE3.9.3 If we widely roll out the image browsing carousel and detail view on mobile web, then we will maintain CTR > 5% on the carousel.
WE3.9.4 If we test the addition of the “Which came first” daily-play trivia game to the iOS App, we’ll see 15% of engaged logged-out readers return to play the game on multiple days.
WE3.10.3 If we show readers several concepts for traversing the knowledge network on the wikis, we will come away with a prioritized list of concepts for further development.
WE3.10.5 If we give readers an enhanced sharing option then [33%] of readers who see the dialog will complete the enhanced share action without harming logged-out reader retention.
WE3.10.6 If we redesign the mobile apps Explore Feed, we'll see a 10% practically significant increase in Explore Feed engagement over multiple days per unique logged-out reader within 14 days of release.
WE3.10.7 If we identify the most frequent and important unmet needs for casual users (as rated by them) as well as which early-stage concept ideas are most desirable and useful, we will be able to prioritize which concepts to put into A/B testing in FY26-27 to give us the best shot at increasing retention.
WE3.10.8 If we test adding Page Previews on Minerva, we will see practically significant improvement to logged-out reader retention.
WE4.6.13 If we encourage users with an unconfirmed email address to confirm their email address, then 10% of active users who receive this notification will attempt to confirm their email address.
WE4.6.16 If we build support for enforcing group membership restrictions on global groups, we will be able to use this to enforce a 2FA requirement for global groups.
WE4.6.17 If we announce and enforce 2FA requirements for an additional set of groups, the number of users who have sensitive rights but don't have 2FA will drop to 0.
WE4.6.18 If we build support for enforcing 2FA on private wikis, we will be able to use this to secure user accounts who have access to private information.
WE4.6.19 If we require reauthentication for sensitive actions and implement other hardening measures, we will be less vulnerable to an attacker exploiting user scripts.
WE4.6.20 If we proactively scan user scripts for malicious code, we will be less vulnerable to an attacker exploiting user scripts.
WE4.6.21 If we reduce the number of staff accounts with advanced rights and how long they have those rights for, attacks targeting staff accounts are less likely to cause damage.
WE4.8.1 If we introduce a mechanism that detects and surfaces related temporary accounts, including a connected-accounts panel on Special:Contributions, then patrollers will identify abusive temporary-account activity faster and more accurately.
WE4.8.3 If we investigate recent complaints about patrolling taking longer than before, we would be able to determine whether or not they are correlated with the introduction of Temporary Accounts.
WE4.10.1 If we roll out hCaptcha to more wikis (Special:CreateAccount, wikitext editor on desktop) in stages, we will increase bot detection coverage across all projects.
WE4.10.2 If we deploy the hCaptcha bot detection in the visual editing, discussion tools, file upload wizard, and mobile editing pathways on pilot wikis, we will see an increase of 35% in the percentage of actions on Wikimedia Foundation wikis that were verified by hCaptcha.
WE4.10.3 If we deploy an hCaptcha risk score collection for blocked edit notices, we will better understand collateral damage impacts of IP range blocks.
WE4.11.1 If we roll out the Incident Reporting System (IRS) on enwiki through a staged deployment, starting small and scaling to at least 50% of logged-in users, then we will have enough data from our newly instrumented metrics to determine if IRS should be adopted on enwiki.
WE4.12.1 If we optimize and compare the performance of at least 2 content policy models with a community-vetted dataset of oversighted (WP:Oversight) content from English Wikipedia, we will be able to recommend a model or combination of models for automatic oversighting or flagging of content that very likely should be oversighted.
WE4.12.2 If we host the gpt-oss-safeguard-20b, CoPE-A-9B, and CoPE-b-12b models on LiftWing and optimize each model's performance to meet the PSI team's initial evaluation requirements, then the PSI team will be able to test the three models and compare their behavior.
WE5.1.3e If we create a data product for analysis of API requests, we'll simplify analysis and segmentation of API requests, and allow Product Analytics to prototype the API Analytics Dashboard by further segmenting and aggregating this new data.
WE5.1.3f If we reduce API rate limits for requests that only provide a User-Agent, we will increase the number of authenticated and known clients, by encouraging UA-only users to move to a more responsible pathway.
WE5.2.2c If we reroute all APIs currently going through the API Gateway through the common gateway, we will be able to fully deprecate the historic API Gateway and ensure consistency for all community facing Wikimedia HTTP/web APIs
WE5.2.5b If we finalize the linter architecture and a core set of linting rules, we can improve the quality of OpenAPI descriptions and start introducing programmatic guarantees of their compliance into CI workflows in API development processes.
WE5.2.8b If we onboard at least 3 more API modules demonstrating a variety of use cases (at least 1 stand-alone service API, 1 feature team owned extension API, 1 internal module), we will be able to refine usability and set the foundation for the future of the API Platform.
WE5.2.11b If we complete API Portal documentation migration, we will be able to fully deprecate the API Portal system, which will simplify API documentation discovery, increase documentation consistency, and reduce the number of API support systems.
WE5.2.12 If we iterate on the design and discovery work required for building the unified front-door for developers early, we will be able to effectively expedite engineering work in FY26-27.
WE5.2.13 If we begin enforcing existing user-agent policies on the dumps website, we can better understand dumps users and use cases while ensuring more consistent access expectations across developer pathways.
WE5.3.2b If we establish a partner pilot program to experiment with Wikimedia attribution, we can show mutually beneficial impacts of attribution by reusers to drive engagement and contributions to Wikimedia.
WE5.3.3 If we provide content reusers with canonical, low-friction retrieval paths, we will lower the effort required to adopt trust signals from Wikimedia’s Attribution Framework, avoid the standardization of suboptimal retrieval paths, and unlock our ability to reliably measure attribution adoption.
WE5.3.3b If we build a data pipeline to compute unique contributor counts and develop a method to serve it to MediaWiki, we will be able to surface contributor counts as a signal to Attribution API users.
WE5.3.3c If we design and implement an API and event stream offering a naive, pageviews-based "relative trending" metric for pages, we will allow the Attribution API to use it as a Trust & Engagement metric and enable prototyping for the mobile apps.
WE5.3.4 If we define “qualified traffic” (specific outcomes of interest) and distinguish referrers by platform and surface, then we will observe systematic differences in downstream engagement and contribution outcomes that are relevant for product and partnership decisions.
WE5.3.4b If we establish a consistent set of traffic health indicators, then we can reliably detect and explain meaningful shifts in Wikimedia’s incoming traffic over time and by referrer beyond raw pageview counts.
WE5.3.4c If we analyze real-world visibility shocks as natural experiments, then we will see measurable changes in content quality and maintenance outcomes, supporting the relationship between visibility and content health.
WE5.4.2c If we can identify the official Wikimedia mobile apps on iOS and Android in the CDN using their application-layer fingerprints, we can add them as a known-client in requestctl, allowing us to set exceptions and custom rate-limits on them to ensure a smooth user experience.
WE5.4.8b If we rate limit requests for multimedia files based on a tally of response sizes, we will increase fairness in allocating the available bandwidth to users.
WE5.4.10 If we stop allowing generation of non-standard thumbnail sizes, it will reduce the strain on our backend media serving infrastructure.
WE5.4.12 If we create signals to distinguish on-site media traffic from external reuse, SRE can prioritize on-site traffic when under load by rate-limiting expensive media requests from external sources.
WE5.4.12b If we can get the image provenance information from MediaWiki, we can use that in conjunction with other identifiers such as referrers and the assigned X-Is-Browser score to relax or vary the rate-limits for on-wiki users.
WE5.4.13 If we establish regular processing and reporting of WE5 objective indicator metrics (request rate, bandwidth, and User-Agent compliance), it will help us track progress across the KRs and assess the effectiveness of blocking high-volume scraping and enforcing the User-Agent policy.
WE5.4.14 If we make our WAF software less tied to our CDN infrastructure, it will be able to serve more use-cases, internal or not.
WE5.4.15 If we can identify and categorize known large-scale NATs containing wiki users, we can use this information to fine-tune ratelimits and other defenses more-strictly on a per-IP level to blunt some of the impact of scraping.
WE5.4.16 If we create a threat model for selected operators of automated traffic, including their intentions, level of investment and techniques employed, we will be able to advance the SRE teams’ ability to identify scrapers and other actors.
WE5.4.17 If we can do near-real time analysis on webrequest traffic to detect one kind of persistent scraping campaign, it will allow us to export rules from the data lake that we can push out to the edge automatically to block/throttle that scraping.
WE6.3.3 If we implement critical Language Variant support improvements and successfully deploy Parsoid to at least 3 Language Variant wikis in Q2, we will identify and resolve the key technical challenges necessary to confidently roll out to all remaining Language Variant wikis.
WE6.5.1 If we investigate and audit the performance concerns and catalog the content-caching fragility for logged-in users, informed by the Readers' strategy for readership retention, we can plan ST6.4 confidently with the right prioritisation framework by observing which cataloged concerns deliver the most value.
WE6.5.2 If we experiment with a platform for cross-wiki code collaboration, testing on at least 4 Indian communities, we will learn how to empower community developers to reuse modules across wikis, and receive positive feedback of these findings at the Hackathon the first week of May. This will be scoped to Lua Modules only, and integrated with WMF's GitLab infrastructure.
WE6.6.1 If we reduce the runtime of the Browser Test jobs to under 10 minutes, we will remove them as the bottleneck and reduce the feedback time of the MW Core Main test build.
WE6.6.2 If we reduce the runtime of the Unit Test jobs to under 10 minutes, we will remove them as the bottleneck and reduce the feedback time of the MW Core Main test build.
Signals & Data Services (SDS) Hypotheses

[ SDS Key Results ]

Dyskusja

Hypothesis shortname Q4 text Details & Discussion
SDS1.5.1 If we create a regular, operationalized internal audit process for bot classification outputs, we will build trust in our solutions and anticipate changes in traffic patterns that are not automatically detected.
SDS1.5.2 If we deploy a Test Kitchen instrument with 100% sampling and a request identifier, we'll be able to capture all requests regardless of whether or not they sent client-side events and analyze them for bot behavior.
SDS1.5.3 If we analyze the basic client-side signal and incorporate it into our heuristics, we will detect additional bot patterns in the Data Platform.
SDS1.5.4 If we move our heuristics to a private repository, we will protect the exact logic and data sources we use from motivated attackers.
SDS1.5.5 If we add a numerical score to our pageview metric based on 2 of the signals we’ve evaluated, we will provide a more complete and nuanced view of our traffic.
SDS1.5.6 If we use hCaptcha scores collected as events on account creation and edits as trusted labels, we’ll be able to correlate them to signals and our current bot detection heuristics to evaluate both.
SDS2.2.4 If Product Safety and Integrity reviews GrowthBook and FerretDB, we will be able to identify, then mitigate and/or address any material risks before production rollout.
SDS2.2.5 If we update Test Kitchen JS and PHP SDKs with methods to log experiment exposure, we will not need to treat all events as exposure events, which will improve performance of experiment assignment queries in GrowthBook and yield more accurate experiment results.
SDS2.2.8 If we conduct end-to-end user acceptance testing (UAT) with analyzing Reader Growth’s upcoming A/B/C test exclusively in GrowthBook, then we will learn which aspects of the experience meet production-readiness standards and which need improvement and supporting content before wider rollout.
SDS2.3.1 If we validate and adapt GrowthBook's API to our own, we can use GrowthBook as the canonical experiment control plane, and if we regularly poll GrowthBook's API, we can deliver experiments configured in GrowthBook quickly and easily.
SDS2.3.2 If we implement custom validation in GrowthBook, we’ll know people can’t accidentally misconfigure experiments in ways that violate the constraints of the platform.
SDS2.3.3 If we confirm role-based needs for GrowthBook users (humans, automation scripts from WMF, affiliates with established trust, and prospectively, vetted NDA end users), ensure automatic de-provisioning of stale users with regular report back to DPE, and update documentation to describe the role-based approach and user expectations regarding permissions and system interaction, user onboarding will be more predictable, and we'll have some additional guards to avoid exceeding our paid licensed seating.
SDS2.4.2 If we safely expand traffic enrolment through monitored stress testing, we will increase statistical power for Reader team experiments, shortening experiment timelines and improving decision confidence.
SDS2.4.3 If we introduce support for non-cache splitting experiments, then teams will be able to test JS-only features beyond the current traffic caps (10% all wikis, 0.1% enwiki), removing one of the primary barriers preventing teams from adopting Test Kitchen.
Product and Engineering Support (PES) Hypotheses

[ PES Key Results ]

Dyskusja

Hypothesis shortname Q4 text Details & Discussion
PES1.4.2 If we make Codex PHP easier to use and stable enough to do a 1.0 release, then teams will adopt Codex PHP for server-generated UIs. This will increase Codex PHP usage from 3 projects to 5.
PES1.5.3 If we enable SLO-based alerting, and make it possible to generate reports quarterly and automatically, service owners will be able to respond to service reliability data without (always) needing SRE to initiate.
PES1.5.4 If we set expectations with SRE Ambassadors about roles and responsibilities for SLOs and production readiness in FY26-27, onboard TPgMs and Objective owners to those expectations, and define how the SLO working group will operate, we will achieve buy-in and scalability for “business as usual” SLO and production readiness work starting in Q1.
PES1.6.2 If we onboard directors to the Service Catalog, they will populate it with "obvious" candidates, and we will identify and find owners for at least 2 more critical unowned services.
Future Audience (FA) Hypotheses

[ FA Key Results ]

Dyskusja

Hypothesis shortname Q4 text Details & Discussion
FA1.1.2 If we create and test 3 different app-based content discovery features as short experiments, we can share recommendations with the Apps team about how to effectively engage with and retain a new generation of apps users
FA1.1.6 If we create 3 different potential previews for Wikipedia links shared on Discord, we can align internally on our measurement and execution strategy and collaborate with Discord's ProdEng team.
FA2.2.1 If we invest in community management across short-video platforms, then by the end of Q2 (December 2025) we will see a 30% QoQ increase in the percentage of views from New Viewers on TikTok — and across all SFV platforms, we’ll earn 50,000 total engagements (likes and reply comments) on brand comments left on external content, which will help us increase visibility and drive engagement with audiences we’re not currently reaching.
FA2.2.2 If we develop and get sign-off on a Wikipedia Creator Partnerships Program internal strategy and external shareables (inclusive of an outline of our value to creators, partnership criteria, contracting process, and how creator content will show up across owned and creator channels), we will be able to establish a robust creator strategy that will help us reach new audiences across social media with our knowledge content.

Wspólne planowanie

Aktualizacja, styczeń 2025

Portrait of Selena

Plan roczny jest opisem tego, co Wikimedia Foundation ma nadzieję osiągnąć w nadchodzącym roku. Ciężko pracujemy, aby plan był partycypacyjny, ambitny i osiągalny. Każdego roku prosimy współedytorów o podzielenie się swoimi perspektywami, nadziejami i konkretnymi prośbami w celu kształtowania planu. Niektóre ze sposobów, w jakie szukamy tego wkładu, to rozmowy zespołów produktowych ze społecznościami, Lista życzeń społeczności i rozmowy takie jak seria rozmów na temat Commons, na konferencjach i za pośrednictwem stron wiki, takich jak ta.

W przypadku naszego następnego planu rocznego, obejmującego okres od lipca 2025 do czerwca 2026, zastanawiamy się, w jaki sposób możemy najlepiej służyć wielopokoleniowej wizji, biorąc pod uwagę szybkie zmiany na świecie i w Sieci oraz to, jak wpływają one na naszą misję wolnej wiedzy.

Jak powiedziałam w zeszłym roku, musimy skupić się na tym, co nas wyróżnia: naszej zdolności do dostarczania wiarygodnych treści, nawet gdy dezinformacja i fałszywe informacje łatwo rozprzestrzeniają się w Internecie i na platformach konkurujących o uwagę nowych pokoleń. Obejmuje to zapewnienie, że realizujemy misję gromadzenia i dostarczania światu sumy całej ludzkiej wiedzy poprzez poszerzanie naszego zakresu brakujących informacji, które mogą być spowodowane nierównościami, dyskryminacją i uprzedzeniami. Nasze treści muszą też pozostać pomocne istotne w zmieniającym się Internecie napędzanym sztuczną inteligencją i bogatymi doświadczeniami. Wreszcie, musimy znaleźć sposoby na zrównoważone finansowanie naszego ruchu poprzez budowanie wspólnej strategii dla naszych produktów i pozyskiwania funduszy, abyśmy mogli wspierać tę pracę w perspektywie długoterminowej.

Aby dokonać wyborów i kompromisów dotyczących tego, na czym skupić nasze wysiłki w nadchodzącym roku, zebraliśmy pytania i zastanowiliśmy się, jak przydzielić nasze ograniczone zasoby, aby osiągnąć jak największy wpływ.

Jeśli jesteś ciekaw/-a konkretnych funkcji lub usług, które dział Produktu i Technologii zbuduje w oparciu o ustalone tutaj priorytety, w marcu będzie czas na skomentowanie konkretnych celów i kluczowych wyników. (Poniżej znajdują się cele i kluczowe rezultaty dla bieżącego planu rocznego).

Jeśli chcesz zastanowić się nad wyzwaniami i szansami w naszym środowisku technicznym oraz kierunkiem, który powinniśmy wyznaczyć w następnym planie rocznym, rozważ z nami poniższe pytania.

Nieustannie zbieramy informacje w tematyce tych pytań na wiele sposobów - z rozmów ze społecznością, gromadzonych przez nas danych, przeprowadzanych wywiadów badawczych i nie tylko. Nie jest to pierwszy raz, kiedy pytamy i uczymy się wiele z tych rzeczy - a nad wieloma z nich już pracowaliśmy! Chcemy teraz zadać owe pytania ponownie i uczyć się dalej, ponieważ są one dla nas najważniejsze na tym etapie naszego planowania.

Pytania:

  • Metryki i dane
    • W jaki sposób dane i wskaźniki mogą lepiej wspierać pracę edytorów? Czy możesz pomyśleć o danych dotyczących edycji, czytania lub organizowania, które pomogłyby Ci wybrać, jak spędzić czas lub kiedy coś wymaga uwagi? Mogą to być dane dotyczące Twojej własnej aktywności lub aktywności innych osób.
  • Edytowanie
    • Kiedy edytowanie jest dla Ciebie najbardziej satysfakcjonujące i przyjemne? Kiedy wydaje się ono najbardziej frustrujące i trudne?
    • Chcemy, aby edytujący otrzymywali więcej informacji zwrotnych i uznania za swoją pracę, tak, aby nie mieli poczucia, że nikt nie zauważa ich wysiłku włożonego w pracę nad wiki. Jaki rodzaj informacji zwrotnej i uznania jest dla Ciebie motywujący? Co zachęca cię do dalszej edycji?
    • Ponieważ wiki są tak duże, edytorom może być trudno zdecydować, które zadania na wiki są dla nich najważniejsze i na które powinni poświęcać swój czas każdego dnia. Jakie informacje lub narzędzia mogą pomóc w wyborze sposobu spędzania czasu? Czy przydatne byłoby posiadanie centralnego, spersonalizowanego miejsca, które pozwala znaleźć nowe możliwości, zarządzać zadaniami i zrozumieć swój wpływ?
    • Chcemy usprawnić współpracę na wiki, aby ułatwić współtwórcom odnajdywanie się nawzajem i wspólną pracę nad projektami, czy to poprzez nadrabianie zaległości projektowych, edycje, wikiprojekty, czy nawet współpracę dwóch osób edytujących. Jak myślisz, jak moglibyśmy pomóc większej liczbie edytorów znaleźć się nawzajem, połączyć i pracować razem?
  • Czytanie/uczenie się
    • Strony wiki ładują się szybciej lub wolniej w zależności od tego, gdzie na świecie mieszkają ludzie. Czy są jakieś części świata, w których uważasz, że poprawa wydajności jest najbardziej potrzebna?
    • Jak możemy pomóc nowym pokoleniom czytelników znaleźć interesujące i angażujące treści Wikipedii? W przeszłości omawialiśmy pomysły dotyczące interaktywnych treści i wideo, a w bieżącym roku skupiliśmy się na wykresach i eksperymentowaniu z nowymi sposobami wyświetlania istniejących treści Wikipedii. Jak możemy kontynuować tę ścieżkę, aby wykorzystać naszą istniejącą zawartość na nowe sposoby, które są unikalne dla Wikimediów?
  • Moderatorzy
    • Co miałoby się zmienić w Wikipedii, aby więcej osób chciało zaangażować się w zaawansowane role wolontariuszy, takie jak patrolowanie lub administrację?
    • Jakie informacje lub kontekst na temat edycji lub użytkowników mogłyby pomóc w szybszym lub łatwiejszym podejmowaniu decyzji dotyczących patrolowania lub administrowania?
  • Trendy zewnętrzne
    • Jakie są najważniejsze zmiany, które zauważasz w świecie poza ruchem Wikimedia? Mogą to być trendy w technologii, edukacji lub sposobie uczenia się.
    • Poza ruchem Wikimedia, w jakich innych społecznościach internetowych uczestniczysz? Jakie wnioski możemy wyciągnąć z narzędzi i procesów na innych platformach społecznościowych?
    • Jak wykorzystujesz narzędzia sztucznej inteligencji w swojej pracy w Wikimediach i poza nimi? Do czego przydaje ci się sztuczna inteligencja?
  • Commons
    • Jakie decyzje możemy podjąć ze społecznością Commons, aby stworzyć trwały projekt wspierający tworzenie wiedzy encyklopedycznej?
  • Wikidata
    • Jak chciał(a)byś, aby Wikidane ewoluowały w przyszłości? W jaki sposób projekt ten może być najbardziej przydatny do tworzenia godnych zaufania treści encyklopedycznych?

–– Selena Deckelmann

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Wikimedia_Foundation_Annual_Plan/2025-2026/Product_%26_Technology_OKRs/pl&oldid=30618380"