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

This page is a translated version of the page Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs and the translation is 100% complete.

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.
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.
  - 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.

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
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ń
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.

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).

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.
  - 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.

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.

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.

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

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.

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.

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.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.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.

Wspólne planowanie

Aktualizacja, styczeń 2025

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?

Dyskusja

–– Selena Deckelmann