Mpango wa Mwaka wa Wikimedia Foundation/2025-2026/Malengo na Matokeo Muhimu ya Bidhaa na Teknolojia

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

Outdated translations are marked like this.

Mwaka Ujao

Hata dunia inapobadilika, Shirika la Wikimedia Foundation bado lina uhakika kwamba tunataka dhamira yetu - kutengeneza na kuweka taarifa muhimu kutoka kwenye miradi ya Wikimedia inayopatikana kwenye mtandao bila malipo - iwe ni juhudi ya vizazi vingi: tunataka maarifa ya bure yaendelee kupatikana kwa vizazi vingi vijavyo.

Mtandao wa intaneti unabadilika haraka. Vizazi vipya vinapata taarifa kupitia video za kijamii na uzoefu wa AI, na, ikilinganishwa na vizazi vya zamani, wachache wao wanafahamu Wikipedia. Tunaona kupungua kwa idadi ya watu wanaokuja kwenye tovuti zetu na idadi ya watu wanaohariri. Wakati huo huo, majukwaa kwenye mtandao yanategemea maudhui ya Wikimedia ili kusisitiza AI zao na matoleo ya utafutaji. Mienendo hii ni changamoto kuu, lakini inaweka wazi kwa nini maarifa ya kuaminika ya bure ambayo tunaunda pamoja ni muhimu sana. Ulimwengu unahitaji chanzo cha maarifa cha kutegemewa, kilichopitiwa upya na binadamu zaidi ya hapo awali, na miradi ya Wikimedia inaendelea kuonyesha kwamba inaweza kutoa.

Ili kukabiliana na changamoto hizi kwa mwaka ujao, tutaunda njia za kutumia maudhui ya Wikimedia kwa uendelevu, na tutaleta maudhui ya Wikimedia kwenye nafasi za kijamii za mtandaoni ambako vizazi vipya vinatumia muda wao. Tutaboresha tovuti zetu ili wasomaji watake kurudi, kushiriki kwa kina, na kuchangia kwa njia ambazo ni muhimu kwao. Na tutawekeza katika uwezo wetu wa kujaribu teknolojia mpya haraka, ili kasi yetu ya maendeleo ilingane na kasi ambayo ulimwengu unabadilika.

Lengo la miundombinu ni jinsi jukwaa na uzoefu wa mtumiaji utasaidia kukabiliana na changamoto hizi na kufikia wengi wa washiriki katika harakati. Si orodha ya miradi, lakini badala yake, seti ya maelekezo ya kuchochea ukuaji wa wafanyakazi wa kujitolea, kuwawezesha wanaojitolea kuunda maudhui ya ensaiklopidia ya kuaminika, kufadhili misheni yetu, na kutoa toleo letu ili kuchagiza mabadiliko ya intaneti. Unaweza kusoma zaidi kuhusu hizo nguzo nne za kimkakati.

Kukuza ujitoleaji wa watu

Jumuiya ya watu wanaojitolea ndiyo injini ya kipekee iliyo nyuma ya mafanikio ya miradi ya Wikimedia, na tunaihitaji ili iwe na afya na kukua. Lakini katika mwaka huu uliopita, tumeona kuendelea kupungua kwa idadi ya wahariri wapya na wanaorejea kwenye miradi. Ili kuelewa vyema na kujibu kwa ufanisi mahitaji ya wafanyakazi wetu wa sasa wa kujitolea, Shirika lilirekebisha Orodha ya Matamanio ya Jumuiya kutoka kwenye uchunguzi wa mara moja kwa mwaka hadi katika mchakato wa upokeaji ulio wazi kila wakati ambapo mahitaji ya mtumiaji na mawazo ya mradi yanaweza kujiingiza katika kazi ya timu nyingi katika Shirika. Tulipanga matamanio katika "Maeneo Lengwa" na tumeunganisha Maeneo lengwa matatu chini ya matokeo muhimu katika mpango wa kila mwaka. Pia tulianzisha jaribio la Baraza la Ushauri la Bidhaa na Teknolojia ili kuongezea mazungumzo mengi ambayo timu za Shirika huwa nayo na wanajamii kwenye- na nje ya wiki kwa mwaka mzima. Zaidi ya hayo, tumetambua fursa za kuleta vizazi vipya katika miradi yetu, kama vile ukweli kwamba vijana wanashiriki kwa shauku katika maeneo mengine ya kijamii ya mtandaoni ambapo wana njia rahisi, zinazofaa kwa simu za mkononi za kuunganisha juu ya mada zinazovutia zinazoshirikiwa.

Kwa mwaka ujao, tutakuza ukuaji wa wafanyakazi wa kujitolea kwa kufanya uchangiaji kuwa rahisi na kuvutia zaidi vizazi vipya kupitia kupanua simu-kwanza, njia mpya za kuhariri (“majukumu yaliyopangwa”), na kuongeza utendakazi mahiri unaorahisisha uhariri mzuri wa simu kwa wachangiaji wapya zaidi (“kuchunguza hariri ”). Ili kuwashirikisha kwa undani zaidi na kuwahifadhi wafanyakazi wa kujitolea waliopo, tutaonesha vitendo na kazi zinazopendekezwa na kuzionyesha katika kitovu kikuu kinachorahisisha kupanga shughuli za wiki. Tutatumia AI kwa uangalifu ili kuimarisha wafanyakazi wa kujitolea katika kazi yao, kila mara tukiwahabarisha watu katika na kutanguliza uwazi. Kwa wajitoleaji wapya na wenye uzoefu, tutaunda njia za kuungana na kufanya kazi pamoja kwenye tovuti zetu - kwa kuchochewa na kampeni zilizofaulu na WikiProjects - kuwaruhusu kupata wahariri wenye nia ya kupendwa na kuboresha maudhui yanayohusiana na mambo yanayowavutia (yanayowiana na eneo hili la kuzingatia katika Orodha ya Matamanio).

Kuunda maudhui ya kiensaiklopidia ya kuaminika

Kadiri nyenzo zinazozalishwa na AI zinavyoongezeka kwenye mtandao, ulimwengu unahitaji maudhui ya ensaiklopidia ya kuaminika zaidi kuliko hapo awali. Tunataka kuongeza uwezo wa watu wanaojitolea kuunda maudhui mapya, kuhakikisha kwamba maudhui yaliyopo yanaendelea kuaminika, na kuwasilisha maudhui ya kuaminika kwa kizazi kipya cha wasomaji wenye mahitaji na mapendeleo mapya.

Ili kuwasaidia watu wanaojitolea kuunda maudhui mapya, tutatumia zana na utendakazi uliopo elekezi (kama vile Zana ya Kutafsiri Maudhui), ili jumuiya kubwa na ndogo ziweze kushughulikia maudhui muhimu. Ili kuhakikisha kuwa maudhui yaliyopo yanaendelea kuaminika, tutasaidia wafanyakazi wa kujitolea wenye uzoefu kudhibiti vyema mzigo wao wa kazi unaoongezeka kwa kupanua zana wanazotumia ili kutafuta kazi zinazohitaji kuzingatiwa - ili iwe rahisi kwao kusasisha makala na kurejesha mabadiliko yasiyokuwa na manufaa (yanayoambatanishwa na eneo hili la kuzingatia Orodha ya Matamanio).

Pia tutasaidia watendaji kutetea maudhui yetu kwa kuwasilisha ishara mpya (zaidi ya anwani za IP) zinazotambua watendaji wabaya, kuruhusu watumiaji kuzuiwa kwa njia zinazopunguza uzuiaji kimakosa wa wahariri wenye nia njema.

Ili kuwasilisha maudhui ya ensaiklopidia kwa kizazi kipya, tutaunda vipengele vinavyosaidia aina mpya za wasomaji kuelewa makala kwa urahisi, kuwasaidia kupata maelezo wanayopenda, na kuwaruhusu kushiriki kikamilifu wanaposoma. Mabadiliko haya yanakusudiwa kuwahimiza wasomaji wapya wa Wikipedia kuwa wasomaji waliojitolea wa Wikipedia, na baadhi yao kuwa wafadhili (kuendana na eneo hili la kuzingatia Orodha ya Matamanio).

Kuwasilisha maudhui ya kuaminika pia kunamaanisha kuunga mkono muundo wa “maarifa kama huduma”, ambapo mtandao mzima unatumia maudhui ya Wikimedia. Katika modeli hii, miundombinu yetu si tu rasilimali muhimu kwa wanadamu wanaokuja kwenye tovuti yetu, lakini pia kwa ajili ya utafutaji na makampuni ya AI, ambayo hufikia maudhui yetu kiotomatiki kama pembejeo ya msingi na matokeo kutoka kwa bidhaa zao. Aina hizi za kampuni zinawakilisha moja tu ya matumizi mengi ambayo yanazidi kuweka mzigo usio endelevu kwenye miundombinu yetu. Katika mwaka uliopita, ongezeko kubwa la kiasi cha ombi linalotoka kwa zana za kuchakachua na roboti limefanya iwe muhimu zaidi kwetu kusahihisha mtindo huu. Tunahitaji kuanzisha njia endelevu kwa wasanidi programu na watumiaji tena kufikia maudhui ya maarifa ili wanadamu wapewe kipaumbele kuliko roboti.

Kutoa ruzuku kwaajili ya mustakabali wa baadaye wa maudhui ya ‘bure’

Idara ya Bidhaa na Teknolojia ina jukumu muhimu katika kuhakikisha kwamba harakati zetu ni endelevu. Kwa mwaka ujao, tutashirikiana kwa karibu na timu ya Kuchangisha pesa ili wafadhili wetu wapate uzoefu unaozidi kuwa wazi na wenye kuthawabisha. Kwenye tovuti zetu na programu za simu, tutajenga fursa kwa wasomaji kutoa shukrani zao kwa Wikipedia kupitia uchangiaji, na tutajenga njia mpya za wafadhili kujisikia kutambuliwa ili waendeleze michango yao mwaka baada ya mwaka.

Kuunda intaneti inayobadilika

Ili kuleta maarifa ya bure kwa kila mtu ulimwenguni, tunahitaji kukutana nao mahali walipo, na uzoefu unaomsaidia kujifunza. Watu wenye umri wa miaka 18-24 wana ufahamu mdogo na matumizi ya Wikipedia kuliko vizazi vilivyokuja kabla yao. Kwa kiasi kikubwa hujifunza na kuingiliana na majukwaa fupi ya video, watu wanaoaminika mtandaoni, uzoefu wa kijamii wa michezo ya kubahatisha, na, zaidi, programu za AI. Mwaka huu, tutafanya Wikipedia ipatikane kwa watazamaji hao katika maeneo wanayotumia muda mtandaoni, ili wajue Wikipedia kama chanzo cha maarifa cha kuaminika na kilichoundwa na binadamu. Tutakuza uwepo wetu katika mifumo maarufu ya video, tukieneza maudhui ya Wikipedia na kuzalisha jumuiya katika nafasi hizo. Na tutachunguza mawazo ya kuleta maarifa ya Wikipedia kwenye michezo ya kubahatisha na majukwaa ya kijamii.

Ndani ya Miundombinu, hii imegawanywa katika makundi matatu za kazi (zinazoitwa "ndoo"): Uzoefu wa Wiki, Huduma za Ishara na Data, na Hadhira za Baadaye. Ndoo hizi ni sawa na mwaka jana na mwaka uliopita.

Kwa pamoja, tunaamini kwamba mpango huu unakutana na wakati muhimu katika historia ya mtandao, ukituweka sisi ili kuhakikisha kwamba maudhui ya maarifa yasiyolipishwa yanaendelea kupatikana na kutengenezwa na vizazi vyote. malengo yetu na matokeo muhimu yanaonyesha muundo na yaliyomo katika mpango huu kwa undani zaidi, na tunatarajia kusikia maswali na mawazo kutoka kwa jumuiya pana.

Kujenga, kuboresha na kudumisha miundombinu ya miradi ya Wikimedia na watu wa kujitolea, kwa kuzingatia maadili yetu

"Shirika litafanya na kuweka taarifa muhimu kutoka kwenye miradi yake inayopatikana kwenye mtandao bila malipo, milele."

Timu za Bidhaa na Teknolojia huweka kipaumbele cha kudumu, cha mwaka mzima ili kujenga, kuboresha na kudumisha miundombinu inayohudumia miradi ya Wikimedia. Tunawekeza katika kuandaa miradi ya Wikimedia, kutengeneza programu huria na mifumo ya kubuni, na kudumisha na kuboresha miundombinu ya bidhaa za data na miundo ya AI.

Sehemu ya kazi yetu muhimu inalenga misingi ya kuendeleza na kukaribisha tovuti kubwa maarufu. Tunapangisha miradi yetu ya Wikimedia katika vituo vya data, kwenye seva na maunzi tunayonunua, kusakinisha na kudumisha, kuunganishwa na kila mfumo mwenza na kwenye mtandao na kwenye mtandao wa intaneti kupitia mtandao wenye kasi. Tunafuatilia na kuongeza uwezo inapohitajika, na kuonesha upya vifaa vinapozeeka sana. Kwa mfano, mwaka huu, tunatarajia kupanua uwezo wetu na kuonesha upya maunzi yetu katika vituo vyetu vya kuhifadhia data huko Ashburn, Virginia na Carrollton, Texas.

Tunasanifu na kutengeneza programu huria (hasa MediaWiki). Pia tunatumia na kusambaza programu huria za wahusika wengine, maktaba na mifumo. Hitilafu muhimu katika programu yetu hupewa kipaumbele na kurekebishwa. Kudumisha programu huria kunahitaji kazi yenye ustadi wa hali ya juu kutoka kwa watu walio na utaalamu maalum katika uundaji wa programu huria, uhandisi wa kutegemewa wa tovuti (SRE), usimamizi wa bidhaa, usimamizi wa programu, muundo na zaidi. Wafanyakazi wetu wanafanya kazi ili kuhakikisha programu na mifumo yetu inasasishwa na kuzoea mazingira yanayobadilika kila mara. Hii ni pamoja na kuboresha msimbo wetu ili kuendelea kunufaika kutokana na marekebisho ya usalama na kufanya kazi vyema na programu mpya za watu wengine. Kwa mfano, MediaWiki imeandikwa katika PHP, na katika mwaka uliopita tulihama kutoka PHP 7.4 hadi 8.1, ambayo ilihitaji mabadiliko kwenye msimbo na miundombinu ambapo tunapangisha tovuti na huduma zetu. Mwaka huu, tutaendeleza juhudi hizo na kuhamia 8.3, kwa kutumia mafunzo tuliyojifunza na zana zilizoundwa katika uboreshaji wa 8.1. Kusasisha kutafanya mifumo yetu iwe ya haraka zaidi kwa wasomaji, iwe rahisi kutumia kwa wafanyakazi na watu wanaojitolea, na salama zaidi kwa kila mtu. Pia itaokoa wakati wa maendeleo wa siku zijazo kutokana na usalama, utendakazi na uboreshaji wa usaidizi unaokuja na masasisho ya lugha.

Ili kuhakikisha miradi na maudhui yetu yanaendelea kupatikana kwenye Mtandao, leo na daima, timu zetu hutoa kiasi kikubwa cha jitihada ili kuhakikisha upatikanaji wa juu wa tovuti na huduma zetu. Kipengele kimoja cha kazi hii kinazingatia uokoaji wa maafa kutokana na matukio hatari au mabaya. Kwa mfano, tunahakikisha kuwa tuna nakala rudufu za data muhimu, na tunaweza kurejesha kutoka kwazo. Vile vile, mara mbili kwa mwaka tunajaribu uwezo wetu wa kubadilisha tovuti zetu kati ya vituo vyetu vya data kwa mtindo wa kiotomatiki, na kurekebisha matatizo yoyote tunayopata. Kipengele kingine cha kazi hii kinalenga katika kutambua na kukabiliana na mienendo inayoendelea katika aina na wingi wa trafiki tunayopokea. Kwa mfano, pamoja na ukuaji usio na kifani katika vichota taarifa otomatiki, tunatanguliza kazi ili kuhakikisha kuwa tovuti na huduma zetu zinasalia kufikiwa na watumiaji wa kibinadamu, tukichukua mkabala wa utaratibu wa kuweka kanuni kuhusu utumiaji unaowajibika wa miundombinu yetu.

Sio kazi zote zinazopangwa mapema. Pia tunashughulikia matukio na matukio yasiyotarajiwa, kama vile kukatika kwa tovuti, ripoti za usalama au matukio ya usalama, au mashambulizi makubwa ya uharibifu kwenye miradi yetu. Tunafuatilia utendaji wetu na vizuizi vya kufikiwa kote ulimwenguni (ikiwa ni pamoja na matatizo ya muunganisho wa Intaneti, au vizuizi vya udhibiti), na kuchunguza hitilafu zozote tunazopata. Baadhi ya matukio haya yasiyotarajiwa au mifumo ya kurudia ya matatizo husababisha wafanyakazi kutanguliza miradi ya ufuatiliaji ya muda mfupi ambayo inalenga kupunguza au kuzuia kabisa athari mbaya zaidi. Kwa mfano, aina hizi za juhudi zilikuwa muhimu kuwezesha miradi yetu ya Wikimedia kuhimili ongezeko la trafiki duniani kutokana na matukio makuu ya habari (k.m., vifo vya watu mashuhuri wa hali ya juu), kupitia mseto wa utendakazi bora, usanifu upya wa maeneo yenye vikwazo, na ongezeko la uwezo. Vile vile, maboresho ya hivi majuzi ya utumiaji wa zana na mifumo yetu ya kudhibiti trafiki tunayopokea yametuwezesha kuitikia kwa haraka na kwa ufanisi mabadiliko ya hali. Aina hii ya kazi inayobadilika ni muhimu kwa uwezo wetu wa kujibu matukio ibuka, mara nyingi kwa mizani ya muda mfupi, na kuhakikisha miradi na maudhui yetu yanaendelea kupatikana.

Malengo ya Bidhaa na Teknolojia

Malengo yaliyowasilishwa hapa yako katika muundo wa rasimu na yako wazi kwa maoni na majadiliano.

Malengo yanawakilisha mwelekeo wa kiwango cha juu.
"Matokeo Muhimu" (KRs) yanawakilisha njia inayoweza kupimika ya kufuatilia mafanikio ya malengo yao.
Kimsingi "Nadharia" za kila KR huwakilisha kazi halisi tunayofanya ili kujaribu kufikia matokeo muhimu yanayohusiana. Yatasasishwa katika waraka huu na kwenye mradi husika au kurasa za wiki za timu kadri maarifa yanavyopatikana mwaka mzima.
ni ya kazi ambayo Shirika linaipa kipaumbele chini ya Orodha ya Matamanio ya Jumuiya.

Uzoefu wa Wiki (WE)

Uzoefu wa Wachangiaji (WE1)

Lengo: Michango huongezeka kwa sababu wanaojitolea wanapewa fursa zinazovutia na kuelewa athari zao. Jadili
- Muktadha: Lengo hili litakuwa msingi wa kuwasilisha mkakati mpya wa wachangiaji wenye nguzo zake 3: 1) kuwapa watu wanaojitolea njia kuu ya kupanga shughuli zao za wiki, 2) kutoa kazi ndogo na za kipekee ili kuleta uwazi zaidi na kuwasaidia wanaojitolea kufikia uwezo wao, na 3) kutoa mchango wenye maana zaidi. Katika mwaka wa 25/26, tunapanga kuwasilisha miundomsingi ya kimsingi ili kuwasaidia wanaojitolea kupanga shughuli zao za mtandaoni kwa njia ya kati, tukianza na hatua zinazolenga wahariri na wasimamizi wazoefu. Katika miaka inayofuata tutaongeza uingiliaji kati katika majukumu yote ya wachangiaji na kujumuisha nafasi zaidi za matatizo. Zaidi ya hayo, tutaendelea kuwekeza katika Kuhariri na Kazi Zilizoundwa, tukijenga msingi wa jinsi ya kutumia AI kwa njia inayoweza kusambazwa, kama mwongozo wakati wa mchakato wa kuhariri na kama njia ya kuwaelekeza wanaojitolea kwenye fursa zinazovutia. Na mwisho, tutawekeza katika kuwafanya wajitoleaji wa athari waonekane zaidi ili kuwaundia matumizi ya maana zaidi.
  - Tokeo muhimu WE1.1: kuongeza kiwango ambacho wahariri walio na hariri limbikizi ≤100 huchapisha mabadiliko ya kujenga kwenye mtandao wa simu [i] kwa 4% [ii], kama inavyopimwa kwa majaribio yanayodhibitiwa (hadi mwisho wa Q2).
    - i. "Hariri zenye tija" = mabadiliko kwa kurasa katika ukurasa mkuu wowote wa Wikipedia ambao hayajarejeshwa katika hali yake ya awali ndani ya saa 48 baada ya kuchapishwa.
    - ii. T389403#10960480
    - Wajitoleaji wapya wanatatizika kuanza kuhariri kwa mafanikio. Hasa, watu wanaotumia vifaa vya mkononi ambapo nafasi ya skrini ni ndogo na umakini mara nyingi hugawanyika.
    - Wengine huchoshwa na muktadha, subira, na majaribio na makosa yanayohitajika ili kuchangia kwa njia yenye kujenga. Wengine bado hawajapata fursa ya kuamua kujaribu.
    - WE 1.1 tutashughulikia masuala haya kwa:
      - Kuonesha mapendekezo ya kuhariri
      - Kutoa mwongozo wa kuhariri unaoweza kutekelezeka
      - Kuunda mtiririko wa kazi maalum wa kuhariri
    - Katika msingi wa juhudi hizi ni hitaji la njia kubwa za kugundua jinsi mabadiliko yanayoendelea na maudhui yaliyopo yanaweza kuboreshwa. Ili kukuza uwezo huu, tutaendelea kufanya majaribio ya kujifunza kwa mashine ili kujifunza jinsi inavyoweza kuwahudumia wahariri vyema zaidi, katika majukumu na viwango vya uzoefu.
    - Mbinu inayopendekezwa ya kupata alama ya Matokeo Muhimu: Kwa msingi wa kila jukwaa, tutakokotoa uwiano wa hatua tulizotumia na kutathmini kupitia majaribio yaliyodhibitiwa ambayo yalitimiza na/au kuvuka lengo la uhariri unaojenga tulioweka mwanzoni mwa mwaka huu. Tazama phab:T379285#10782051 kwa kutafakari.
      - Kumbuka: kuanzia tarehe 30 Juni 2025, WE 1.1 ina majaribio mawili ya udhibiti yaliyopangwa.
  - Tokeo muhimu WE1.2: Kuongezeka kwa idadi ya ushirikiano kwenye wiki kwa 55% YoY kufikia mwisho wa Q4.
    - Wachangiaji mara nyingi hutatizika kupata fursa za kushirikiana wao kwa wao, hasa kuhusu mada na kazi wanazojali. Hii inaweza kusababisha hisia ya kuwa peke yako kwenye wiki kwa wageni, na inaweza kusababisha uchovu kwa wahariri wenye uzoefu. Zaidi ya hayo, athari za shughuli za ushirikiano mara nyingi hazieleweki, ambayo inaweza kusababisha watu wachache kutaka kujiunga, kupanga, au kuunga mkono ushirikiano kwenye Wiki.
    - Tunataka kufanya thamani ya ushirikiano iwe wazi zaidi kwa kufanya yafuatayo:
    1. Kuunda njia mpya za kushirikisha athari za shughuli shirikishi kwenye wiki
    2. Kuanza kukusanya data za harakati kuhusu athari za shughuli za kiushirikiano
    3. Kuweka miundo msingi ya kufuatilia michango shirikishi, ili tuweze kutoa njia mpya za kibunifu za kutambua na kutuza michango katika siku zijazo.
    - Ushirikiano utapimwa kwa shughuli mpya zitakazoundwa kupitia Usajili wa Tukio katika kiendelezi cha Matukio ya Kampeni. Lengo ni kwamba, kufikia mwisho wa KR hii, tutakuwa na watumiaji zaidi wa zana za upanuzi na njia mpya za kupata athari za ushirikiano. Hili litatuweka katika nafasi nzuri ya kuunganisha miundombinu yetu iliyopo kwa njia zingine za kutambua na kuthawabisha kazi kwenye wiki (kama vile moduli ya athari, asante, n.k).
    - Eneo la kuzingatia orodha ya matamanio: Orodha ya Matamanio ya Jumuiya/Maeneo Lengwa/Kuwaunganisha Wachangiaji
  - Tokeo kuu la WE1.3: Hadi mwisho wa Q3, 10% ya wachangiaji ambao waliwasilishwa kwa ukurasa wa nyumbani uliolenga wasimamizi wapya waliutembelea wiki mbili mfululizo.
    - Tunaamini kwamba tunaweza kufanya kazi bora zaidi ya kuibua fursa za michango kwa watu wanaojitolea. Muda mrefu tunaamini ukurasa wa nyumbani unaweza kusaidia kwa mhariri yeyote kupanga kazi yake, kupata fursa mpya na kuelewa athari zake. Lengo letu katika Mwaka wa Fedha 25/26 ni kuwasilisha fursa mpya kwa wahariri wenye uzoefu ili kuchukua kazi za usimamizi ambazo si lazima wangeonyeshwa.
    - Tuitajaribu nadharia hii kwanza kwa kuelewa ni kiasi gani wahariri wenye uzoefu wangetumia ukurasa wa nyumbani, sawa na kile ambacho wageni wanaweza kufikia.
    - Kisha tutaonyesha shughuli mahususi za udhibiti (maelezo yatabainishwa) kwa wachangiaji ambao ni wapya kwa aina hiyo ya hatua ya usimamizi, kwa lengo la kusaidia kupunguza mzigo kwa wahariri wenye uzoefu kupitia viporo vilivyopunguzwa (chini ya Matokeo Muhimu mapya).
    - Ikiwa tutafaulu na dhana ya ukurasa wa nyumbani, tunapanga kuufanya ukurasa huu kuwa wa kawaida ili kukidhi mahitaji ya jumuiya. Moduli hizi zinaweza kujumuisha mambo kama vile kurahisisha wahariri kuelewa athari zao.
    - Vidokezo juu ya mbinu:
    - Tutakuwa na nadharia tete ya kufafanua hadhira yetu, ambayo itakuwa sehemu ya WE1.3.1.
    - "Wasimamizi" watafuata ufafanuzi ulioanzishwa katika Research:Develop a working definition for moderation activity and moderators, ingawa kazi ya ufuatiliaji ingehitajika ili kupunguza ufafanuzi wa kiasi.
    - Wiki ya pili itabainishwa kuhusiana na muda wa ziara ya kwanza ya kila mtumiaji. Katika hali hii, tungepitia wasimamizi wote wapya waliotembelea ukurasa wa nyumbani kwa muda uliowekwa na kisha kufanya angalau ziara moja ya kurudia (siku 7 hadi 14) baadaye.
    - Eneo la kuzingatia orodha ya matamanio: Orodha ya Matamanio ya Jumuiya/Maeneo Lengwa/Utiliaji vipaumbele vya Kazi
  - Tokeo kuu WE1.4: Kuboresha % ya wageni wa kipekee kwenye orodha ya kutazama na/au mabadiliko ya hivi Karibuni wanayobofya kuona hariri.
    - Lengo letu ni kuwasaidia wahariri walio na hariri 100+ ili kupata na kufungua hariri zinazohusiana na mambo yanayowavutia kwa ufanisi zaidi. Tutachunguza Eneo Lengwa la Uwekaji Kipaumbele cha Jukumu, kutoa matakwa katika eneo hili, na kutafuta maoni ya ziada kutoka kwa watu wanaojitolea kuhusu jinsi ya kuboresha mifumo hii. Tunaweza kupima mafanikio kwa kuboresha ufanisi wa kila ukurasa katika "kutafuta kazi", iliyofafanuliwa na kipimo cha kiashirio cha viwango vya kubofya.
  - Tokeo muhimu WE1.5: Kufafanua na kutekeleza vipimo saba vya kipaumbele cha juu [1] vinavyohitajika kwa ajili ya kufuatilia maendeleo ya kufikia malengo yaliyoainishwa katika mkakati wa mchangiaji kufikia mwisho wa Q4, kwa kuunda dashibodi na uendeshaji wa vipimo vya Msimamizi Hai wa Kila Mwezi.
    [1] Wahariri walioshikiliwa, uwezeshaji wa kujenga, uhariri unaojenga, usajili wa akaunti ulibakiza watu wapya, wahariri hai kwa muda, wahariri hai kulingana na kiwango cha uzoefu.
    - Mkakati wa uzoefu wa wachangiaji unatazamia juhudi za miaka 3-5 za "kuchochea ukuaji wa watu wa kujitolea" na "kuongeza ubakizaji na utendaji" wa wachangiaji wapya na waliopo kupitia maeneo makuu matatu ya shughuli:
    1. Kurahisisha jinsi watu wa kujitolea wanaweza kupokea mapendekezo, kusimamia kazi na mambo yanayowavutia, kuona kinachoendelea kwenye wiki, na kuelewa athari zao.
    2. Kutoa majukumu yaliyopangwa ipasavyo ili kuleta uwazi zaidi na kuwasaidia wanaojitolea kufikia uwezo wao kwa kuboresha mtiririko wa kazi tunaotuma, ikiwa ni pamoja na kuendelea kuwekeza katika kutoa mwongozo uliopangwa na majukumu ya kujirudia kiotomatiki, kwa kuzingatia matumizi maalum ya mtandao wa simu.
    3. Kutoa mchango wa maana kwa kuonyesha watu wanaojitolea athari zao na kwa kuwekeza katika njia za uhusiano wa kibinadamu na mazingira kulingana na mrejesho mzuri.
    - Mradi wa mkakati wa kipimo kisha ulionyesha kwa muhtasari mtandao mkubwa wa vipimo vya kufuatilia nadharia hii ya mabadiliko. Ulihitimisha kuwa kipimo cha msingi cha mafanikio (“kipimo cha msingi”) kinapaswa kuwa hesabu ya wahariri waliodumishwa, ikisaidiwa na vipimo finyu zaidi vya kiashirio kama vile uamsho wa kujenga na nia ya wachangiaji ya kurejesha na vipimo vipana vya "chini" kama vile wahariri hai na maudhui ya ubora. Tunahitaji kuhakikisha kuwa vipimo hivi vimetekelezwa na kuonekana kwenye dashibodi, ili tuweze kufuatilia maendeleo yetu kuelekea utekelezaji wa mkakati.
  - Key result WE1.6: By the end of Q3, watchlist users can more easily organize their work and act more effectively on taking patrolling or editing action, as measured by qualitative feedback.
    - Our goal is to help editors with 100+ edits to more efficiently find edits that relate to their interests. We will explore the Task Prioritization Focus Area, deliver wishes in this area, and solicit additional feedback from volunteers on how to improve these surfaces.
  - Key result WE1.7: Primary: Achieve a ≥ 10% relative increase in the edit completion rate of qualified newcomer and Junior Contributor mobile edit sessions, based on controlled A/B test(s).[i]
    [i] Qualified edit session = edit session in which a logged-in user with ≤100 cumulative edits spent at least ≥2 seconds in VE's "ready" state.
    Guardrail: No meaningful decreases in constructive edit rate among mobile edits published by newcomer and Junior Contributors, based on controlled A/B test(s).
    - 150,000–200,000 times/day, someone will tap "Edit" on mobile web, wait for the editing interface to load, look around for at least 2 seconds, and then leave without doing anything. No keystrokes, no taps on the toolbar…nothing.
    - WE 1.7 will meet these "curious clicks" with clear, compelling, and structured edit suggestions that cause the people making them to experience the satisfaction, joy, and meaning that can come with making Wikipedia, the resource they chose to visit, a bit better.
  - Key result WE1.8: By the end of Q4, target a 5 percent overall relative increase in the mobile web account creation completion rate, with success measured by at least three controlled experiments achieving a minimum 2 percent relative improvement each.
    - Account creation is the gateway to meaningful participation on Wikimedia projects, yet it remains an outdated experience in the newcomer journey. The current flows impose high cognitive load, present limited or confusing value propositions, and rely on legacy interface patterns that no longer reflect contemporary expectations. As a result, many potential contributors disengage before they have a chance to join the community.
    - This initiative aims to modernize account creation, reduce friction for good faith contributors, and introduce thoughtful experiments that encourage registration at the moments where motivation is naturally highest. The work lays essential groundwork for long term improvements in newcomer activation, retention, and editor diversity.
    - We estimate a 5 percent relative increase in account creation on Wikipedia on mobile would translate to several thousand additional new accounts per month, and several hundred more retained new editors per month, based on current registration volumes.
  - Key result WE1.9: By the end of Q4, deliver one tangible product recommendation each for goal setting, newcomer progression, and recognition to enable junior contributors to stay engaged and evolve.
    - Background: we know that retention of junior contributors is quite low despite recent gains (data). We believe that a fundamental challenge for overcoming this low junior contributor retention is developing our platforms to help editors stay highly motivated to contribute – i.e. not just reducing the barrier to contribute but also making the experience rewarding. This is not trivial though – e.g., editors enter the project with varying motivations; interventions such as gamification that may boost initial engagement might not help with long-term retention.
    - Why now: much of the focus of Contributors Product teams to date has been related to reducing technical barriers to activation/engagement but there are a suite of upcoming projects that are more retention-focused – e.g., Progression System and Recognition. The research under this KR aims to get ahead of this implementation work and provide clear recommendations to Product teams in this space about how they should design their platforms to better support the diverse motivations of editors and increase long-term retention. This links back to key questions related to newcomers and junior editors in the Contributor Strategy.
    - Proposed KR scoring methodology: for each identified project (goal setting; progression system; recognition), we will make at least one concrete recommendation with implications for design. Research is experimental work and the projects may evolve over the course of the KR but we will keep in close communication with the relevant product teams. In practice, these recommendations may include insights about what is most demotivating for newcomers (things to avoid) what is most satisfying (things to emphasize), common "tripping points" in journeys that need to be addressed, strategies for getting through these challenges, etc. The recommendation should help the PM identify clear next steps for design and/or engineering.
  - Key result WE1.10: By the end of Q4, implement a new guided article creation flow where the survival rate of articles created by junior editors on mobile is 5% greater on each deployed wiki than articles created by other means while the volume of surviving articles stays the same or higher, as measured by a controlled experiment.
    - The Article guidance initiative aims to develop new approaches that support editors in creating initial, well-structured contributions to Wikipedia that align with community policies and content quality. As an initial intervention, a new workflow for article creation was implemented last quarter, based on community-editable outlines that encapsulate the guidance for specific types of articles. In Q4, the goal is to run an A/B test experiment to measure the impact on a set of pilot wikis to evaluate the impact. Since the guidance is community-dependent, the experiment preparations will requires collaboration with the communities of the pilot wikis to adapt the system to their needs.

Maarifa Muhimu (WE2)

Lengo: Kufanya maarifa muhimu zaidi yapatikane na kuoneshwa vyema katika lugha na mada mbalimbali. Jadili
- Muktadha wa lengo: Lengo hili litachochea ukuaji wa maudhui unaozingatia maslahi ya wachangiaji katika mada na lugha mahususi, na hitaji la msomaji la maarifa muhimu ambayo yameonyeshwa vyema. Ujuzi muhimu ni seti ya makala ambayo hutoa upana na undani wa mada zinazohitajika kwa mradi wa lugha ya Wikipedia. Inafafanuliwa na jumuiya kwa kurejelea kujulikana, umuhimu, usomaji uliotabiriwa, na miunganisho kati ya makala.
- Tutachukua mbinu ya kijamii na kiufundi, kuboresha ufanisi wa vipengele, zana na michakato ya kijamii. Tutatumia vipengele vya bidhaa vyenye athari ya juu kama vile kazi zilizopendekezwa, utafutaji wa maudhui na tafsiri ya maudhui lakini pia kuwezesha uanzishaji na ukuzaji wa Wikipedia za lugha ndogo. Tutawasaidia waandaaji wa Wikimedia ambao huajiri, kutoa mafunzo na kusaidia wachangiaji ili kufanyia kazi malengo ya maudhui shirikishi kupitia usanidi shirikishi kama vile Miradi ya Wiki na kampeni. (Tunakadiria kuwa angalau waandaaji 300 wanashiriki kila robo mwaka.) Pia tutakuza uhusiano na wachapishaji wanaofaa zaidi ili kuondoa vizuizi kwa nyenzo za chanzo. (Kwa sasa tuna ushirikiano na kanzidata zaidi ya 100 maarufu zaidi duniani kwaajili ya kujisajili tu.)
- Ili kuhakikisha uingiliaji kati wetu una matokeo chanya kwenye maarifa muhimu, tutapima ongezeko la maudhui yaliyopewa kipaumbele na jumuiya na ubora wa maudhui hayo, tukiangalia vipengele kama vile viwango vya ubadilishaji na idadi ya marejeo na picha.
  - Tokeo muhimu la WE2.1: Mwishoni wa Q2, kujaribu na kutathmini hatua 3 zinazosaidia wachangiaji kuboresha hali ya maudhui muhimu kwenye Wikipedia zao.
    - KR hii itaangazia mapengo ya maudhui ndani ya taratibu za kuhariri, kama vile ugunduzi wa picha kwenye Wikipedia, tafsiri ya maudhui na uundaji wa makala mpya. Pia tutatekeleza na kujaribu uingiliaji kati wa kijamii na kiufundi ili kusaidia shughuli ya kuunda maudhui kwa jumuiya za lugha ndogo. Mafanikio yatapimwa ndani ya kila dhana.
  - Tokeo kuu la WE2.2: Mwishoni mwa Q4, kujenga uwezo wa jukwaa unaohitajika ili kuthibitisha kwamba tunaweza kuunga mkono maono ya Muhtasari wa Wikipedia kwa kiwango. Tutajua kuwa tumefaulu ikiwa tutaonyesha maudhui ya mfumo wa ensaiklopidia tajiri, ya lugha nyingi kwa kutumia Wikidata na uundaji wa lugha asilia, inadhibitiwa na jumuiya ya Wikimedia, na kubaki tendaji katika utandazaji mpana.
    - Kwa kuwa sasa tunaweza kutumia Wikidata kutoa maudhui ya msingi, maandishi wazi kwenye Wikipedia, hatua inayofuata ni kuendelea kujenga uwezo wa jukwaa ambao unaweza kusaidia Abstract Wikipedia kwa kiwango kikubwa. Jukwaa litahitaji kuunga mkono maudhui tajiri, ya lugha nyingi ambayo yanaweza kudhibitiwa na jumuiya na kuendelea kufanya kazi kwa kiwango kikubwa. Hii ni hatua ya KR tunapotoka 0-1.
  - Tokeo kuu la WE2.3: Mwishoni mwa Q4, tumia fomu ya awali ya wiki mpya kwa ajili ya kuunda makala za Muhtasari za jumuiya.
    - KR hii hutuweka ili kujaribu uwezo wa jukwaa la Muhtasari wa wiki mwaka ujao. Wiki mpya, inayojitegemea itakayohifadhi maktaba ya makala za muhtasari zilizoundwa kwenye Wikifunctions, na kutoa uwezo wa jukwaa unaohitajika ili kujumuisha baadaye makala za muhtasari kwenye Wikipedia siku zijazo.
  - Tokeo kuu la WE2.4: Kuweka sawa WMF na WMDE kuhusu ufafanuzi wa mafanikio ya uboreshaji wa miundombinu ya kiufundi inayosaidia jambo muhimu la utumiaji wa Wikidata kufikia mwisho wa Q2, ikijumuisha vipimo na malengo hadi Mwaka wa Fedha 25-26.
    - Timu ya WMF Wikidata Platform (WDP) ilianzishwa na kuajiri - Kiongozi mmoja wa Bidhaa na Kiongozi mmoja wa Teknolojia - mnamo Agosti 2025. Kama nyongeza mpya kwa programu yenye maendeleo ya miaka mingi kupitia wamiliki wa kiufundi na bidhaa katika WMF na WMDE, mtawalia, lengo hili linaonyesha nia yetu ya kubadilisha umiliki kupitia upatanishi wa masuala ya matumizi, utegemezi na vigezo muhimu vya mafanikio. Tokeo hili muhimu litajenga msingi wa kuelewana kuhusu nafasi ya tatizo, ambayo tutaijenga kwa kipindi kizima cha mwaka wa fedha (Mei 2026).
  - Key result WE2.5: By the end of Q4, our backend replacement has been stood up in parallel to Blazegraph and is capable of supporting the cutover of select users. We define “migration ready” for this KR as capable of supporting the pilot phase of our migration in Q1 of FY26-27.
    - Following the progress made towards defining the success criteria as a part of WE2.4, we are now shifting into execution mode. In the next two quarters, we will outline all of the variables associated with the Blazegraph cutover in a migration plan, determine which are critical for pilot launch, implement them in a new RDF database, and define the migration timeline for all requirements beyond our pilot personas. Our work between now and our target launch of a new WDQS backend (est. July 2026) will be guided by the requirements laid out in this plan.

Uzoefu wa Mtumiaji (WE3)

Lengo: Wasomaji kutoka vizazi vingi hujishughulisha, na wanaendelea kujishughulisha, na Wikipedia, na kusababisha ongezeko linalopimika la uhifadhi na shughuli ya uchangiaji. Jadili
- Muktadha wa lengo: Lengo hili litalenga kuhifadhi wasomaji wapya kupitia miundo bunifu ya maudhui, hadhira kuu kupitia kuimarisha uzoefu unaofahamika wa usomaji, na kuhakikisha uendelevu wa muda mrefu kwa kuimarisha miunganisho ya wasomaji na kutoa michango mbalimbali. Itajumuisha muendelezo wa kazi yetu ili kurahisisha ugunduzi wa maudhui kupitia vipengele vipya na vya majaribio zaidi kama vile muhtasari wa AI au maeneo tata yaliyobinafsishwa. Pia itajumuisha kazi ya kubakiza na kuboresha ubora wa uzoefu wa kusoma kwa kina zaidi katika faneli ya kusoma na kuchunguza uratibu wa usomaji kupitia orodha za usomaji na ushiriki mwingine usio wa kuhariri. Kwa wafadhili, kazi hii itaendelea kulenga utofautishaji wa vyanzo vya mapato kutoka ndani ya jukwaa.
  - 'Tokeo muhimu la WE3.1: Kufikia mwisho wa Q2, kuonyesha ongezeko kubwa la ubakishaji wa wasomaji waliyotoka, kama inavyopimwa kupitia majaribio ya A/B ya kipengele kimoja kwa kila jukwaa
    - KR hii italenga kuendelea kuwekeza katika matumizi ambayo yanaboresha njia mpya za kuvinjari na kujifunza maudhui, mara nyingi kwa kutumia teknolojia na miundo mipya - kuwasilisha maudhui yaliyopo kwa njia mpya na zinazovutia. Katika mwaka huu wa fedha, tungependa kuendelea kujaribu vipengele vipya huku tukizingatia kuongeza majaribio yaliyofaulu kwenye wiki na mifumo. Kazi katika KR itaenea kwenye tovuti ya simu na eneo-kazi, pamoja na programu za iOS na Android na kulenga ugunduzi wa maudhui (maelekezo ya kuvinjari na mapendekezo) na miundo ya kujifunza inayoweza kubadilika (muhtasari unaosaidiwa na mashine, uchanganyaji wa maudhui).
    - Eneo la kuzingatia orodha ya matamanio: Matukio mapya ya watumiaji
  - Tokeo muhimu WE3.2: Ongeza idadi ya michango kupitia njia zisizo za mabango au barua pepe kwa 5% Mwaka baada ya Mwaka kwa kila jukwaa kupitia afua za bidhaa zinazokuza miunganisho ya kina na kupunguza msuguano kwa wafadhili kufikia mwisho wa Q2.
    - KR hii itatuona tukiendelea kuchunguza maeneo mapya ya michango na fursa nyingine za kubadilisha wasomaji kuwa wafadhili na kuwafanya waendelee kuwa nasi kwa kuimarisha miunganisho yao kwenye Wiki, ikijumuisha maudhui yaliyobinafsishwa zaidi. KR itaangazia kutambulisha pointi mpya za kuingia na kurudia maeneo yaliyopo kwenye programu na wavuti, kwa ushirikiano na timu ya kuchangisha pesa.
  - Tokeo muhimu WE3.3: Mwishoni mwa Q2, kuonyesha ongezeko kubwa la ubakishaji wa msomaji aliyeingia, kama ilivyopimwa kupitia majaribio ya A/B ya kipengele kimoja kwa kila jukwaa
    - KR hii italenga kuboresha hali ya usomaji na ujifunzaji kwa wasomaji waliopo na wenye uzoefu, kwa lengo la kuhifadhi hadhira yetu ya sasa na kuimarisha muunganisho wao kwenye tovuti ili wapate kujifunza zaidi, na pia kuwa tayari na kuwa wazi kuchukua njia kuelekea mchango na uhariri. Kazi kwa eneo hili hapa italenga kuboresha hali ya usomaji kwenye wavuti na programu (maboresho ya usomaji, usogezaji bora na ugunduzi), pamoja na kuendeleza na kusisitiza kuhusu uratibu na matoleo yetu ya kuweka mapendeleo (Orodha za kusoma, mapendekezo yaliyobinafsishwa, historia ya mtumiaji na makala, n.k.)
  - Tokeo muhimu WE3.4: Mwishoni mwa Q4, kuondoa vizuizi vyote vilivyotambuliwa kwa uwekaji wa tovuti ndogo ya hifadhi muda (PoPs) ambayo inakidhi ubora wetu wa sasa wa huduma na viwango vya usalama kulingana na uwekaji wetu wa sasa wa tovuti ya hifadhi muda
    - KR hii italenga kuthibitisha dhana kwamba tunaweza kuboresha utendakazi wa tovuti na kupunguza muda wa kusubiri kwa wasomaji wetu kwa kurahisisha miundombinu yetu ya akiba na kuboresha michakato ya uwekaji wa tovuti ya kache kwa kupunguza muda wa awali wa utumaji kutoka takriban mwaka mmoja kwa wastani hadi robo kabisa. Lengo hapa litakuwa kukamilisha kurahisisha, kupeleka PoC, kufanya ukaguzi wa usalama na kukamilisha muhtasari wa uamuzi kuhusu kama kuendelea na kupeleka akiba zetu za kache kwa umma. Kupungua kwa muda wa kusubiri kunaweza kusababisha ongezeko lililothibitishwa la utazamaji wa kurasa na msingi wa wasomaji wa kijiografia zaidi.
  - Tokeo muhimu WE3.5: Kuboresha utambulisho wa wafadhili - kuhakikisha kuwa wasomaji wote walioidhinishwa walioingia kwenye tovuti wanaweza kutambuliwa kwa hali ya wafadhili kwa matumizi maalum - mwishoni mwa Q4.'
    - Tutatekeleza mikakati ya utambulisho wa wafadhili ili kuhakikisha kuwa wasomaji wote walioidhinishwa walioingia wanaweza kutambuliwa kulingana na hali ya wafadhili, na hivyo kuwezesha utumiaji ulioboreshwa zaidi na unaovutia. Juhudi za kuwatambua wafadhili zitapewa kipaumbele kwenye robo mwaka ya nne Q4 ili kusaidia juhudi zenye tija za utambulishi na uwezeshaji kwa siku zijazo.
  - Tokeo muhimu la WE3.6: Kukamilisha, kuchapisha na kuwasilisha mkakati wa msomaji wa Wikipedia na matumizi ya watumiaji katika majukwaa yote hadi mwisho wa Q4, kwa malengo yaliyobainishwa na vipimo vya kimsingi, vilivyoundwa kwa ushirikiano na wadau na jumuiya, ili kuongoza kazi yetu hadi 2030.
    - Kazi kuhusu mkakati wa watumiaji itaendelea, kwa kulenga kujenga na kuwasilisha mkakati huo ndani pamoja na jumuiya na kufafanua na kuanzisha vipimo vya msingi kwa watumiaji, na misingi yao husika.
  - Key result WE3.7: Increase the number of donations through non-banner or email methods by 10% YoY per platform through product interventions that foster deeper connections and reduce friction for donors by the end of Q4.
    - This KR will see us continue to explore new entry points for donation and other opportunities to convert readers into donors and retain them by deepening their connections to the wikis, including more personalized content. The KR will focus on introducing new entry points and iterating on existing entry points on apps and web, in collaboration with the fundraising team.
  - Key result WE3.8: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for active readers in a test environment, monitoring a guardrail appropriate for the feature.
    - This KR will focus on scaling features that showed promise in improving engaged reader retention (or related indicator metric) across web and apps, based on experiment results from Q1/Q2. This includes scaling of the reading list on web (to drive account creation and internal referral rate), activity tab on iOS (for account creation and retention), and a potential longer production analysis of activity tab on Android (already released) to validate feature retention improvements.
  - Key result WE3.9: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for logged-out casual readers in a test environment, monitoring a guardrail appropriate for the feature.
    - In this KR, we will scale successful experiments that have proven to provide a high value to readers, new and lapsed, who do not currently engage with wiki projects. We will scale improvements focused on logged-out reader experiences that support knowledge seeking- content discovery experiences, visual presentations and modalities for sharing (knowledge, content, topics of interest). This KR spans across mobile web and apps platforms (iOS and Android).
  - Key result WE3.10: By the end of Q4, perform at least one experiment per platform (web and apps) that shows a practically significant improvement in logged-out casual reader retention or another indicator metric over control (with casual reader retention defined as 21-day cumulative retention for web, and 14-day cumulative retention for apps).
    - We are continuing our investment in experiments that convey Wikipedia's value to readers, new and lapsed, who do not currently engage with wiki projects. We will look to test improvements to the logged-out reader experience focusing on content discovery (e.g., Minerva TOC, semantic search, Q&A), visual presentations (e.g., visually engaging link cards), and modalities for sharing (e.g., share action). This KR spans web (mobile and desktop, though with an emphasis on mobile due to the audience) and apps (iOS and Android).

Uaminifu na Usalama (WE4)

Lengo: Mifumo yetu inalinda vyema akaunti za wahariri wetu na taarifa za faragha kwa mpangoli, huku ikitoa njia zaidi kwa wahariri na watumiaji walio na haki za ziada za kuzuia na kujibu shughuli za matusi. Jadili
Tokeo kuu la WE4.1: kuweka mfumo wa kuripoti matukio unaowezekana na unaofanya kazi katika wiki zetu zote, ambao unatumiwa na kukubaliwa na jumuiya zao, kufikia mwisho wa Q2.
- Kuhakikisha usalama na ustawi wa mtumiaji ni jukumu la msingi la mfumo wetu. Mamlaka nyingi zina kanuni zinazohitaji mifumo ya mtandaoni kama yetu kufuatilia na kuchukua hatua dhidi ya unyanyasaji, unyanyasaji wa mtandaoni na maudhui mengine hatari kwenye mifumo yao. Kukosa kushughulikia haya kunaweza kuweka mifumo kwenye dhima ya kisheria na vikwazo vya udhibiti.
- Tunataka kuwawezesha watumiaji wetu kuweza kuripoti vitisho mara moja vyenye madhara kupitia utaratibu wa kuripoti unaoweza kugundulika kwa urahisi na angavu ili kuhakikisha kuwa tunaweza kujifunza kuhusu matukio kama haya na kuchukua hatua za haraka inapobidi. Hii ni hatua ya kuwafanya watumiaji wetu kujisikia salama wanapochangia kwenye mfumo wetu. Tunafanya hivi kwa kutekeleza Mfumo wa Kuripoti Matukio kwenye wiki zetu.
Tokeo muhimu WE4.2: Kuimarisha usahihi na ufanisi wa zana za kupambana na unyanyasaji, kwa kupeleka maboresho 2 kufikia mwishoni wa Q2.
- Sisi na jumuiya yetu tunahitaji kutambua vyema na kuzuia shughuli zisizo sahihi na ovu kwenye wiki. Tutafanya hivyo kwa kuongeza idadi na ubora wa ishara zinazopatikana kwenye jukwaa, kwa kuchanganya ishara hizi katika zana tunazotoa kwa watumiaji walio na haki za ziada, na kutambua ni wapi tunaweza kuweka vizuizi vya kiotomatiki kwa shughuli za kutiliwa shaka kwa usalama.
- Pia tunaona fursa za kuboresha ufikivu wa Wikipedia na miradi yetu mingine kwa wakati mmoja. Kwa mfano, mradi mmoja ni kuchukua nafasi ya CAPTCHA ya kawaida ya Wiki inayojisimamia, ambayo humzuia mtumiaji kuingia hadi atakaposuluhisha fumbo, kwa huduma ya alama za hatari ambayo mara chache huwa changamoto kwa mtumiaji. Badala yake, ingeunganisha akaunti kimya kimya na kiwango cha wasiwasi ambacho tunaweza kutumia kuzuia utendakazi, na kufanya hali hii ionekane kwa wasimamizi wenye mamlaka ya juu kusaidia katika kazi zao.
- Kwa ujumla zaidi, miradi ya Wikimedia inategemea sana uzuiaji wa anwani za IP ili kupunguza matumizi mabaya kutoka kwa watendaji wabaya. Hili linazidi kutofanya kazi katika kukomesha matumizi mabaya na kuathiri vibaya watumiaji wa imani nzuri ambao wanaathiriwa na IP na vizuizi vya masafa ya IP. Katika Tokeo Muhimu hili, tunalenga kuboresha uwezo uliopo na kutoa zana mpya zinazowezesha uzuiaji kwa njia sahihi na unaofaa zaidi wa watendaji wabaya, na kupunguza uharibifu wa dhamana unaosababishwa na na IP na vizuizi vya masafa ya IP.
- Ili kupima ufanisi wetu, tutaangalia maoni ya kimaelezo kutoka kwa wafanyakazi wa kujitolea wanaofanya kazi ya kupinga matumizi mabaya, na viashirio vya kiasi kama vile kiwango cha vizuizi vya IP vinavyotumika, kutumiwa kwa sifa ya IP na upunguzaji wa ishara ya kivinjari, kiwango cha mwingiliano unaowezekana na binadamu mtumiaji anapozuiliwa, na kutumiwa kwa ishara mpya katika zana za kupambana na matumizi mabaya.
- Kazi katika KR hii inahusisha ugunduzi na udhibiti ulioboreshwa wa sockpuppet na kupiga marufuku ukwepaji, kuibua taarifa kuhusu uwezekano wa uharibifu wa dhamana, kuimarisha utambuzi wa roboti, kutoa ishara kwa wanaojitolea kupambana na matumizi mabaya, kuboresha utendakazi katika violesura vya kupambana na matumizi mabaya, kuboresha vipimo vinavyoohusiana na matumizi mabaya, na kutoa mapendekezo ya shughuli za akaunti zinazotiliwa shaka kwa uchunguzi kwa watumiaji wa CheckUser.
Tokeo muhimu WE4.3: Kupunguza idadi ya mashambulizi makubwa yanayohitaji uingiliaji kati wa binadamu wa SRE kwa 50% (ikilinganishwa na Mwaka wa Fedha-juu ya-Mwaka wa Fedha), kufikia mwisho wa Q4.
- Mabadiliko ya mandhari ya mtandao, ikiwa ni pamoja na kuongezeka kwa roboti za kiwango kikubwa na mashambulizi ya mara kwa mara zaidi yamefanya mbinu zetu za kijadi za kuzuia matumizi mabaya ya kiwango kikubwa kuwa za kizamani. Mashambulizi kama haya yanaweza kufanya tovuti zetu zisipatikane kwa kujaza miundombinu yetu na maombi, au kuzidi uwezo wa jumuiya yetu kupambana na uharibifu mkubwa. Hili pia linaleta doa lisilo na sababu kwa wahariri wetu wa mapendeleo ya juu na jumuiya yetu ya kiufundi.
- Tunahitaji kwa haraka kuboresha uwezo wetu wa kugundua, kustahimili, na kupunguza au kukomesha mashambulizi kama hayo kiotomatiki.
- Mwaka huu tutaangazia zaidi ugunduzi wa kiotomatiki wa anwani za IP na mitandao ambayo hujihusisha na mashambulizi ya mara kwa mara dhidi yetu, na kupunguza kiasi cha mzigo wa maingizo hatari ya mara kwa mara yanayowekwa kwenye mifumo yetu.
Tokeo muhimu la WE4.4: Kufikia Q2, Akaunti za Muda zitakuwa zimewekwa kwa 100% ya miradi yetu ili uwazi wa taarifa zinazotambulika kibinafsi za wahariri wetu ambao hawajasajiliwa zinapatikana kwa chini ya 0.1% ya watumiaji waliojiandikisha.
- Akaunti za muda zinalenga kuboresha faragha na hivyo basi, usalama wa wahariri wetu ambao hawajasajiliwa kwa kulinda taarifa zao za kibinafsi zinazoweza kuwatambulisha (anwani ya IP) ili zisionekane na umma na kuwawekea vikwazo wale wanaozihitaji kwa madhumuni ya doria pekee. Licha ya kuwa uboreshaji mkubwa wa usalama wa watumiaji, mradi huu pia ni muhimu kwa kuzingatia mahitaji mbalimbali ya udhibiti.
Tokeo muhimu WE4.5: Kutathmini athari za AI zalishi kwenye uaminifu na usalama, na kubainisha uingiliaji kati wa bidhaa ili kuongeza fursa na kuzuia vitisho kwa miradi ya Wikimedia, kufikia mwisho wa Q3..
- Matumizi ya AI na haswa AI ya uzalishaji yanaongezeka kwa kasi kwenye mtandao. Kuna fursa za uaminifu na usalama pamoja na vitisho vinavyoibuka na AI kuwa kila mahali. Kwa mfano, maudhui ni rahisi na ya bei nafuu kuzalisha, lakini kiasi ni ngumu zaidi. Vile vile, utafiti unaweza kufanywa kwa bidii kidogo lakini uongo wa AI ni ngumu kutambua.
- Mradi huu unalenga kuendeleza Tathmini ya Athari za Haki za Binadamu za ML/AI, kwa kutathmini athari za AI kwenye vipengele vya imani na usalama vya mfumo ikolojia wa Wikimedia. Hii ni pamoja na:
  - Kushauriana na watumiaji walio na haki za ziada.
  - Kubainisha mifano ya matumizi mabaya yanayosaidiwa na AI zalilishi na uwezekano wa kuyapunguza.
  - Kutambua fursa za ML ili kupunguza mzigo kwa watumiaji walio na haki za ziada.
  - Kufanya majaribio ili kuelewa kile tunachopaswa kulenga, ili kuleta matokeo zaidi.
Tokeo muhimu WE4.6: Kutekeleza kiufundi kwamba 100% ya haki zinazowezesha watumiaji kuchukua hatua nyeti za usalama au faragha zinaweza tu kufanywa na akaunti ambazo zimewezesha uthibitishaji wa vipengele viwili, kufikia mwisho wa Q4.
- Tunahitaji kuimarisha usalama wa akaunti za watumiaji kwenye wiki zetu, haswa kwa watumiaji walio na ruhusa nyeti. Lengo kuu ni kuhitaji kwamba hatua yoyote nyeti inaweza tu kuchukuliwa na watumiaji ambao wamewezesha uthibitishaji wa vipengele viwili (2FA). Tutaunda mfumo unaopanuliwa zaidi wa utekelezaji wa haki ambao utakwepa hitaji la ukaguzi na utekelezaji wa mwongozo wa 2FA, na kupanua ni mapendeleo gani yanahitaji 2FA kuwezeshwa kwenye jukwaa.
- Kama sehemu ya hili, tutakuwa tukiboresha mifumo yetu ya uthibitishaji na urejeshaji ili sisi (WMF) na watumiaji wetu tuweze kwa urahisi kuunga mkono msimamo mkali zaidi kuhusu 2FA. Tutakuwa tukipanua upatikanaji wa jumla wa uthibitishaji wa vipengele viwili kwenye jukwaa, ili kila mtumiaji aweze kuiwasha anavyotaka na kuhakikisha kuwa imewashwa kabla ya mapendeleo nyeti kutolewa. Pia tutaelekeza fikira zetu katika kupunguza mzigo wa uendeshaji unaobebwa na mifumo yetu ya kurejesha uwezo wa kufikia akaunti na usaidizi, na hivyo kusaidia kurahisisha michakato yetu ya uwekaji upya na urejeshaji inayozunguka kuingia kwa akaunti. Pia tunanuia kuboresha utumiaji wa utekelezaji wetu wa 2FA, ili kuwapa watumiaji chaguo zaidi ili kulinda akaunti zao na kuepuka kufungwa kimakosa.
Key result WE4.7: Publicly conclude our bot detection trial, by the end of Q4.
- This KR is a focused, one-quarter effort to evaluate the results of this trial, to decide inside WMF about whether to maintain and expand this system across our wikis, and to publicly publish the results of the trial and our path forward.
Key result WE4.8: Simplify the patrolling of temporary accounts, by making it quicker to identify and address abuse, by the end of Q4.
- The purpose of temporary accounts is to continue to safely support participation from good-faith unregistered editors. However, some anti-vandalism workflows became more complicated by the release of temporary accounts. To ensure temporary account vandalism can be sustainably managed, we will make it easier and quicker for patrollers to understand and respond to temporary-account activity, both good- and bad-faith.
  We will surface clusters of related temporary accounts to patrollers, while also exploring other interventions that could improve early identification and rapid response.
Key result WE4.9: Empower volunteer investigators to deter and block more inauthentic activity on wikis where they actively review flagged accounts, as measured by a 20% increase in the rate of mitigating actions on those accounts, by the end of Q4.
- For Q3 and Q4, recognizing the strategic potential that Suggested Investigations has demonstrated, we will invest in deploying new signals independent of bot detection, and will set aside time to prioritize a variety of efficiency and quality-of-life features that have been requested by SI users since its original MVP release.
Key result WE4.10: By the end of Q4, we'll increase hCaptcha bot detection coverage from 18% to 100% of account creations and from 18% to 90% of higher risk edits.
- In Q3, we concluded our hCaptcha trial, during which we enabled hCaptcha during account creation, and later expanded it to include new users on the desktop wikitext editor, on eight large Wikipedias, including English Wikipedia. Based on the results of that trial, we’re now expanding hCaptcha to more editing interfaces and more wikis. Our main priority will be expanding what we currently have to all wikis, but we’ll also focus on new avenues to (discussion tools, uploads), as well as categories of users whose actions will be protected by hCaptcha.
Key result WE4.11: By the end of Q4, complete an IRS trial on enwiki with a graduated deployment, reaching at least 50% of logged in users and resulting in 5 new reporting metrics.
- We are trialing an incident reporting system (IRS) on English Wikipedia that is designed to help less experienced community members more easily report potentially bad behavior to the community-managed place that can best deal with it. For more rare and severe cases, it also provides a form to directly report imminent threats of harm to the WMF Trust and Safety team.
- This trial will be primarily focused on calibrating the first use case: helping editors report potentially bad behavior, without overloading the system.
- During the trial, we will focus on monitoring the volume of new reports, checking that reports are routed correctly, and identifying any immediate issues. We will be coordinating closely with all community members to fix bugs if they arise, and to otherwise streamline the process. For example, we are exploring some ways to tighten the user experience and help people more directly submit their reports, which we may deploy and measure during the trial as well.
Key result WE4.12: By end of Q4, we will have defined a detection pipeline for classifiers that automatically detect English Wikipedia policy-prohibited content, and evaluated the impact of at least one classifier detecting at least one type of prohibited content, validated against community datasets, on its potential for reducing volunteer workload.
- We want to support volunteers and UWERs by reducing work needed to remove harmful content from the projects, to enable volunteers to handle more difficult cases.
- In this quarter, we want to gain experience in defining repeatable processes for building detection pipelines for different types of content, and take first steps to evaluate these pipelines safely on large projects (A/B tests, log-only mode deployments, etc). We will start with a focus on content that should very likely be suppressed, such as threats, or disclosure of personal information.
- We plan to expand on these initiatives in FY26-27 work as part of an overhaul of anti-abuse tooling that supports UWERs and volunteers in reducing the time to mitigation for bad-faith activity.

Matumizi ya Kiuwajibikaji ya Miundombinu (WE5)

Lengo: Wasanidi programu na watumiaji tena wanafikia maudhui ya maarifa katika njia zilizoratibiwa, kuhakikisha uthabiti wa miundombinu yetu na utumiaji wa maudhui unaowajibika. Jadili
- Muktadha wa lengo: Lengo hili litazingatia kuanzisha njia za utumiaji wa maudhui unaowajibika.
- Wikimedia huandaa mkusanyiko mkubwa zaidi wa maarifa yaliyoratibiwa na binadamu kwenye wavuti. Hii imefanya miundombinu yetu ya maarifa kuwa kifikio cha thamani sana si kwa wanadamu tu, bali pia kwa watumiaji wa data otomatiki. Maudhui yetu huingia kwenye injini za utafutaji, majukwaa ya mitandao ya kijamii, biashara ya mtandaoni, na tangu kuibuka kwa AI, hutumika kufunza miundo mikubwa ya kujifunza kwa mashine. Wateja huchambua data kwa kurasa za kuchota kurasa, kwa kutumia API, na kupakua maudhui – kwa kawaida bila maelezo. Katika ulimwengu wa trafiki ambayo haijaidhinishwa hatuwezi kutofautisha kwa uhakika mtumiaji mmoja na mwingine, ambayo inapunguza sana uwezo wetu wa kuwezesha na kutekeleza utumiaji unaowajibika wa miundombinu yetu: Je, tunawezaje kuendelea kuwezesha jumuiya yetu, huku pia tukiweka mipaka kuhusu matumizi ya maudhui kiotomatiki? Je, tunawezaje kuelekeza watumiaji kwenye vituo vinavyopendelewa na vinavyotumika? Je, tunahitaji mwongozo gani ili kuhamasisha utumiaji upya wa maudhui kuwajibika? Je, tunawezaje kuelekea kwenye utumiaji wa ushirikiano wa wasanidi programu, na kuunda bidhaa zinazokidhi mahitaji ya wasanidi programu wa kujitolea, wafanyakazi na watumiaji tena kwa pamoja? Ingawa maswali haya yote si mapya, uharaka wa kushughulikia haya umeongezeka kwa kasi: Tangu 2024 tunaona ongezeko kubwa la kiasi cha ombi, huku ongezeko kubwa likitoka kwa kufuta roboti kukusanya data ya mafunzo kwa mtiririko wa kazi na bidhaa zinazoendeshwa na AI. Mzigo kwenye miundombinu yetu si endelevu na unaweka ufikiaji wa maarifa kwa binadamu katika hatari: Tunahitaji kuchukua hatua sasa ili kuweka upya usawa wa afya, ili tuweze kuunga mkono ipasavyo miradi ya Wikimedia na kuwezesha mafanikio endelevu ya dhamira yetu.
  - Tokeo muhimu la WE5.1: Kufikia mwisho wa Q4, 50% ya maombi kwa vituo vya ufikiaji wa programu yanaweza kuhusishwa na msanidi programu au programu tumizi inayojulikana.
    - Kwa sasa tuna njia chache za kutambua ni nani anayehusika na trafiki otomatiki na, tofauti na kwenye wiki, njia chache za kuwasiliana na watumiaji au kudhibiti ufikiaji wao. Tumeona ongezeko kubwa la kiasi cha trafiki ya nje ya kiotomatiki, ambayo si endelevu kwetu na inaweka ufikiaji wa maarifa kwa wanadamu hatarini. Tunalenga kuongeza asilimia ya trafiki otomatiki ambayo inahusishwa na akaunti inayojulikana, kwa kuhitaji uthibitishaji na uidhinishaji kulingana na viwango vya viwango vya ufikiaji kwa uchakachuaji wa sauti ya juu na matumizi ya API. Hili litatusaidia kutambua ni nani anayetumia tena maudhui kwa kiwango, na kutuwezesha kulinda miundombinu yetu na kuboresha utawala kuhusu matumizi ya haki, huku kukidhi mahitaji yao kwa ufanisi zaidi. Pia tutachunguza jinsi ya kuunga mkono vyema jumuiya ya kiufundi kwa kutumia utumiaji wa msanidi wa ushirikiano zaidi ambao hulinda ufikiaji wa mapendeleo kwa wanajamii na kuwezesha utendakazi mpya kwa wasanidi programu.
  - Tokeo kuu la WE5.2: Mwishoni mwa Q4, 70% ya vidokezo vya API ya mtandao wa Wikimedia vitasaidiwa na miundombinu ya pamoja.
    - Tunalenga kuboresha uzoefu na uendelevu wa njia zetu za wasanidi programu kwa kutoa API za wavuti thabiti, thabiti na zinazoweza kugundulika kwa wasanidi wote wa Wikimedia. Tutarahisisha matoleo yetu ya API kwa kuanzisha miundo msingi zaidi kwa uwezo mkuu wa API, kuturuhusu kuwa na njia na utawala thabiti kwa: Vipimo vya OpenAPI na uwekaji hati, utambuaji wa msanidi programu na vidhibiti vya ufikiaji, utekelezaji wa sera ya API, uelekezaji, matoleo na kushughulikia makosa. Kwa kurahisisha matoleo yetu ya API, tutaifanya iwe haraka, rahisi na ya kupendeza zaidi kuunda zana, roboti, miradi ya utafiti na vipengele vinavyotumikia dhamira ya Wikimedia. Mbinu hii inasaidia mustakabali wa dhamira ya vizazi vingi kwa kupunguza gharama za matengenezo ya miundombinu ya API, kuongeza mwonekano na udhibiti wa ufikiaji wa kupambana na watendaji wabaya, na kukuza jumuiya yenye nguvu ya wasanidi programu.
  - Tokeo muhimu la WE5.3: Kufikia mwisho wa Q4, mfumo mpya wa ugawaji sifa kwa ajili ya wavuti, programu tumizi, visaidizi vya sauti, na LLM utachapishwa na kuunganishwa kwenye tovuti zote za Wikimedia, huku maonyesho mawili ya utumiaji tena yakitolewa ambayo yatafanya ushiriki upimike, na mshirika mmoja wa nje wa utumiaji wa kurudia atapitisha ugawaji sifa wa mbinu bora.
    - Ili kuongeza maelezo yanayofaa ya maudhui ya Wikimedia, tutatoa mwongozo wazi wa utendaji bora ambao unakuza utumiaji wa tena na tena unaowajibika. Hii ni pamoja na kuunda mfumo wa maelezo kwa majukwaa muhimu (wavuti, programu tumizi, sauti, mediatutiko) na kuonyesha angalau mifano miwili ya vitendo inayoangazia utumizi wa mfano wa maudhui ya Wikimedia. Mifano ya matokeo ni pamoja na kuhimiza mashirika ya vyombo vya habari kutoa mikopo kwa picha za Wikimedia Commons, injini za utafutaji ili kuwasilisha data muhimu za Wikimedia kwa ufanisi zaidi, au visaidizi vya AI ili kuunganisha maarifa ya Wikipedia kwa njia za uwazi na za uwajibikaji zinazoongeza uaminifu katika kutegemewa kwao. Kuimarisha mbinu za uwasilishaji sio tu huongeza ufahamu wa umma na kurudisha ushiriki kwenye miradi ya Wikimedia, lakini pia husaidia kuanzisha njia zinazowajibika na mpya za kuchanganya maarifa, na kuzuia matumizi mabaya.
  - Tokeo muhimu WE5.4: Kupunguza kiasi cha trafiki kinachozalishwa na wachotaji wa taarifa kwa 20% inapopimwa kulingana na kiwango cha ombi, na kwa 30% kwa suala la kipimo data
    - Kuchakachua kumekuwa hapa kila wakati: injini za utaftaji zimetegemea Wikipedia kutoa habari kwa watumiaji wao kwa miongo kadhaa; hata hivyo hivi majuzi kuna motisha nyingine kubwa ya kuchambua data yetu: ndiyo seti kubwa zaidi ya maarifa iliyoratibiwa, ya lugha nyingi unayoweza kupata kwenye mtandao na ni zana ya kimsingi ya kufunza miundo mikubwa ya lugha. Hii ni kweli kwa maudhui yetu ya ensaiklopidia na hazina yetu ya media mbalimbali, Wikimedia Commons, ambayo ni muhimu sana kwa miundo ya mashine jifunzaji kujifunza modeli ambazo huzalisha picha.
    - Kwa hivyo, kwa mwaka uliopita, tuliona ongezeko kubwa la kiasi cha trafiki cha wachota taarifa, na pia matukio yanayohusiana ya uthabiti wa tovuti: Wahandisi wa utegemezi wa tovuti wamelazimika kutekeleza maamuzi ya jambo moja baada ya lingine mara kwa mara kuweka vikwazo au kupiga marufuku wachotaji taarifa ili kulinda miundombinu yetu. Uchakachuaji umekuwa maarufu sana hivi kwamba kipimo data chetu kinachotoka kimeongezeka kwa 50% mwaka wa 2024. Zaidi ya hayo, uchanganuzi wa hivi majuzi ulionyesha kuwa angalau 65% ya maombi yetu ya bei ghali zaidi (yale ambayo hatuwezi kutoa kutoka kwa seva zetu za akiba na ambayo hutolewa kutoka kwa hifadhidata kuu badala yake) hufanywa na roboti.
    - Rasilimali zetu za kompyuta ni chache sana ikilinganishwa na idadi ya trafiki tunayotengeneza, kwa hivyo inatupasa kuwapa kipaumbele wale tunaowahudumia kwa rasilimali hizo, na tunataka kupendelea matumizi ya binadamu, na kuweka kipaumbele kusaidia miradi ya Wikimedia na wachangiaji kwa rasilimali zetu chache.

Kuharakisha Njia ya kupata Matokeo ya Bidhaa (WE6)

Lengo: Wasanidi wa Wikimedia hupeleka bidhaa zao kwa watumiaji wa mwisho kwa haraka na kwa uhakika. Jadili
- Tafsiri:Mpango wa Mwaka wa Shirika la Wikimedia Foundation/2025-2026/Bidhaa na Teknolojia OKRs/182/sw

Muktadha wa lengo: Ili kuwa na ufanisi katika kufikia nguzo 4 za kimkakati, wasanidi wa Wikimedia wanahitaji kutumia muda na juhudi zao katika shughuli za kiwango cha juu zinazosababisha kuwasilisha bidhaa bora mapema iwezekanavyo. Utiririshaji mgumu sana, ukosefu wa zana za kawaida, na vipengee vya mfumo visivyo endelevu huzuia matokeo hayo.

- Kazi hii inaendelea kutokana na kasi ambayo tumechukua mipango 2 iliyopita ya kila mwaka inayoendeleza MediaWiki kama jukwaa na programu inayosaidia uundaji na utumiaji wake. Kazi ya mwaka huu italenga kutoa mazingira ya kuaminika zaidi ya wasanidi programu, kurahisisha utendakazi wa kabla ya utayarishaji, na kupunguza hatari za jukwaa na miundombinu.
  - Tokeo kuu la WE6.1: Mwishoni mwa Q4, idadi ya vizuizi vya hitilafu ambazo hutokea zaidi ya majaribio ya tovuti za wiki za majaribio kupunguzwa kwa 10%
    - Mnamo 2024, kulikuwa na mara 144 ambazo wasanidi programu walilazimika kurejea kazini kwa sababu kulikuwa na dharura iliyozuia kusimikwa kwenye MediaWiki. Katika mengi ya matukio hayo, hitilafu zilinaswa baada ya kutumwa kwa wiki za majaribio, kumaanisha kuwa suala hilo lilifikia hadhira inayoweza kuwa ya mabilioni ya watumiaji. Hatuwezi kudhibiti ukweli kwamba hitilafu zitakuwepo, lakini kuzipata mapema kunaweza kumaanisha kuwa kazi ndogo ya shujaa inahitajika. Pia itajenga imani kwa wasanidi programu kwamba kitu kinapoenda kwa uzalishaji halisi, hakutakuwa na moto.
    - Tutakamata hitilafu hizi mapema kwa kutoa mazingira yanayohitajika na wasanidi programu ili kuwasilisha na kujaribu misimbo yao kwa ujasiri katika kipindi chote cha utayarishaji na usambazaji. Tunahitaji pia kuhakikisha kuwa maboresho haya hayaji kwa gharama ya kasi ya msanidi programu.
  - Tokeo muhimu WE6.2: Kufikia mwisho wa Q4, hatua 4 kutoka kwenye orodha ya ukaguzi ya utayari wa uzalishaji zinaweza kutekelezwa bila uingiliaji wa SRE
    - Kupata huduma au kipengele kipya kilichotolewa katika toleo la umma kwa sasa kunategemea orodha ya hatua 24 ambazo kwa kawaida kila hatua huhitaji usaidizi kutoka kwa SRE. Tulianzisha mpango wa balozi wa SRE ili kuingilia kati mapema mzunguko wa maendeleo na kujenga uwezo ndani ya timu za maendeleo zenyewe, lakini majukumu mengi yanapaswa kuwa ya kujitegemea kabisa. Hivi sasa, hii ni sawa na kazi ambayo ni ya mwongozo, inayorudiwa, inayoweza kuendeshwa kiotomatiki, na ambayo inalingana na idadi ya timu za maendeleo. Hii si endelevu kwa timu ya SRE kwa muda mrefu.
    - Hapo awali, sehemu kubwa ya kazi hii iliondolewa kutoka kwa timu za maendeleo kwa kudumisha seti ya maktaba zinazoshirikiwa pamoja na mbinu bora za kuingiliana na mfumo wetu. Hizi ziliachwa tulipohamia kwenye miundombinu yetu mpya ya Kubernetes na hatuna mbadala wa moja kwa moja. Kwa kutoa maktaba, hati na mafunzo sawa ambayo yanatumika kwa jinsi tunavyounda na kusambaza vitu leo, tunaamini kuwa tunaweza kupunguza kiwango cha uhusika kinachohitajika kutoka kwa SRE kabla ya kupeleka huduma au kipengele kipya kwenye uzalishaji.
  - Tokeo muhimu WE6.3: Hadi mwisho wa Q4, 100% ya maoni ya ukurasa wa Wikipedia yanatolewa kupitia Parsoid
    - Parsoid inatoa uwezo ulioimarishwa wa mageuzi ya maandishi ya wiki na uthibitisho wa siku zijazo wa jukwaa. Kudumisha vichanganuzi viwili kwa wakati mmoja si endelevu kwa muda mrefu, kwani huongeza deni la kiufundi na ugumu. Zaidi ya hayo, mafanikio ya baadhi ya miradi mipya kama vile Wikifunctions inategemea Parsoid kupatikana kwa wingi.
    - Tumekuwa tukiongeza usambazaji kwenye miradi midogo na mwaka huu tutakuwa tayari kwa Wikipedia. Kutumikia mwonekano wote wa ukurasa wa Wikipedia unaosomwa kupitia Parsoid ni hatua muhimu zaidi inayofuata. Kando na uchapishaji wenyewe, kazi hii pia inajumuisha kusuluhisha masuala ya utendakazi na kuwasiliana vyema kuhusu athari kwa wasomaji na wahariri.
  - Tokeo kuu la WE6.4: Kufikia mwisho wa Q2, angalau hatari mbili zilizotambuliwa ambazo zinatishia uwezo wetu wa kuendelea kusambaza au kuongeza wiki zimedhibitiwa au kupunguzwa hadi kiwango kinachokubalika
    - Kupitia mipango michache inayolengwa, tutathibiti au kupunguza hatari kadhaa za kuongezeka, kutegemewa au usalama ambazo tumetambua kuwa tishio linalowezekana kwa ukuaji na uendelevu wa jukwaa letu na miradi yetu ya umma.
    - Kwa mfano, tutakuwa tukibadilisha muundo wa hifadhidata za msingi za Commons ili kuhakikisha ukuaji wake hautazuiliwa na uwezo wa maunzi ya seva yanayopatikana ndani ya miaka michache ijayo. Pia tutasasisha PHP, lugha ya programu inayowezesha MediaWiki na huduma zinazohusiana, hadi toleo la kisasa zaidi. Hatari nyingine zilizotambuliwa huenda zikahitaji kutekeleza hatua za ziada za usalama ili kulinda na kuimarisha miundombinu yetu.
  - Key result WE6.5: By the end of Q4, determine the feasibility of and next steps for scalable cross-wiki code collaboration and logged-in reader support.
    - One of the central features of wikis is collaborative content creation. In the context of the Wikimedia movement, the collaboration needs are very specific to the evolution of the projects and the challenges that arise at the scales that some of the larger projects operate in.
    - Code collaboration (cross-wiki or on-wiki) is a legitimate need and should be accommodated. This is less a single problem and more a problem space that includes several overlapping problems around code (templates & modules primarily) and solving problems in this space requires shared understanding around priorities that are most impactful.
    - With an experimentation mindset, we're exploring a leaner approach to test shared code libraries that could improve cross-wiki collaboration in a small and controlled environment. This means we will go through a phase of technical feasibility and scope exploration to approach the experiment roll-out in small iterations to collect insights that can help us decide how we want to tackle the aforementioned problem. Our intention is to demonstrate our learnings and progress in the Wikimedia Hackathon 2026.
    - Similarly, if we want to improve the experience of logged-in users, we need to know where the performance gains are, what product work will make demands, and what a sustainable approach will look like for this work next FY. Research in this area will set us up for starting platform work quickly next FY.
  - Key result WE6.6: By end of Q4, developers are able to get the results of MediaWiki Core CI in under 10 minutes.
    - Our current median CI cycle time baseline is over 24 minutes while a DevEx industry standard for high performing teams is 10 minutes or less.
    - To bridge this gap, we're planning to optimize the CI workflows, address main bottlenecks such us browser tests by optimizing how we run them, the underlying testing framework and its configuration.
    - By slashing median CI wait times from 24 to 10 minutes we ensure the rapid feedback loop needed to test and fix issues quickly, significantly accelerating iteration speed. Additionally, improving this metric speeds up merge times, shortening the time between a change being ready and being available for deployment, which directly contributes to the top-level OW5 metric of making it "easier and faster to build products".
  - Key result WE6.7: By end of Q1 of 2026-27 fiscal year, developers are able to test MediaWiki code in production within 1 day of it being merged.
    - Currently, on average developers can test their code on production ~4 days after merging. By shrinking this time, developers can test sooner, and by improving test environments they will have more confidence that their tests will result in fewer bugs reaching production.

Ishara na Huduma za Data (SDS)

Vipimo (SDS1)

Lengo: Watoa maamuzi hutumia zaidi vipimo tegemewa na vya wakati ili kufahamisha bidhaa na maamuzi ya kimkakati. Jadili
- Muktadha wa lengo: Tunatumia vipimo kufanya maamuzi ya Shirika kuhusu mahali pa kuelekeza juhudi zetu ili kuhudumia harakati vyema zaidi. Hata hivyo, baadhi ya mabomba yetu ya data yana uwezekano wa kukatika, hivyo kusababisha ucheleweshaji wa utoaji. Matatizo ya data yanapojitokeza, wakati wetu wa kutambua na kusuluhisha huwa juu sana. Kwa kuongezea, hifadhidata zetu nyingi hazijaboreshwa kwa uchunguzi rahisi wa mitindo na zinakosa vipimo ambavyo vimejitokeza kuwa muhimu kwa kutafsiri data. Matatizo haya hupunguza kasi na kupunguza uwezo wetu wa kutathmini vipimo.
- Katika FY25-26, tutaangazia kesi mahususi za utumiaji wa mpango wa kila mwaka kwa ajili ya kusuluhisha mapengo ya ubora wa data katika mabomba yetu ya sasa, kuweka miundombinu na michakato ya ufuatiliaji na kutatua masuala ya ubora wa data, na kutoa zana zinazowawezesha watoa maamuzi kuelewa mienendo.
- Mfano mmoja kuhusu utumiaji ni kuhusu jinsi tunavyopima trafiki ya binadamu na roboti. Kuongezeka kwa trafiki otomatiki katika miaka michache iliyopita kumefanya iwe vigumu kuelewa ni kwa kiasi gani wanadamu wanatangamana na kuchangia miradi ya Wikimedia. Tunalenga kuboresha uwezo wetu wa kutathmini mifumo ya trafiki ya binadamu na roboti, ambayo ni nyenzo muhimu kwa kupanga na maamuzi ya bidhaa.
  - Tokeo muhimu la SDS1.1: Kufikia mwisho wa Q1, wachambuzi wanaotumia vipimo vya kutazamwa kwa ukurasa wanaweza kufikia hatua za kimsingi za ubora wa data na vipimo vya utendaji wa mbinu elekezi za kiotomatiki za kugundua trafiki.
    - Kupitia dhana zilizogunduliwa katika KR hii, tunalenga kutambua mapungufu katika mbinu zetu za sasa za ugunduzi wa kiotomatiki wa trafiki na kuelewa pale zinaposhindwa kuainisha vizuri trafiki ya kutazama ukurasa. Maarifa haya yataarifu uboreshaji wa njia zinazozalisha na kuainisha vipimo vya mwonekano wa kurasa. Zaidi ya hayo, tutafafanua vipimo vya ubora wa data ili kufuatilia na kupima uboreshaji wa usahihi wa data.
    - KR hii itaweka msingi wa ufuatiliaji wa KR unaolenga kutekeleza uboreshaji wa mambo yaliyobainishwa hapa. Vipimo vya ubora wa data vilivyoanzishwa katika awamu hii vitatumika kama vigezo vya kutathmini ufanisi wa maboresho hayo ya siku zijazo.
  - Tokeo muhimu la SDS1.2: Mwishoni mwa Q1, maudhui ya seti ya data ya historia ya maudhui ya mediawiki yatapatikana kupitia uhamishaji wa faili kwa dhamana ya uwasilishaji ya kila wiki (SLOs). Data ya faili iliyohamishwa itakuwa na usawa ikilinganishwa na bomba la usafirishaji la XML Dumps 1.
    - Lengo la FY24/25 KR 1.4 limekuwa kuondoa utegemezi wa seti za data za mediawiki_wikitext_history zilizosasishwa kila mwezi na mediawiki_wikitext_history_current seti za data kwa mabomba 3 muhimu zaidi ya mkondo wa data na kutoa seti mbadala ya data iliyo na SLO za kila wiki zenye uhakika.
    - Ingawa FY24/25 KR 1.4 ilisaidia kupunguza masuala ya kutegemewa kwa mabomba tegemezi muhimu zaidi, kuna mabomba yaliyosalia na chanzo kisichotegemewa cha ingizo la urithi. Hizi zinapaswa kuhamishwa pia na chanzo cha ingizo cha faili kwenye data ya historia ya maandishi ya wiki iliyowekwa yenyewe.
  - Tokeo muhimu SDS1.3: Mwisho wa Q2, ugunduzi wa roboti hujumuisha ishara 1 ya ziada na hutoa tahadhari otomatiki kwa hitilafu.
    - Kote katika Shirika, timu zinafanya maamuzi ya bidhaa na ufadhili kulingana na uwezo wa kubainisha tofauti kati ya usomaji wa kibinadamu na nyendo za kiotomatiki. Jukwaa la Data ndio hazina kuu ya ishara za ugunduzi wa roboti na uchanganuzi wa bechi. Kupitia dhahania ambazo tumekagua kupitia Q1/Q2, tunapanga kuanza kutambulisha ishara mpya za ugunduzi wa roboti kuimarisha uchanganuzi wetu wa nyendo za otomatiki, na kuanza kufanya mchakato wa kutambulisha ishara mpya kwa ufanisi na kurudiwa.
  - Tokeo muhimu la SDS1.4: Mwisho wa Q2, watoa maamuzi wana uelewa wazi wa hali ya sasa ya maarifa inayotolewa na vipimo vya shirika letu. Tutajua kuwa tumefaulu ikiwa tutatoa uwasilishaji wa mkutano wa bodi ambao utajumuisha uchanganuzi wa vipimo vyetu ndani ya mfumo ikolojia wa Wikimedia, na pia katika mwelekeo mpana wa mtandao na changamoto katika soko.
    - Maarifa kutoka kwa vipimo vya shirika letu hutumika kufanya maamuzi mengi katika shirika, ikijumuisha maamuzi kuhusu jinsi tunavyounda bidhaa zetu, jinsi tunavyogawa rasilimali za miundombinu na jinsi tunavyochangisha pesa. Wakati huo huo, mazingira ya mtandao yanabadilika, huku nyendo za kiotomatiki zikiathiri vipimo vyetu. Lengo ni kwa uongozi wa Shirika kuingia katika mkutano wa bodi ya Desemba na maelezo ya wazi kuhusu vitisho na fursa ndani ya mfumo wa ikolojia wa Wikimedia unaoungwa mkono na uchanganuzi wa uhakika wa vipimo vya ndani na mitindo ya nje. Tunaweza kusimulia hadithi hii kwa kukusanya maarifa, vipimo na vidokezo vya data ambavyo hutuambia kwa uhakika kuhusu:
      - Mitindo katika hatua zetu za ndani za usomaji (utazamaji wa kurasa)
      - Mitindo ya mfumo wetu wa ikolojia wa wachangiaji
      - Mitindo kutoka kwa data za nje na vigezo vya mshindani
      - Maarifa kutoka kwa tafiti za ndani na nje na utafiti unaoaminika
  - Key result SDS1.5: By the end of FY25-26 Q4, analytics bot detection will incorporate 2 signals calibrated against 1 trusted classification.
    - In Q1/Q2, SDS1.3 addressed the big gap in incident detection time and analyzed additional signals for bot detection. We learned that:
      - Modern and feasible signals come with a number of caveats and uncertainties that need to be expressed in our metrics.
      - Evaluating the quality of our model, as well as doing robust analysis of signals to enable future iteration, will require labeled data, trusted by definition and preferably sourced from independent systems (formerly called “ground truths”).

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

- - - In Q3/Q4, we will follow that with three main deliverables:

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

Jukwaa la Majaribio (SDS2)

Lengo: Wasimamizi wa bidhaa wanaweza kutathmini kwa haraka, kwa urahisi na kwa uhakika athari za mabadiliko ya kipengele cha bidhaa katika Wikipedia. Jadili
- Muktadha wa lengo: Ili kuwezesha na kuharakisha kufanya maamuzi kwa ufahamu wa data kuhusu uundaji wa vipengele vya bidhaa, wasimamizi wa bidhaa wanahitaji jukwaa la majaribio ambapo wanaweza kufafanua vipengele, kuchagua hadhira ya kimatibabu ya watumiaji, na kuona vipimo vya athari. Kuharakisha muda kutoka kwenye uzinduzi hadi uchanganuzi ni muhimu, kwani kufupisha ratiba ya kujifunza kutaharakisha majaribio, na hatimaye, uvumbuzi. Kazi za mwongozo na mbinu zilizopangwa za kipimo zimetambuliwa kama vizuizi vya kasi. Hali inayofaa ni kwamba wasimamizi wa bidhaa wanaweza kupata kutoka kwa uzinduzi wa majaribio hadi ugunduzi kwa uingiliaji mdogo au bila uingiliaji wa mikono kutoka kwa wahandisi na wachambuzi.
- Tunaangazia Wikipedia kwa mwaka ujao wa fedha kwa sababu hapo ndipo Uzoefu wa Msingi una nia ya majaribio (mkakati wa shirika unatufanya tuongezeke maradufu kwenye Wikipedia), na kwa sababu huturuhusu kuangazia na kuashiria kwa uwazi zaidi timu na miradi gani tunashirikiana nayo. Timu nyingine zimetumia vipengele vya mfumo wa majaribio na huenda zikaendelea kufanya hivyo, lakini matumizi hayo hayatakuwa kipaumbele katika lengo hili.
  - Tokeo kuu la SDS2.1: Kufikia mwisho wa Q2, kuwezesha kukamilika kwa angalau mizunguko 2 kamili ya majaribio kwa kutumia jukwaa la majaribio.
    - Kadiri shirika linavyozidi kusisitiza maamuzi ya bidhaa yenye kuzingatia data, ni lazima tufanye majaribio yaweze kufikiwa na timu zote za bidhaa, sio tu zile zilizo na ujuzi maalum. Timu za Bidhaa zinahitaji viwango vya pamoja, zana na miundombinu inayoziwezesha:
      - Kujaribu mawazo kwa haraka kwa watumiaji wetu wa kimataifa
      - Kupima athari za mabadiliko ya bidhaa kwa kutumia vipimo vilivyosanifiwa
      - Kushirikishana matokeo kwa uwazi na wadau wetu wa Harakati
    - Kwa nini tunahama kutoka kuangazia idadi ya "timu zilizowezeshwa" hadi "majaribio yaliyokamilika":
    1. Upangaji wa kimkakati: Ni kipimo kikuu cha mafanikio cha jukwaa
    2. Mbinu iliyozingatia data: Utafiti wetu wa watumiaji (unaendelea) unapendekeza utayari wa timu tofauti katika shirika lote, ilhali tunajua kuwa timu ya Wavuti imethibitisha kupendezwa na majaribio mawili mahususi.
    3. Uboreshaji wa rasilimali: Utoaji wa jukwaa letu la MVP utahitaji uboreshaji wa hali ya juu, na kulifanya liwe na ufanisi zaidi katika muda mfupi ujao ili kuzingatia fursa za majaribio badala ya kutuma wavu mpana kwenye timu nyingi. Tunapanga kusonga mbele kuelekea toleo la jumla na hatutaki kuwekeza tena katika timu za mazoezi tena, ikiwa tutaweza kuepuka hilo.
    4. Mazingatio ya Wakati ujao: Maoni kutoka kwenye mzunguko kamili wa majaribio yataarifu uboreshaji wa jukwaa letu kwa ufanisi zaidi kuliko kujifunza kutoka kwenye mapokeo nusunusu au yasiyokamilika. Tunapojikita katika majaribio yaliyo kamili kunasaidia kuepuka kuwekeza katika mbinu za muda ambazo zitahitaji kutengenezwa upya.
    - Tuna utafiti wa watumiaji unaoendelea ili kuvuta mahitaji ya timu mbalimbali: utafiti na mahojiano yanaratibiwa ili kuongeza uwazi kwa mahitaji ya timu ya bidhaa katika nusu ya pili ya Mei 2025. Baada ya utafiti huo kukamilika, tutafanya kalenda ya majaribio ambayo inaweza kutumika kuweka malengo yetu ya KR yanayofuata na vipaumbele.
  - Key result SDS2.2: Before the end of Q3, results for at least one web experiment can be analyzed and viewed in GrowthBook.
    - After a long and arduous process, we finally made a decision to integrate GrowthBook as a third-party experimentation solution that offers experiment flagging, automated analysis, and dashboarding, with support for guardrail metrics. Experiment Platform intends to replace the UI to define and deploy experiments (1) and the experiment analytics pipeline (5) with GrowthBook.
    - Because of the risks associated with this integration, the Experiment Platform Team believes that GrowthBook should be integrated as an experiment analytics pipeline first because it's non-disruptive and because it's the greatest source of risk.
    - The architectural decisions we made during FY24/25 SDS2 and GrowthBook’s modularity allow us to replace parts of the Experimentation Lab out of order, i.e. WMF staff can define and deploy experiments with xLab UI while analyzing them with GrowthBook. Further, we can run the current experiment analytics pipeline and GrowthBook’s in parallel, which allows for side-by-side comparisons as well as User Acceptance Testing in real-world scenarios.
  - Key result SDS2.3: By the end of Q4, all new Test Kitchen experiments are configured in GrowthBook.
    - After having enabled WMF staff to use GrowthBook for analyzing experiment results, the Experiment Platform team held a design sprint to assess options for experiment configuration. The decision was to use GrowthBook as the source of truth for experiment configuration but keep Test Kitchen UI (TKUI) as the source of truth for instrument configuration.
      In making GrowthBook the source of truth for experiment configuration, we aim to:
      - Reduce coordination when running an experiment
      - Enable more frequent and repeatable experimentation
      - Clearly delineate between instruments and experiments
      - Move toward a mental model centered on metrics rather than instruments
  - Key result SDS2.4: At least 14 out of 20 product teams have used Test Kitchen to inform a strategic decision for an OKR initiative, by the end of Q4.
    - The work done under SDS2.1 revealed a critical insight: building an experiment platform is not enough — Product & Tech teams face some barriers to adoption. Even though teams see value, they often lack time, infrastructure, instrumentation, or confidence to begin. In addition to this, they may encounter technical blockers that will need to be addressed by thoughtful partnership.
    - KR SDS2.4 shifts our focus from building to scaling adoption. By continuing to partner with teams as they onboard onto the platform, overcoming technical barriers and providing hands-on migration support, we aim to consolidate experimentation onto Test Kitchen as the unified platform for product teams, enabling fast, self-service testing cycles that reduce dependence on engineering and analytics support.
    - This KR was planned after we decided to split SDS2.2 in two pieces of work, which is why the numbering was affected. SDS2.3 is an upcoming KR that is sequential to GrowthBook for Experiment Analytics.

Hadhira za Baadaye (FA)

Hadhira za Baadaye (FA1)

Lengo: Shirika la Wikimedia Foundation limetayarishwa na mapendekezo kuhusu uwekezaji wa kimkakati wa kufuata ili kusaidia harakati zetu kuhudumia hadhira mpya katika mtandao unaobadilika. Jadili
- Muktadha wa lengo: Kutokana na mabadiliko yanayoendelea katika teknolojia na tabia ya mtumiaji mtandaoni (k.m., kuongeza kwa upendeleo wa kupata ujuzi kupitia programu za kijamii, umaarufu wa uboreshaji wa video fupi, kuongezeka kwa AI ya uzalishaji), harakati za Wikimedia zinakabiliwa na changamoto katika kuvutia na kuhifadhi wasomaji na wachangiaji. Mabadiliko haya pia huleta fursa za kuhudumia hadhira mpya kwa kuunda na kutoa taarifa kwa njia mpya. Hata hivyo, sisi kama harakati hatuna picha wazi iliyo na data ya manufaa na mabadiliko ya mikakati tofauti tunayoweza kufuata ili kushinda changamoto au kuchangamkia fursa mpya. Kwa mfano, tunapaswa...
  - Je, ungependa kuwekeza katika vipengele vipya vikubwa kama vile vikaragosi(chatbots?)
  - Je, ungependa kupeleka maarifa na njia za Wikimedia za kuchangia kwenye majukwaa maarufu ya watu wengine?
  - Kitu kingine?
- Ili kuhakikisha kuwa Wikimedia inakuwa mradi wa vizazi vingi, tutajaribu dhahania ili kuelewa vyema na kupendekeza mikakati yenye mwelekeo chanya - kwa Shirika la Wikimedia Foundation na harakati za Wikimedia - kufuata ili kuvutia na kuhifadhi hadhira ya siku zijazo.
  - Tokeo muhimu FA1.1: Kutokana na maarifa na mapendekezo ya majaribio ya Hadhira ya Baadaye, kufikia mwisho wa Q3 angalau lengo moja au tokeo moja kuu linalomilikiwa na timu ya Wasio na mtazamo wa siku zijazo litakuwepo katika rasimu ya mpango wa mwaka unaofuata.
    - Tangu 2020, Shirika la Wikimedia Foundation limekuwa likifuatilia mitindo ya nje ambayo inaweza kuathiri uwezo wetu wa kuhudumia vizazi vijavyo vya watumiaji-maarifa na wachangiaji-maarifa na kubaki kuwa harakati ya maarifa bila malipo kwa vizazi vijavyo. Hadhira ya baadaye, timu ndogo ya R&D, ita:
      - Kufanya majaribio ya haraka na ya muda (yakilenga angalau majaribio 3 kwa mwaka wa fedha) ili kuchunguza njia za kushughulikia mienendo hii.
      - Kulingana na maarifa kutoka kwenye majaribio, toa mapendekezo kwa uwekezaji mpya usio wa majaribio ambao WMF inapaswa kufuata - yaani, bidhaa au programu mpya zinazohitaji kutekelezwa na timu kamili au timu - katika kipindi chetu cha kawaida cha kupanga kila mwaka.
    - Matokeo haya muhimu yatatimizwa ikiwa angalau lengo moja au matokeo muhimu ambayo yanamilikiwa na timu nje ya Hadhira ya Baadaye na yanaendeshwa na pendekezo la Hadhira ya Baadaye yataonekana katika rasimu ya mpango wa kila mwaka wa mwaka wa fedha unaofuata.

Video ya kijamii (FA2)

Lengo: Vijana (<25-umri wa miaka) watu wanapenda, kujifunza kutoka kwenye majukwaa, kujihusisha na, na kushirikisha maudhui ya Wikipedia kwenye majukwaa ambapo wanapenda kutumia muda mtandaoni. Jadili
- Muktadha wa Malengo: Majaribio ya Hadhira ya Baadaye ya video fupi mwaka huu wa fedha yameonyesha kuwa tunaweza kufikia hadhira changa kwa kiwango kikubwa kwenye mifumo hii, lakini data yetu ya Afya ya Biashara inaonyesha kuwa uwekezaji wetu wa sasa hautoshi kukabiliana na kupungua kwa ufahamu na uhusiano na Wikipedia kati ya hadhira ya Gen-Z.
- Ili kuhakikisha kwamba tunakifikia na kushirikisha kizazi hiki ipasavyo, tunaamini kwamba tutahitaji kujihusisha katika mbinu mbalimbali, na kuongeza kwa kiasi kikubwa ushiriki wetu katika maeneo kama vile masoko na ushawishi wa kulipia, kampeni za ubunifu, kuitikia mitindo na kuongeza kiwango chetu cha majaribio kwenye njia hizi.
- Tunatarajia kuwa changamoto tunazokabiliana nazo zitahitaji uwekezaji mkubwa zaidi ili kutusaidia kuzishinda, hasa katika juhudi za Mawasiliano na Masoko ili kuanzisha ushirikiano, pamoja na ushirikiano wa idara mbalimbali katika kuunda bidhaa na uzoefu mpya unaolenga kuongeza uwepo wa chapa na maudhui ya Wikipedia kwenye mifumo hii.
  - Tokeo kuu la FA2.1: Kufikisha watazamaji 9,500,000 kutoka kwa maudhui ya video ya muda mfupi katika chaneli zote zinazoomilikiwa kufikia mwisho wa H1.
    - Mwaka huu, tulifikisha takriban maoni milioni 1 ndani ya miezi 3 ya kuzindua video fupi kwenye chaneli za @Wikipedia kwenye TikTok, Instagram na YouTube. Kufikia mwanzoni mwa mwaka ujao wa fedha, tunatarajia wafuasi zaidi kwenye chaneli zetu tunazomiliki na maarifa zaidi kuhusu maudhui bora/ya kuvutia ambayo tunaweza kutekeleza ili kufikia watazamaji wengi zaidi.
    - Kwa kuweka lengo kuu katika nusu ya kwanza ya mwaka, tunatumai kuelekea kwenye matokeo makubwa zaidi, kuruhusu uundaji wa mikakati/taratibu mpya ili kuwezesha kazi, na kuwa na uwezo wa kutetea rasilimali za ziada ili kufikia lengo hili.
  - Tokeo muhimu la FA2.2: Kuongeza ufuasi nje ya jukwaa letu kwenye TikTok kutoka Ngazi ya Kati (wafuasi 100k–250k) hadi kiwango Kikubwa (wafuasi 250k–1M) kufikia mwisho wa Mwaka wa Fedha 25/26 (Juni 2026).
    - Kwa sasa tuko katika Kiwango cha Kati cha ufuasi wa TikTok (wafuasi 100k–250k), na lengo letu ni kufikia kiwango Kikubwa (wafuasi 250k–1M) kufikia mwisho wa Mwaka wa Fedha 25/26 (Juni 2026). Viwango hivi—Vidogo, Kati, na Vikubwa—ni alama za kawaida katika tasnia kwa ukubwa na ufikiaji wa watazamaji. Ili kufika huko, tutaboresha mkakati wetu wa maudhui ili kuvutia zaidi wafuasi wa Gen Z na kuongeza mwonekano wetu kwa ujumla kupitia usimamizi wa jumuiya. Utendaji wa H1 utaarifu marekebisho ya mbinu katika H2 ili kuharakisha ukuaji na kufikia hatua hii muhimu.
  - Tokeo muhimu FA2.3: Kuzindua bidhaa nje ya jukwaa inayolenga watazamaji wa siku zijazo' mbinu mpya za kujifunza/matumizi ya vyombo vya habari na kuileta sokoni kupitia kampeni ya uwekaji chapa ya bidhaa na masoko.
    - Hadhira ya Baadaye kwa kawaida hufanya kazi kwenye majaribio ya kiwango kidogo na uuzaji mdogo/asili. Mwaka huu, tungependa kuweka muda kwa ajili ya kampeni ya uuzaji bidhaa mpya iliyoboreshwa zaidi inayolenga hadhira changa iliyo nje ya jukwaa.

Bidhaa & Usaidizi wa Kiuhandisi (PES)

Bidhaa & Uhandisi wa Bidhaa(PES1)

Lengo: Timu za Bidhaa na Uhandisi za WMF zinafaa zaidi kutokana na michakato iliyoboreshwa, na kuhimiza mabadiliko chanya katika utamaduni wetu. Jadili
- Muktadha wa lengo: Lengo hili ni kuhusu kufanya njia za Shirika Wikimedia Foundation kufanya kazi kwa haraka zaidi, nadhifu na bora zaidi. Yote ni kuhusu jinsi tunavyofanya kazi. Hii ina maana ya msuguano mdogo na vikwazo (upungufu na makosa) katika michakato, na kufikia athari haraka. Lengo hili pia linahusu njia za kujifunza za kazi ambazo zinaweza kupitishwa katika idara na shirika zima.
  - Tokeo kuu la PES1.1: Ifikapo mwisho wa Q2, kufafanua SLOs kwa huduma 6 za uzalishaji kulingana na rubriki ya vipaumbele ambayo inalenga kuongeza mafunzo yetu ya jinsi ya kufafanua na kutumia SLO kufanya maamuzi sahihi kuhusu kuweka kipaumbele kwa kazi zinazohusiana na kutegemewa na timu za washikadau.
    - Madhumuni ya Kiwango cha Huduma (SLO) ni makubaliano kati ya timu za washikadau kwenye kiwango kinacholengwa cha huduma (kutegemewa/utendaji kazi) ambacho timu hushirikiana kukutana (na kisichozidi sana). Kwa mfano, inasaidia kujua kama kutegemewa au kazi ya utendaji vinapaswa kupewa kipaumbele au kunyimwa kipaumbele na timu ya wasanidi programu, au kinachojumuisha tatizo. Timu zinahitaji kujali kutambua ni nini kinachotokea mara moja (tahadhari/majibu ya matukio/ hitilafu muhimu) dhidi ya kile ambacho sivyo. Lengo ni kupunguza msuguano katika utendaji kazi wote kwa kujadiliana kuhusu shabaha na kufahamisha uwekaji kipaumbele wa pamoja na wazi.
  - Tokeo muhimu la PES1.2: Kufikia mwisho wa Q2, ishara za jumuiya (pamoja na Orodha ya Matamanio) zimeathiri WMF kuweka kipaumbele kwa angalau mikondo 5 ya kazi ya bidhaa kwa Q3 - Q4.
    - Lengo letu ni kutambua na kusherehekea wakati timu zinatoa kipaumbele kwa kazi kulingana na maombi ya kiushahidi ya jumuiya.
    - Nadharia tete mbili zilizopangwa zimeelekezwa kwenye Orodha ya Matamanio pekee. Zimeundwa ili kuboresha uaminifu, kurahisisha michakato, na kuongeza ushiriki kati ya wafanyakazi na watu wanaojitolea. Nadharia tete nyingine ni jaribio lililoundwa ili kuona kama kuna ishara za thamani za kutosha kutoka kwa pampu ya kijiji, n.k, na kama AI inaweza kusaidia misuli yetu ya kukusanya ishara.
  - Tokeo kuu la PES1.3: Majaribio mawili ya hatua ya awali ya idara mbalimbali, yaliyothibitishwa na watumiaji wetu wa nje, wafadhili, na wachangiaji, yanajumuishwa na Shirika katika mpango wa kila mwaka.
    - Kazi hii inahusu kuunda majaribio na michakato ya majaribio ili kupitishwa katika shirika letu.
    - Shirika linaimarisha utamaduni wa majaribio ya idara mbalimbali kwa kujumuisha majaribio mawili yaliyoidhinishwa, ya hatua ya awali katika upangaji wake wa kila mwaka. Mpango huu unakuza ushirikiano zaidi ya kitengo cha vipengele vya kitengo cha Bidhaa na Teknolojia, na hivyo kuhimiza ubunifu zaidi na idara nyingine katika shirika (kama vile Mawasiliano na Maendeleo). Kwa kupanda mawazo mapya ambayo hayajajaribiwa na kurahisisha michakato ya majaribio, timu huongeza tija na athari kubwa. Mafanikio hupimwa kwa kukamilisha majaribio mawili ya idara mbalimbali kwa mwaka, kuyaunganisha katika kazi ya OKR ya siku zijazo, na kuongeza upitishwaji wa mazoea ya majaribio. Mifano ya matokeo ni bidhaa-mfano mpya za kuongeza ukuaji na tija ya wahariri wapya, hadi vipengele vya majaribio ambavyo vinakuza muunganisho wa wasomaji na wafadhili kwenye Wikipedia. Fursa moja mahususi iliyotambuliwa ni kuunganisha ugunduzi wa vipengele vidogo ili kusherehekea miaka 25 ya kuzaliwa kwa Wikipedia.
  - Key result PES1.4: By the end of Q4, we'll see a 10% adoption rate increase for Codex among P&T teams.
    - As a standardized UI library, Codex vastly reduces both the maintenance burden of creating custom UI components, as well as the time needed for implementing product UIs. Codex also provides a shared vocabulary for talking about design and implementation, which increases efficiency between Design & Engineering.
    - Codex will lose utility if adoption doesn’t increase and Codex isn’t widely used, and currently it is not being adopted or widely used in some places because the tooling isn't ready for some use cases. It may also need more prominent advertising/awareness. This work is a priority because teams must be able to adopt Codex organically, and currently not all can without blockers to adoption being addressed first.
    - We're anticipating that this will mean:
      - Discovery - What do different teams show us is blocking them? What are the use cases and blockers about which we are not yet aware?
      - Improvement - Example: We know that Codex PHP 1.0 will unblock server-side adoption.
      - Metrics deep dive - Example: What do the baseline metrics established in Q1 tell us about where organic adoption is not working (and are there lessons from OOUI adoption in years past)?
    - The KR will focus on tracking “official” usage (i.e. adoption that follows the documented guidance) separately from partial or piecemeal usage, e.g. when teams use only part of a component or just the CSS. The latter type of adoption incurs a higher maintenance cost than out-of-the-box component usage.
  - Key result PES1.5: 20% of service SLOs result in an impactful decision made by the end of Q4.
    - Service Level Objectives (SLOs) are a tool used to determine priorities based on data from service reliability. For instance, whether a down service needs immediate attention. SLOs work most effectively when ownership is clear, and everyone is using them. To make this happen we need to shift development culture toward adopting SLOs for every service. Building on the last few quarters of creating SLOs and testing them with service teams, we've identified an opportunity to clarify the value of SLOs, so that we can continue to spread this culture.
      - We have 19 SLOs currently.
      - We want to incentivize SLOs for services that would be most likely to leverage them. If we get ~3-4 (~20% 0f 19) "impactful decisions" from our current crop, great, but we anticipate we'll need to make more. The denominator will increase, but that further incentivizes targeting the right services.
      - Q4 is the end of the timebox because we want more than one cycle of data, and each quarter is a cycle. It also gives us space to shore up tooling, pilot SRE-alerting, etc.
    - Success looks like:
      - Impactful decision = “is this service currently reliable enough, or do we need to prioritize work to fix it” -- that is, it's as much a decision to find an error and say it's OK not to prioritize it, as it is to find an error and prioritize correcting it.
      - We want decisions to be diverse (e.g. Architectural vs Organizational vs Implementation; or affirmative vs deciding not to do something), because this is about spreading the value of SLOs and shifting culture. All the same type of decision or all from the same team doesn't accomplish that, even if it's good.
      - Even if we don't meet the KR target, we hypothesize that we'll have learned valuable information about why (e.g. we're targeting the wrong services).
      - Important: 80% of our SLOs not having an impactful decision is not a failure state for those, because most of the time services should not be failing.
  - Key result PES1.6: 20% of critical unowned services, according to a risk analysis framework, get owners committed by the end of Q4.
    - Clear code and service ownership is critical to ensuring the Wikimedia Foundation’s technical infrastructure remains reliable, scalable, and secure. Addressing current gaps in ownership will improve accountability, enhance cross-team collaboration, fast-track effective decision-making, and reduce risks to platform stability, security and sustainability. Additionally, it will provide greater clarity for Wikimedia affiliates and volunteers, helping them understand who is responsible for maintaining and supporting key services.
      - We estimate there are ~20 critical services without owners.
      - We think we can assign 4 owners over 4 months during Q3/4. The first 2 months or so will be setting ourselves up for success with prep work.
      - We plan to develop a risk analysis framework to determine criticality, as part of hypothesis work under this KR.
  - Key result PES1.7: By the end of Q4, 85% of wishes have a response within 10 working days, and a monthly update is posted on the work we committed to implement.
    - Having revamped Wishlist triage in the first half of the year, we want to consistently demonstrate that volunteers are getting responses to their Wishes plus a monthly update consisting of what’s coming, what’s pending or blocked, and what’s being scoped. We will judge the metric by measuring response time on a rolling average over a month, and aim to sustain that for at least a month.

Nadhariatete

Q1

Robo ya kwanza (Q1) ya mpango wa mwaka wa WMF inajumuisha Julai-Septemba.

Nadhariatete za Uzoefu wa Wiki (WE) [ Matokeo Muhimu ya WE ] Majadiliano
Jina fupi la nadharia tete	Maandiko ya Q1	Maelezo na Majadiliano
WE1.1.1	Kama tutawauliza watu wapya wanaojitolea kubandika maandishi kutoka tovuti ya nje ili kuthibitisha kama waliandika maudhui wanayojaribu kuongeza, basi tutaona kupungua kwa ≥10% asilimia ya hariri mpya za maudhui yanakayochapishwa na watu wapya wa kujitolea ambao wamerejeshwa kwa misingi ya WP:COPYVIO (na sera zinazohusiana).
WE1.1.2	Ikiwa tutatoa toleo la awali la beta la Mabadiliko Yanayopendekezwa la "Improve Tone" basi tunaweza kujifunza kama umbizo hili jipya la Mabadiliko Yanayopendekezwa ni njia ya maana ya kuongeza uhariri wa kujenga kwa wachangiaji wapya bila kuongeza mzigo wa udhibiti kwa wafanya doria/wahakiki.
WE1.1.3	Tukitumia Hali mpya ya Mapendekezo inayolengwa kwa Wachangiaji Wakuu ndani ya kihariri cha macho (simu ya mkononi + ya mezani) kama Kipengele cha Beta chenye ≥ mapendekezo 3 mapya ya uhariri ndani yake, tutagundua ni nini - ikiwa yapo - marekebisho yanahitajika kufanywa kabla ya kutathmini utumiaji na watu wapya wa kujitolea kupitia jaribio linalodhibitiwa.
WE1.1.4	Tukitumia kipengele cha Reference Check kwenye en.wiki kupitia jaribio linalodhibitiwa, tutaona ongezeko la ≥10% la mabadiliko ya kujenga ya watu wa kujitolea wapya kuchapisha na kujifunza kama kuna usaidizi wa kutosha kati ya wafanya doria na wasimamizi ili kuwezesha kipengele kwa upana zaidi.
WE1.1.5	Iwapo tutajaribu mfumo wa uendelezaji kupitia mifano ya awali ya muundo na wageni, basi tunaweza kutambua ni aina gani ya matukio muhimu, mwongozo, na utambuzi unaochukuliwa kuwa wa kutia moyo zaidi, na kutumia maarifa haya kukamilisha muundo wa majaribio ya wiki ya baadaye.
WE1.1.6	Tukichunguza vizuizi vya juu vya kiufundi, kijamii na kitabia na viwezeshaji vya uhariri wa wavuti kupitia mtandao wa simu kupitia utafiti wa watumiaji na uchanganuzi wa data, tutazalisha angalau maarifa 3 yanayoweza kutekelezeka ambayo yanaziba mapengo muhimu ya maarifa na kuimarisha uwezo wetu wa kuweka kipaumbele kwa uwekezaji wa bidhaa kwa nusu ya pili ya Mwaka wa Fedha 25/26 na zaidi.
WE1.2.1	Ikiwa tutaunda uthibitisho wa dhana ya kuonyesha data ya michango shirikishi kwenye wiki, tunaweza kukusanya maoni kutoka kwa angalau wachangiaji 30 huku 70% ya waliojibu wakishiriki kuwa kipengele hiki ni muhimu na kinaweza kusaidia kukuza ukuaji wa ushirikiano.
WE1.3.1	Ikiwa tunatumia mahitaji yaliyotambuliwa kutoka kwa utafiti na muundo uliopita na kushiriki nakala za awali za moduli kuu za X zenye athari kubwa zaidi za usimamizi, tunaweza kurekebisha ukurasa wa nyumbani kwa vitendo vya udhibiti nazo.
WE1.3.2	Ikiwa tutarekebisha ukurasa mpya wa nyumbani ili kutoa moduli za wasimamizi kwa masharti, basi tunaweza kuthibitisha uwezekano wa kutumia ukurasa wa nyumbani kwa wasimamizi.
WE1.4.1	Ikiwa tutafanya idadi ya maboresho yaliyotajwa katika T396489, tutapunguza maswali ya polepole ya mabadiliko ya hivi karibuni kwa asilimia X kwenye wiki kubwa. Kisha zana za msimamizi zitaweza kupeleka moduli za ukurasa wa nyumbani kwenye wiki hizo bila wasiwasi maalumu wa utendaji wa db.	T400696
WE2.1.1	Kama tutawaalika wazungumzaji asilia wa wiki ndogo kupitia bango la CentralNotice kwenye Wikipedia ya watu wengi katika eneo lao ili kuchangia kwa SuggestedEdits na vipengele vingine vya Growth, tunaweza kutathmini kama mbinu hii inavutia wazungumzaji wapya na ikiwa wanatumia zana hizi za kuhariri kuboresha maudhui muhimu.
WE2.1.2	Ikiwa tungetengeneza na kutoa mapendekezo ya tafsiri ambayo yanalenga wahariri wapya, basi tutaweza kujaribu kama mbinu hii inatoa matokeo bora ya tafsiri ikilinganishwa na mbinu yetu ya sasa. Hii inashughulikia changamoto zinazojulikana zinazokabili wahariri wapya, ambao wana uwezekano mkubwa wa kufutiwa makala. Kwa kuwaelekeza katika kutafsiri maudhui yanayoweza kudhibitiwa zaidi, lengo ni kutoa utangulizi usiolemea na unaoweza kufikiwa zaidi kwa mchakato wa tafsiri. Makala bora na waombaji wa sehemu wanaweza kuonekana kama uchangamano mdogo kwa namna ya mpangilio na urefu wa jumla.
WE2.1.3	Tukijifunza kuhusu uzoefu wa mhariri anapounda makala na sehemu mpya (ikiwa ni pamoja na motisha, maumaumivu na hisia zao kwa mawazo mapya kuhusu jinsi ya kuyasaidia vyema), basi tutafichua mahitaji ya mtumiaji na mienendo ambayo hutoa maarifa na mikakati inayoweza kutekelezeka ya kufahamisha bidhaa, muundo na uhandisi kuhusu kuboresha hali ya uundaji wa makala.
WE2.1.4	Tukichunguza, kupitia warsha shirikishi au mahojiano, jinsi Wikipedia tatu za ukubwa wa kati zinavyokabili mapengo ya maarifa na umuhimu, tutafichua fasili za kazi au kutunga dhana za "maarifa muhimu" ambayo yanafaa kwa kila jumuiya.
WE2.2.1	Ikiwa tutafuata uchapishaji wa Parsoid na kuunganisha Wikifunctions kwenye Wiktionary nyingi na baadhi ya Wikipedia zenye nyendo za chini, tutapata majaribio tunayohitaji ili kusambaza wiki kubwa zaidi kwa ujasiri.
WE2.2.2	Tukiwezesha Wikifunctions kutoa majedwali, mitindo na viungo vya HTML, tutaonyesha kupitia kipengele cha Kukokotoa kinachoonyesha jedwali la mnyambuliko uwezo wake wa kutoa maarifa mapya kwenye Wiktionary zaidi ya ubadilishaji rahisi.
WE2.2.3	Tukiongeza usaidizi kwa vipengele vya Wikidata katika simu za utendakazi zilizowekwa, tutawezesha zaidi vitendaji 200 vipya vinavyoweza kutoa sentensi za kina kwa kutumia vipengele vya Wikidata, na kufanya utendakazi kutumika kwa urahisi zaidi kwenye miradi ya Wikimedia.
WE2.2.4	Ikiwa tutaunda mpango wa usanifu wa mahali Maudhui ya Muhtasari yatakaa na jinsi yatakavyoingiliana na Wikipedia, tutakuwa tayari zaidi kutekeleza jukwaa la Muhtasari la Wikipedia ili kuongeza utoaji wa maudhui ya ensaiklopidia ya ubora wa juu.
WE2.2.5	Ikiwa tutafafanua na kushirikiana katika timu zote za Bidhaa na Teknolojia kuhusu mahitaji ya bidhaa kwa marejeo ambayo yanahitajika kwa Maudhui ya Muhtasari, tutaweza kuendesha kazi ya Wikimedia kote ili kutoa maelezo ya asili yaliyoambatanishwa na Muhtasari wa Maudhui, ambayo ni muhimu kwa uchukuaji kwa mafanikio katika Wiki zote.
WE2.2.6	Kama tutafanya mpangilio wetu wa ombi la ndani kuwa wazi zaidi na kwa ufupi, tunaweza kuongeza uthabiti wa mfumo, na hivyo kusaidia utoaji mpana zaidi.
WE2.2.7	Kama tutatoa vipande vya mfano tukitumia miito ya Wikidata na Wikifunctions ili kutengeneza vipande vya lugha asilia, tutaonyesha utayari kwa mradi huu, na tutakuwa tayari kuvitumiakufundishia AI ili binadamu wasilazimike kufikiria sana kuhusu kazi.
WE2.2.8	Kama tutatoa uagizaji wa taarifa za Wikidata pamoja na vivumishi, itawezekana kutoa ukweli wenye mambo mengi (ukweli unaohitaji zaidi ya mada/kivumishi/thamani kueleza), ambayo inajumuisha wastani wa 50% ya maudhui ya ensaiklopidia katika Wikidata.
WE2.2.9	Tukiweka akiba ya vipengele vya Wikidata vilivyowekuliwa, tutapunguza kwa angalau 50% wastani wa muda wa utendaji wa kadhia unaotegemea maudhui ya Wikidata, tukiokoa muda na kufadhaika kwa mtumiaji.
WE2.2.10	Ikiwa tutatoa kijenzi cha maana ya kitomeo cha Wikidata katika UI ya Wikifunctions, basi wachangiaji wataweza kutambua na kuchagua vitomeo vinavyofaa bila kuondoka kwenye jukwaa/Wikifunctions—kupunguza ubadilishaji wa muktadha na kuwezesha uundaji wa haraka na wenye mafanikio zaidi ya kadhia zinazohusiana na lugha.
WE2.2.11	Tukishughulikia matokeo ya matumizi kutoka kwa jumuiya ya Dagbani kuhusu ujumuishaji wa Wikifunctions kwenye Wikipedia, tutaona kuwa wahariri hukumbana na masuala machache au sufuri muhimu ya utumiaji wanapoingiza chaguo za kukokotoa kwenye makala wakati wa majaribio.
WE3.1.1	Tukijaribu A/B toleo lililoboreshwa la kipengele cha kuvinjari cha Vichupo, kwenye Programu ya IOS, tutaona ongezeko la 5% la matumizi ya siku nyingi miongoni mwa watumiaji wa Vichupo.
WE3.1.3	Kama tutatoa njia mpya kwa watumiaji kuvinjari maudhui husika ya picha au video ndani ya kurasa za makala, tutaona angalau kiwango cha kubofya cha 3% kati ya watumiaji ambao wamewasilishwa kwa kipengele hiki.
WE3.1.4	Ikiwa tutaonyesha wasomaji dhana kadhaa za kupitia mtandao wa maarifa kwenye wiki, tutabaki na orodha iliyopewa kipaumbele ya dhana kwa maendeleo zaidi.
WE3.1.5	Iwapo tutawapa wasomaji wa wavuti chaguo la kuona toleo la maudhui ya Wikipedia yaliyotafsiriwa kwa mashine ambayo hayapo katika lugha yao, tutajifunza kama shughuli ya kusoma imeongezeka, ikipimwa kama ongezeko la 3% la mwingiliano wa kurasa, kuwavuta wasomaji kwenye wiki ya lugha ya ndani yenye uwezekano wa ongezeko la shughuli za uhariri wa ndani. Hii itatolewa kama mpangilio wa majaribio ya A/B unaodhibitiwa kwa muda usiozidi miezi 6, na katika Wikipedia 13 kwa idhini ya awali, kwa kutumia huduma za utafsiri za mashine wazi ambazo tayari zinapatikana kwa wahariri wa Wikipedia.
WE3.2.1	Tukishirikiana na kuchangisha pesa tutatengeneza slaidi za wafadhili zinazovutia zaidi, zilizounganishwa na za kibinafsi katika Mwaka wa Mapitio wa iOS kama inavyopimwa kupitia majaribio ya watumiaji. Hili litafuatiliwa na dhana katika Q2 ili kutathmini ikiwa Mapitio ya Mwaka ulioboreshwa yalitoa michango kwa 5% zaidi ya Mwaka wa Mapitio wa 2024.
WE3.2.2	Ikiwa tutawaomba wasomaji wa Programu za Android katika masoko yasiyo ya kampeni kuweka kikumbusho cha hiari, kinachoweza kugeuzwa kulingana na matakwa ya mtumiaji (idadi na marudio) kwa michango kulingana na matumizi yao ya Wikipedia, tutaona ongezeko la 5% la michango ya menyu ya programu tumizi katika masoko hayo.
WE3.2.3	Iwapo tutafanya jaribio la A/B kwa watumiaji walioondoka ili kuonyesha matoleo madogo ya sehemu ya michango kwa simu za mkononi na kwa kompyuta za mezani, tutaona idadi ya juu ya 2% ya michango kupitia njia za matibabu, ikilinganishwa na udhibiti.
WE3.3.1	Tukiongeza vipengele vya kibinafsi vya chini hadi vya kati vilivyoombwa na watumiaji wa iOS mwaka 2024 hadi 2025, tutaona ongezeko la 3% katika kiwango cha kuridhisha ikilinganishwa na mwaka jana, kama inavyopimwa kupitia majaribio ya utumiaji au majaribio ya beta.
WE3.3.2	Tukipanua kichupo cha Hariri kilichopo kwenye Android hadi kuwa hebu ya shughuli ya kibinafsi ambayo inajumuisha maarifa kuhusu kusoma na kutoshiriki kuhariri, tutaona ongezeko la 5% la matumizi ya siku nyingi na kichupo hicho ikilinganishwa na toleo la awali.
WE3.3.3	Tukianzisha angalau avatar moja ambayo inaweza kufunguliwa katika programu tumizi ya Android kwa wamiliki wa akaunti—iliyopatikana kupitia vitendo vya maana vya usomaji kama vile kuhifadhi idadi fulani ya makala — tutaongeza ushiriki unaorudiwa na vitendo vinavyohusishwa na watumiaji walioingia kwa 10% kwa siku nyingi.
WE3.3.4	Ikiwa tutawapa wasomaji walioingia katika akaunti uwezo wa kuhifadhi makala kwenye orodha ya usomaji ya faragha, tunatarajia ushiriki kwenye tovuti utaongezeka, kama inavyopimwa na ongezeko la 5% la trafiki ya rufaa ya ndani kwa wasomaji wanaotumia kipengele, na ongezeko kubwa la takwimu kwa watumiaji wote.
WE3.3.5	Ikiwa tutafanya utafiti wa mtumiaji unaoruhusu wasomaji wa wavuti kukusanya au kuratibu maudhui kutoka kwa Wikipedia, basi angalau 10% ya washiriki watahifadhi aina mbili au zaidi tofauti za maudhui (k.m. makala, dondoo, vyombo vya habari) kwenye mkusanyiko.
WE3.4.1	Ikiwa tutafanyia kazi uwekaji mseto wa PoP/CDN, itaturuhusu kuleta PoP kamili na PoP ndogo (za kimwili na wingu) kama inavyohitajika, na kuweka msingi wa uwekaji wa mfano mdogo wa PoP katika siku zijazo.
WE3.6.1	Iwapo tutafanya jaribio la A/A kuhusu kiwango cha kubaki kwa watumiaji walioondoka, tutaweka msingi wa kiwango cha kubaki ambacho tunaweza kutumia kwa robo za baadaye.
WE3.6.2	Iwapo tutafanya jaribio la A/A kuhusu kiwango cha kubaki kwa watumiaji walioondoka, tutaweka msingi wa kiwango cha kubaki ambacho tunaweza kutumia kwa robo za baadaye.
WE3.6.3	Ikiwa tutashirikisha jumuiya katika mazungumzo kuhusu mahitaji yanayoendelea ya wasomaji, na kuhusu mabadiliko ya asili ya maarifa kwenye mtandao, tunaweza kujenga mtazamo wa pamoja wa jinsi ya kuwahudumia wasomaji na kufanya kazi pamoja kuhusu kama na jinsi ya kujaribu mawazo yetu mbalimbali (ikiwa ni pamoja na wale walio karibu na mediatutiko, utafutaji na ugunduzi, na kujifunza kwa mashine).
WE3.6.4	Tukitafiti misukumo, tabia, na mahitaji mahususi nyuma ya lini, kwa nini na jinsi wasomaji wanavyotumia Wikipedia na majukwaa mengine ya maarifa, tutakuwa na matokeo tunayoweza kutumia kufahamisha na kubadilisha mkakati wetu wa watumiaji.
WE4.1.1	Iwapo tutaiga mtiririko usio wa dharura unaoweza kutumika kwa kiasi kidogo, na kuweka wazi kitanzi cha maoni cha kurudia tunapoyatengeneza na watumiaji walio na haki za ziada, basi vikundi hivi vitasaidia uenezaji zaidi wa mtiririko huu.	Project page
WE4.2.1	Tukiwasilisha kiwango cha hatari cha hCaptcha kinachohusishwa na ufunguaji akaunti kwa watendaji wanaoaminika, tutapunguza muda unaohitajika ili kutambua watendaji wabaya, na kuongeza idadi ya ugunduzi wa akaunti za watu wabaya zinazoundwa kwenye jukwaa. Tunaweza kupima mafanikio ya nadharia tete kwa kuangalia kiwango cha vizuizi vinavyotumika kwenye akaunti, upatanishi wa viwango vya hatari vya hCaptcha na vizuizi vya akaunti kwa ujumla, na mrejesho wa maelezo kutoka kwa watendaji.
WE4.2.2	Ikiwa tutatoa uchunguzi uliopendekezwa kwa CheckUsers kufuatilia, tutaona kupungua kwa muda unaohitajika ili kutambua akaunti za watendaji wabaya na ongezeko la idadi ya akaunti za watendaji wabaya zilizotambuliwa. Tutajua kuwa tumefaulu tunapoona matumizi ya mara kwa mara ya kipengele cha "Uchunguzi Unaopendekezwa", ongezeko la vidhibiti vinavyotumika kwa akaunti zilizotambuliwa kupitia uchunguzi uliopendekezwa, na kupitia mrejesho utafiti wa maelezo.
WE4.2.3	Tukichanganua data kutoka kwa jaribio la kuunda akaunti ya hCaptcha, tutaelewa njia ya kufungua akaunti, ufanisi wa fumbo na alama za hCaptcha, na kuwa na data inayohitajika kujulisha kuhusu utekelezaji zaidi wa hCaptcha kwenye ufunguaji akaunti.
WE4.2.4	Ikiwa tutatumia UserInfoCard kwenye wiki zote, tutawawezesha watendaji na wasimamizi kutambua na kupunguza akaunti za watendaji wabaya zaidi.	Project page
WE4.2.5	Ikiwa tutafanya utafiti, kushauriana na jumuiya, na kuchunguza suluhu za kiufundi, tutaweza kufafanua jumla ya sababu zilizopangwa za kuzuia ambazo zinaweza kutumika katika wiki zote za WMF.
WE4.2.6	Tukikuza uwezo wa kupeleka makundi kulingana na OpenSearch kwenye Jukwaa la Data, basi timu za uhandisi wa vipengele vya bidhaa zitawezeshwa kuunda mifumo inayounganisha uwezo huu, kwa uhuru, uthabiti, na kutengwa kwa mifumo mingine inayotegemea utafutaji. Mpangaji wa kwanza na mkuu wa mfumo huu atakuwa huduma ya IPoid.
WE4.2.7	Tukiweka ujumuishaji wa hCaptcha Enterprise kwenye Wikipedia kadhaa za uzalishaji kama majaribio ya awali, tutaweza kukusanya data kuhusu ufanisi na thamani ya hCaptcha Enterprise juu ya kupambana na matumizi mabaya, utambuzi wa roboti, utumiaji na ufikiaji.
WE4.3.1	Tukijumuisha usaidizi wa kidakuzi kipya cha Edge Uniques kwenye requestctl, injini yetu ya sheria za makali ya SREs kupambana na matumizi mabaya, tutaweza kutetea vyema DDoS na matumizi ya maudhui tena.
WE4.4.1	Iwapo tunaweza kufanya uboreshaji kulingana na maoni ya majaribio na kutumia Akaunti za Muda kwa miradi yote tutaweza kulinda ufichuaji wa taarifa zinazotambulika kibinafsi (anwani za IP) za watumiaji ambao hawajasajiliwa kwenye miradi yetu yote ili zipatikane kwa chini ya 0.1% ya watumiaji wote (waliosajiliwa).	Project page
WE4.4.2	Iwapo tutawasiliana na wadau husika wa harakati (pamoja na jumuiya za wiki na watendaji wa kimataifa) kwa uwazi na kwa wakati, tutaweza kutumia kwenye Wiki zote zilizosalia, kupunguza mzigo wa kazi uliogunduliwa katika dakika ya mwisho, na kuepuka kurudisha nyuma utumiaji.
WE4.4.3	Ikiwa tutafanya iwe rahisi kwa wafanya doria kuchuja vitendo na kutazama shughuli za akaunti za muda, kulingana na anwani zao za IP, basi tutawezesha akaunti za muda kuanzishwa kwa wiki zote kwa ufanisi.
WE4.4.4	Tukiruhusu akaunti ya muda ya IP kufichua ufikiaji kubatilishwa kwa mujibu wa sera ya IP kufichua ufikiaji, na kuonyesha kipengele hicho katika sehemu nyingi zaidi, basi tutawezesha akaunti za muda kuanzishwa kwa wiki zote kwa ufanisi.
WE4.5.1	Iwapo tutafanya utafiti wa maelezo kutambua mifano ya matumizi mabaya kutoka kwa watendaji wabaya wanaosaidiwa na AI zalishi (kama vile barua taka, unyanyasaji, watu wenye matumizi mabaya kwa muda mrefu, uhariri wa malipo ambao haujafichuliwa, au kampeni za taarifa za uongo), tutaweza kutathmini hatari kwa miundo ya jumuiya yetu na kutoa mawazo ya kupunguza aina tofauti za matumizi mabaya ya AI.
WE4.6.1	Tukiweka mchakato wa kusawazisha akaunti otomatiki ndani ya Zendesk kwa kuweka upya nywila, hii itapunguza mzigo kwenye T&S na kuwaruhusu kushughulikia maombi zaidi ya 2FA yanayoingia.
WE4.6.2	Ikiwa tutawasaidia na kuwahimiza watumiaji kusajili vipengele vingi vya uthibitishaji, watumiaji walio na 2FA watakuwa na uwezekano mdogo wa kujifungia nje ya akaunti zao.
WE4.6.3	Tukiruhusu watumiaji wote walio na anwani ya barua pepe iliyothibitishwa waweze kuwasha 2FA kwa akaunti zao, lakini tusitangaze mabadiliko haya kwa watumiaji mapema, mzigo wetu wa dawati la usaidizi wa urejeshaji utasalia katika kiwango endelevu.
WE5.1.1	Ikiwa tutatumia mbinu tofauti za hifadhi kwa vipindi vilivyoidhinishwa na visivyojulikana, tutaweza kulinda hifadhi ya vipindi dhidi ya mashambulizi ya DDoS na mashambulizi ya wachambuzi wa tovuti wa kiwango kikubwa, kwa kutoipakia vipindi visivyojulikana ambavyo vimeundwa ili kutoa uzuiaji wa CSRF kwenye kurasa za uthibitishaji.	T398814
WE5.1.2	Tukibadilisha kuki za kipindi cha MediaWiki kuwa muundo uliopangwa wenye saini ya kriptografia, tutaweza kutumia uwepo wa kipindi kama kipengele cha ulinzi dhidi ya vikwaruzi, kwa kuwezesha uthibitishaji unaoaminika wa vipindi ukingoni kwa njia yenye utendaji wa juu na inayoweza kupanuka kwa urahisi.	T398815
WE5.1.3	Iwapo tutaunda suluhisho la kupunguza viwango vya lango la API kwa kutumia mazingira ya eneo la uendelezaji kulingana na Kubernetes, tutaweza kubaini kubaini njia bora ya kufanya majaribio kwa trafiki ya uzalishaji, kwa kulinganisha utendaji na ufanisi wa angalau huduma tatu tofauti za kudhibiti kiwango cha maombi.	T398913
WE5.2.1	Tukiunda upya REST API Sandbox UI ili kukidhi vyema mahitaji ya maelezo ya wasanidi programu, tutaboresha uwazi wa hati, kama inavyothibitishwa kupitia majaribio ya utumiaji.
WE5.2.2	Ikiwa tutaelekeza API zote chini ya rest.php kupitia lango kuu, tutafungua njia za usimamizi wa API kati na tunaweza kuanza kupima mara kwa mara trafiki ya API ya REST na mifumo ya matumizi ili kupata maarifa ambayo yataarifu maamuzi na vitendo vya siku zijazo.
WE5.2.3	Ikiwa tutatekeleza ufuatiliaji wa dashibodi na kengele za API ya MediaWiki REST, basi tunaweza kuonyesha njia endelevu, muhimu, na inayoweza kunakiliwa ili kuboresha mwonekano wa tabia na masuala ya mifumo yetu mapema, hasa wakati wa marekebisho muhimu.
WE5.3.1	Tukipanua na kuratibu miongozo ya maelezo ya UX huku tukisasisha miongozo yoyote iliyopo, tutaanzisha seti ya msingi ya miongozo iliyoboreshwa iliyo tayari kujaribiwa ndani na kuboreshwa mara kwa mara ili kutayarishwa kwa matumizi mapana ya umma.
WE5.3.2	Iwapo tutaunda sauti inayoonyesha manufaa ya kuhusisha Wikipedia na watumiaji wengine wa maudhui na watumiaji wao wa mwisho, tunaweza kuunga mkono WME4.1 & WME4.2 kwa kuwezesha angalau mshirika mmoja wa ziada wa matumizi ya kurudia kukubali kuonekana katika utafiti wa kisa au onyesho kufikia mwisho wa Q1.
WE5.4.1	Ikiwa tutahakikisha kuwa sehemu kubwa ya maombi ya wavuti yanapata kuki ya kipekee kwenye ukingo, itakuwa rahisi kutambua roboti na maombi ghushi.
WE5.4.2	Iwapo tutaunda njia kubwa ya kutambua wateja wanaojulikana, tunaweza kuruhusu vizuizi vya viwango vya jumla vya roboti za asili iliyothibitishwa, na kuelekea kwenye utekelezaji wa utaratibu wa sheria zetu.
WE5.4.3	Tukipanga upya uchujaji wa maombi ya maandishi kwenye CDN kwa kuzingatia orodha ya ruhusa/orodha ya kukataliwa, tunaweza kutekeleza uzuiaji wa viwango vya jumla vya roboti na kurahisisha uchujaji wa trafiki.
WE5.4.4	Iwapo tutaunda mkakati wa umoja wa kipimo, tutawezesha kutathminiwa kwa mkakati wa miaka mingi wa 'matumizi yenye uwajibikaji ya miundombinu,' na kufafanua ramani ya mwongozo ya kuendeleza vipimo na uwezo wa kuripoti.
WE6.1.1	Ikiwa tutarejesha muundo wa picha wa kila siku kwenye seva ya utumiaji na kuongeza masasisho ya picha yanayotokana na vitendo fulani vya uwekaji tutafichua vikwazo na kuweka msingi wa muda unaohitajika ili kutekeleza utumiaji zaidi unaoendelea.
WE6.1.3	Tukiongeza wikifarms kwenye mazingira ya majaribio ya kabla ya kuunganisha hii itawezesha timu za maendeleo zinazojenga dhidi ya uzalishaji ambazo zinahitaji Wiki nyingi kupima visasisho vyao kwa kutengwa na kuzipa ujasiri mkubwa zaidi katika hatua ya maandizi ya uzalishaji na kusababisha kuepuka kasoro chache.
WE6.2.1	Tukipitia na kuchapisha Orodha yetu ya Kujitayarisha kwa Uzalishaji ambayo inafafanua kwa uwazi sharti la huduma itakayochukuliwa kuwa tayari kwa uzalishaji, pamoja na kazi zinazoweza kujiendesha, tutapanga matarajio kati ya SREs na timu za utayarishaji, kuboresha ufanisi wetu wa jumla wa utenndaji na ukubwa.
WE6.2.2	Tukitangaza kuunda maktaba ya Golang na nodejs inayoondoa kazi nyingi ngumu kwa wasanidi programu, watatujibu wakitoa maoni na upendeleo.
WE6.2.3	Ikiwa tutaunda orodha/lahakazi, wasanidi wanaweza kujiandaa kikamilifu mapema kwa ukaguzi wa muundo wa Kudumu kwa Data.
WE6.3.1	Iwapo tutasambaza angalau Wikipedia 70 zenye trafiki ya chini katika Q1, bila kujumuisha wiki zenye usaidizi wa kibadala cha Lugha, tutaongeza imani yetu kwa usambazaji wa mwisho kwa wiki 10 bora ambazo zitakuwa na athari kubwa katika mitazamo ya kurasa zinazotolewa kupitia Parsoid.
WE6.4.1	Ikiwa tutaweka jedwali la viungo vya kugawanyika la Commons katika kundi lake lenyewe, tutaongeza uwezekano kwamba ukuaji wa kanzidata kwa Commons utaendelea kuwa endelevu.	T398709
WE6.4.2	Ikiwa sisi (SRE) tutatoa usaidizi kwa timu za wahandisi za MediaWiki - kwa kuunda hati, kuandaa miundombinu ya msingi inayohitajika (k.m., vifurushi vya PHP, picha za makontena), na kutoa mwongozo na ukaguzi - wataweza kuanzisha toleo jipya la PHP 8.3 kwa ujasiri mwanzoni mwa Q2.	T360995
WE6.4.3	Iwapo tutahitaji kipengele cha pili halisi (ufunguo wa usalama wa maunzi) kwa ajili ya kuingia kwa SSH na watumiaji walio na haki za juu za mfumo, tutapunguza hatari kwamba kompyuta mpakato iliyoathiriwa itasababisha ukiukaji mkubwa wa usalama.
WE6.4.4	Ikiwa tutaunganisha vikoa vyetu kwa kuhudumia mara ambazo ukurasa umetazamwa kwenye tovuti za MediaWiki kupitia kikoa cha kisheria, basi tutapunguza utata wa jukwaa na hatari za Injini ya Utafutaji (SEO) kwa kuondoa uelekezaji wa kikoa kidogo cha simu. Kukamilika kunapimwa kwa kupunguza uelekezaji kwa matembezi ya simu kwenye vikoa vya kisheria kutoka 100% hadi 0%.	T214998
WE6.4.5	Ikiwa Timu ya Uhandisi ya MediaWiki itafuatilia na kurekebisha masuala katika MediaWiki kikamilifu yanayohusiana na uboreshaji wa PHP 8.3, timu ya SRE itafunguliwa ili kuendelea na uboreshaji wa PHP 8.3 mwanzoni mwa Q2.	T360995

Nadharia tete za Ishara na Huduma za Data (SDS). [ Matokeo Muhimu ya SDS ] Majadiliano
Jibu fupi la nadharia tete	Maandiko ya Q1	Maelezo na Majadiliano
SDS1.1.1	Tukichanganua ufanisi wa mbinu za kiotomatiki za kugundua trafiki katika seti zetu za data za mwonekano wa kurasa, tutaweza kutengeneza vipimo vya ubora wa data ili kuelezea utendaji wao na kubainisha hitaji la uwekezaji zaidi katika hesabu hizi.
SDS1.2.2	Tukihamisha mchakato wa kutengeneza nakala za XML kutoka kwa miundombinu ya sasa ya 'Dumps 1' kwenda kwenye njia ya usindikaji wa data inayotumia mfumo wa MediaWiki, tutaweza kuhakikisha SLO na kuzima mfumo wa zamani wa 'Dumps 1' unaotumika kusafirisha data za XML.
SDS1.2.3	Tukifanya mapitio na kukagua SLO za Historia ya Maudhui ya MediaWiki na Jukwaa la Tukio/Lango la Tukio, tunaweza kuthibitisha wateja, vipimo na wadau tegemezi, na kutambua maboresho ambayo yanaweza kuhitajika kwa SLO, ambayo yatatusaidia kufafanua mapungufu yoyote katika dhamana zetu za kila wiki za uwasilishaji.
SDS2.1.1	tukioanisha kwa karibu na timu zinazoendesha majaribio, tutajifunza jinsi ya kufanya mfumo ujihudumie zaidi katika siku zijazo na ni changamoto zipi za kimawazo au za kiufundi ambazo wanaweza kukabiliana nazo.
SDS2.1.2	Ikiwa tunaweza kutekeleza utatuzi bora zaidi wa uwekaji kumbukumbu za matukio, basi timu za bidhaa zitajua kuwa jaribio lao linakusanya data ya matukio kama inavyotarajiwa, na hivyo kuongeza imani ya wamiliki wa majaribio.
SDS2.1.3	Iwapo tutaboresha kumbukumbu na uangalizi wa kijenzi cha jukwaa la majaribio ya A/B (xLab) cha jukwaa la majaribio, na kwa sehemu zake zinazohusiana za MediaWiki, tutaweza kuweka misingi ya utendaji wa mfumo na kujibu matatizo yanayohusiana na majaribio.
SDS2.1.4	Ikiwa tutashiriki hadithi za majaribio na matokeo katika shirika mara moja kwa mwezi (kupitia mikutano ya Watendaji wa Bidhaa, mikutano ya timu ya Usanifu, na mawasilisho ya timu mbalimbali), basi tutaunda matumizi ya kiasili ya jukwaa la majaribio.
SDS2.1.5	Tukiwaambia watumiaji kuwa zana yao, ikiwa imeundwa katika xLab, ina kundi la sifa zinazobadilisha aina ya hatari, tutazuia watumiaji wa zana kutoka kwa kukusanya data kupita kiasi na kuongeza uwazi kuhusu mchanganyiko wa sifa gani unaohitaji ukaguzi wa faragha.

Nadharia tete ya Hadhira ya Baadaye (FA) [ Matokeo Muhimu ya FA ] Majadiliano
Jina fupi la nadharia tete	Maandiko ya Q1	Maelezo na Majadiliano
FA1.1.1	Iwapo sisi 1) tunatoa njia kwa wakusanyaji wa maudhui kwenye mifumo mingine (kama vile Letterboxd, Goodreads, na RateMyMusic) ili kuboresha mikusanyiko yao kwa maarifa ya kipekee ya Wikipedia, au 2) kuwapa wakusanyaji wa vyombo hivi vya habari vitu vya kushirikisha kwenye mitandao ya kijamii, kisha tutaweza kuongeza ufikaji wa Wikipedia nje ya jukwaa lake.
FA2.1.1	Ikiwa tutajenga uwezo wetu wa ndani wa kuunda maudhui mafupi ya video (kwa kuongeza ukubwa wa timu yetu na ukaguzi na kutambua fursa za kuongeza ufanisi katika mchakato wetu wa sasa wa uzalishaji) katika Q1, tutaweza kuchukua hatua kutokana na mafunzo kutoka kwa maudhui yaliyoundwa katika Mwaka wa Fedha 2024-5 na kufikia kiwango cha juu cha YoY ya maudhui yaliyozalishwa katika Q2 Mwaka wa Fedha 2025-6.

Nadharia tete za Usaidizi wa Bidhaa na Uandisi (PES) [ Matokeo Muhimu ya PES ] Majadiliano
Jina fupi la nadharia tete	Maandiko ya Q1	Maelezo na Majadiliano
PES1.1.1	Iwapo tutaunga mkono xLab, Chati, na ToneCheck katika kufafanua vipimo vya SLI (Viashiria vya Kiwango cha Huduma) katika Prometheus, na kuingia kwenye Malengo ya Kiwango cha Huduma (SLO) kwenye Pyrra, tutajifunza vikomo na masuala ya kona za utumiaji wa zana zetu kama vile ufafanuaji wa zana nyingi zinazohitajika. kiolezo cha SLO, ambacho kitatusaidia kuunga mkono vyema SLO 6 zilizopangwa kwa KR.
PES1.1.2	Ikiwa tutajaribu seti mbili za dashibodi za tahadhari ya SLO, tutajifunza jinsi itakavyokuwa vigumu kutekeleza zana zinazofaa ili wamiliki wa huduma waelewe waziwazi ahadi zao, na pia kama tunahitaji kuhamia zana tofauti ambayo inatoa mwonekano mmoja tu wa SLO mahususi. Dashibodi moja itakuwa ya ripoti za kila robo mwaka (ambapo Makubaliano ya Kiwango cha Huduma ya bajeti ya hitilafu yamewekwa) na ile ndogo inayobadilika (inayoitwa "rolling") itakuwa ya shughuli za kila siku na kutahadharisha.
PES1.1.3	Iwapo tutaendelea kuunga mkono kikundi cha Abstract Wikipedia katika kuandaa SLO (Malengo ya Kiwango cha Huduma) kwa mradi wa Wikifunctions, tutajifunza jinsi ya kufafanua orodha ya malengo ya SLO (pamoja na vipimo vyao vya Viashiria vya Kiwango cha Huduma) kwa kipengele changamani kinachoongezwa kwa sasa kwa mtiririko muhimu wa mtumiaji: kutoa makala za Wiki. Pia tutajifunza jinsi ya kuibua vyema bajeti za hitilafu zinazohusiana na tahadhari juu yake kwa kutumia dashibodi na vifuatiliaji vilivyotolewa na SRE.
PES1.1.4	Iwapo tutaunga mkono kikundi cha Data Platform kupitia na kurudia Malengo ya Kiwango cha Huduma (SLO) kwa mradi wa Historia ya Maudhui ya MediaWiki, tutajifunza jinsi ya kutumia SLO kusaidia umiliki wa huduma wakati mseto wa huduma za kuchakata bechi na utiririshaji zinapopangwa pamoja ili kusasisha seti ya data, kuiweka sawa na kupatikana kwa watumiaji wa mwisho.
PES1.2.1	Tukitengeneza maboresho 3 yaliyolengwa kwenye Orodha ya Matamanio, basi tutahimiza washiriki 30% zaidi wa kipekee katika Orodha ya Matamanio.
PES1.2.2	Ikiwa tutajaribu matakwa yanayoingia na kukabidhi Watunzaji (k.m. Wasimamizi wa Bidhaa) ndani ya saa 72 (ikiwa ni pamoja na kukataa, kufafanua, kuripoti huduma ambazo hazijadumishwa, n.k.), kwa kurejelea matakwa mapya dhidi ya jedwali la Watunzaji na kukabidhi "Jamii ya Mtunzaji" kwa timu ya bidhaa husika zaidi au mtu binafsi, mtu binafsi, Watunzaji (k.m. Wasimamizi wa Bidhaa) wataweza kutathmini na kujibu matakwa ndani ya siku 10 au chini ya hapo.
PES1.2.3	Ikiwa tutajaribu kazi ya kutambua ishara za jumuiya kwa ujumla, tutajumuisha sauti zaidi ya watu wa kujitolea katika juhudi zetu za kuweka kipaumbele kwa jamii.
PES1.2.4	Ikiwa tutafanyia majaribio mchakato wa matamanio ya kila robo mwaka na kuashiria mchakato wa ukaguzi wa jumuiya na timu 3 katika Q1, tutashirikisha Wasimamizi wa Bidhaa ili kujumuisha ishara za jumuiya katika michakato yao ya kupanga kila robo mwaka na kila mwaka.
PES1.3.1	Iwapo, kufikia mwisho wa Q1, tutaratibu vipindi 3 vya upangaji kazi na idara ya Mawasiliano na timu za bidhaa ili kupatanisha ujumbe, mahitaji ya ubunifu, na ratiba za kampeni za mipango ya WP25, basi tutakamilisha muhtasari wa ubunifu wa majaribio yote 3 ya kampeni (25YiR, Mayai ya Pasaka, WikiRun).
PES1.3.2	Tukianzisha kamati inayoongoza iliyo na wawakilishi kutoka kwa Usanifu na uhandisi wa vipengele, tutaweza kufafanua vipimo vya msingi kuhusu michango ya Codex: ufahamu, matumizi, ubora wa mchango na wingi. Maarifa kutokana na kutathmini dhidi ya vipimo hivi vya msingi yatatusaidia kubainisha ramani ya kushirikisha ukuaji na mseto wa msingi wa wachangiaji wa Codex.

Q2

Robo ya pili (Q2) ya mpango wa mwaka wa WMF inajumuisha Oktoba-Desemba.

Nadharia tete za Uzoefu wa Wiki (WE) [ Matokeo Muhimu ya WE ] Majadiliano
Jina fupi la nadharia tete	Maandiko ya Q2	Maelezo na Majadiliano
WE1.1.1	Tukichanganua seti iliyoamuliwa mapema ya viashirio vya awali ≥wiki 2 baada ya kuanza kwa jaribio la Paste Check la A/B, tutaweza kubainisha ni nini - iwapo zipo - nyanja za uzoefu kamili kuanzia mwanzo hadi mwisho zinahitaji kurekebishwa au kuchunguzwa kabla ya kuwa na uhakika wa kutathmini athari ya kipengele.
WE1.1.4	Tukiweka Reference Check kwenye en.wiki kupitia jaribio linalodhibitiwa, tutaona ongezeko la ≥4% la mabadiliko ya kujenga ya watu wakujitolea wapya kuchapisha na kujifunza kama kuna usaidizi wa kutosha kati ya wafanya doria na wasimamizi ili kuwezesha kipengele kwa upana zaidi.
WE1.1.7	Tukichanganua seti iliyoamuliwa mapema ya viashirio vya awali ≥wiki 2 baada ya kuanza kwa jaribio la Tone Check la A/B, tutaweza kubainisha ni nini - iwapo zipo - nyanja za uzoefu kamili kuanzia mwanzo hadi mwisho zinahitaji kurekebishwa au kuchunguzwa kabla ya kuwa na uhakika wa kutathmini athari ya kipengele.
WE1.1.8	Tukitumia kielelezo cha Tone Check kwa makala zilizochapishwa, tutajifunza ikiwa tunaweza kutambua matatizo ≥10,000 ya toni (kila moja ikiwa na uwezekano wa alama 0.8 au zaidi) ambayo inahitajika ili kuunda mkusanyiko wa ubora wa juu (usahihi ≥ 70%) ili kusaidia wahariri kuboresha toni ya makala.
WE1.1.10	Tukihoji ~ watu 10 wa kujitolea wenye uzoefu katika en.wiki na fr.wiki wanaoandika AbuseFilters (na vifaa vingine/hati/violezo/notisi za kuhariri) ili kufanyia doria au usimamizi otomatiki mtiririko wa kazi,tutatambua ruwaza/mahitaji ≥3 ambayo yatasaidia kuchagiza pendekezo la thamani la Ukaguzi wa Kuhariri ulioandikwa na jumuiya.
WE1.1.11	Tukisambaza utafiti kwa ≥500 waliofanikiwa kuingia[i] na kupata data ya ubora wa juu ambayo inawakilisha idadi kubwa ya wageni waliofaulu, tutaweza kubainisha ≥maarifa 4 yanayoweza kutekelezeka tunayoweza kutumia kuweka kipaumbele ni vipengele gani vya uandikishaji vinahitaji kuboreshwa.
WE1.1.12	Tukiwezesha watu ≥3 wa kujitolea kutathmini ≥30 sampuli za mabadiliko kila moja, kwa kila lugha kati ya 10 mpya tunazotafuta kuongeza hadi, tutajifunza ni mara ngapi watu wakujitolea wanakubaliana na ubashiri wa moduli na tutaweza kuamua ni wiki zipi mpya za kufanyia kazi kuhusu kupeleka Tone Check .
WE1.1.13	Ikizingatiwa tuliongeza "Add a Link" kwa 100% ya watu wapya wa kujitolea zaidi katika Wikipedia ya Kiingereza, kisha uwezeshaji na uhifadhi wa programu mpya utaongezeka, jambo ambalo litaongeza uhariri mzuri unaofanywa na watu wapya wa kujitolea kwa ≥4%.
WE1.2.3	Tukiondoa sharti kwamba mtu fulani anahitaji haki ya Mwandalizi wa Tukio ili kutumia Usajili wa Tukio kwenye wiki ndogo na za kati, basi tutaona angalau matukio X zaidi* yaliyoundwa kwenye wiki ndogo na za kati kufikia mwisho wa mwaka wa fedha. hesabu ya kiwango cha mwanzo au lengo bado haijakamilika
WE1.2.4	Kama tutarudia kwenye MVP ya Michango Shirikishi yenye angalau maboresho 2, basi ushirikiano zaidi utaundwa kupitia Usajili wa Matukio.
WE1.2.5	Tukiweka mkakati mmoja wa upitishaji wa Usajili wa Tukio kwenye Wikimedia Commons mapema Q2, tutaweza kuufanyia majaribio na waandaaji wa angalau kampeni 1 kubwa na kuwawezesha waandaaji 5 wa ndani kutumia kipengele hicho.
WE1.3.3	Tukizindua jaribio la kuwasilisha dashibodi ya msimamizi kwa wahariri wapya zaidi, 10% ya wachangiaji wanaoitembelea hufanya hivyo wiki mbili mfululizo.
WE1.4.1	Tukifanya uboreshaji uliofafanuliwa katika T396489, tutapunguza maswali ya polepole ya mabadiliko ya hivi karibuni kwa angalau 30% kwenye wiki kubwa, ambayo yatawezesha Teknolojia ya Jumuiya kutumia Lebo za Orodha ya Ufuatiliaji bila kupakia kanzidata ya mabadiliko ya hivi karibuni.
WE1.4.3	Ikiwa tutatumia mabadiliko ya hivi karibuni na orodha ya ufuatiliaji, basi tunaweza kufafanua kiwango cha msingi ni mara ngapi watu wanabofya kwenye kurasa.
WE1.5.1	Ikiwa tutatumia dashibodi kuchunguza vipimo 7 vya wachangiaji na kusawazisha hesabu ya angalau kipimo kimoja kwa kutumia dbt basi tunaweza kuwezesha timu za bidhaa za wachangiaji kujihudumia zenyewe maarifa ya upimaji na kukuza kiwango cha kuhifadhi mantiki ya hesabu ya kipimo.
WE1.5.2	Tukibainisha katika Q2 ni hatua zipi za udhibiti zakujumuisha katika ufafanuzi wa nani ni Msimamizi, basi timu ya Maarifa ya Harakati inaweza kuunda kipimo cha Wasimamizi Wanaotumika Kila Mwezi katika Q3/Q4.
WE2.1.3	Tukijifunza kuhusu uzoefu wa mhariri anapounda makala na vipengele vipya (ikiwa ni pamoja na motisha, matatizo na hisia zao kwa mawazo mapya kuhusu jinsi ya kuwasaidia vyema), basi tutafichua mahitaji ya mtumiaji na mienendo ambayo hutoa maarifa na mikakati inayoweza kutekelezeka ya kuhabarisha bidhaa, muundo na uhandisi kuhusu kuboresha hali ya uundaji wa makala.
WE2.2.12	Tukianzisha Wikifunctions kwa wiki ambazo zimewezeshwa Parsoid, tutaweza kuendelea kujaribu kama mfumo utaendelea kufanya kazi na kutumika katika uchapishaji mpana zaidi.
WE2.2.13	Iwapo tutashirikisha upatikanaji wa utendaji wa jedwali la muunganisho na jumuiya ya Wiktionary, tutapata maoni muhimu kuhusu matumizi ya utendaji na maarifa kuhusu watu wetu ambao tunaweza kutumia kwa uchapishaji wa siku zijazo.
WE2.2.14	Tukiangalia kazi ya Databox ya jumuiya kuhusu kutumia Wikidata kwa visanduku vya taarifa na kuchunguza kama Wikifunctions zinaweza kusaidia, tutaweza kutambua jaribio la kwanza la Wikifunctions katika visanduku vya taarifa.
WE2.2.15	Tukiunda ufahamu wa jumuiya kuhusu uwezo wa kuunda na kutafsiri ujumbe wa hitilafu kwenye Wikifunctions, tutaona ongezeko la idadi ya ujumbe muhimu wa hitilafu.
WE2.2.16	Ikiwa tutatoa onyesho la utendaji wa kisemantiki unaopatikana kwa jamii, tutaona ongezeko la utendaji wa kisarufi kwa 50%.
WE2.2.17	Ikiwa tutatoa kipengele maalum cha kutazama taarifa za Wikidata kwenye Wikifunctions, watumiaji wataweza kuelewa zaidi data inayoletwa kutoka Wikidata na kuhisi kutolemewa sana.
WE2.2.18	Iwapo tunaweza kuzuia ongezeko la matumizi ya kumbukumbu mara 10, mwandalizi ataweza kushughulikia vyema viumbile vya Wikidata, kusaidia matumizi ya Wikifunctions kama jukwaa la Abstract Wikipedia.
WE2.2.19	Ikiwa tutawawezesha watumiaji kushiriki viungo vya moja kwa moja vya wito mahususi wa utendakazi - ikiwa ni pamoja na michango yao - wachangiaji wataweza kuzalisha, kuthibitisha, na kujadili tabia ya utendakazi kwa urahisi zaidi, ambayo nayo itaharakisha utatuzi, kuboresha utiririshaji wa kazi za majaribio, na kusaidia utatuzi wa matatizo shirikishi kote katika jumuiya ya Wikifunctions.
WE2.3.1	Ikiwa tutakamilisha uamuzi wa kuunda wiki mpya na kuamua juu ya jina na jumuiya, tutaweza kushirikiana kwa upana zaidi uundaji wa wiki hii mpya na wadau wetu na kujiandaa kwa ajili ya uratibu wa mabadiliko yanayowezekana ya jina la bidhaa.
WE2.3.2	Tukifafanua MVP kwa mfano wa Wiki ya Abstract ambayo inajumuisha uzoefu wa kiwango cha chini kabisa kwa ajili ya kujaribu uwezo wetu wa muundo wa nyuma ya mfumo na NLG, na kuturuhusu kubuni mara kwa mara, tutaweza kupanga na kuzindua mfano wa moja kwa moja katika Q3.
WE2.3.3	Tukianza kuzungumza na jumuiya na kuchunguza miundo inayoweza kutumika kwa ajili ya matumizi ya mtumiaji wa Wiki ya Abstract, tutaweza kuendeleza kazi katika Q3.
WE2.4.1	Ikiwa tutakusanya matukio ya matumizi ya masuala ya Wikidata na WDQS kutoka kwa timu za WMDE na WMF, tutaweza kufafanua mahitaji ya bidhaa kwa ajili ya uboreshaji wa miundombinu.
WE2.4.2	Iwapo tutatoa mtazamo wa kuripoti uliojumlishwa viashirio muhimu vya utendakazi (KPIs) na malengo yaliyopo ya kiwango cha huduma (SLOs) kwa Wikidata na WDQS, tutaweza kueleza na kufuatilia vigezo vya mafanikio vya uboreshaji wa miundombinu ya kiufundi inayosaidia suala muhimu la matumizi ya Wikidata.
WE2.4.3	Kama tunaweza kutathmini na kuainisha hifadhi mbadala kwa Blazegraph kwa kutumia vigezo vya uhalisia wa uzalishaji ndani ya robo hii, tutaweza kufanya uamuzi wa uhamiaji unaoendeshwa na data na kueleza ramani thabiti iliyo na ratiba ya matukio na mahitaji ya rasilimali.
WE3.1.1	Tukijaribu A/B toleo lililoboreshwa la kipengele cha kuvinjari cha Vichupo, tutaona ongezeko la 5% la matumizi ya siku nyingi miongoni mwa watumiaji wa Vichupo.
WE3.1.3	Iwapo tutatoa njia mpya kwa watumiaji kuvinjari maudhui ya picha husika ndani ya kurasa za makala, na kuijaribu kwa kikundi kidogo cha visomaji vilivyotoka kupitia jaribio la A/B kwenye seti ya wiki, tutaona angalau kiwango cha kubofya cha 3% kati ya watumiaji ambao wamewasilishwa kwa kipengele hiki.
WE3.1.4	Ikiwa tutaonyesha wasomaji dhana kadhaa za kwa ajili ya kupitia mtandao wa maarifa kwenye wiki, tutachukua orodha iliyopewa kipaumbele ya dhana kwa maendeleo zaidi.
WE3.1.5	Iwapo tutawapa wasomaji wa wavuti chaguo la kuona toleo lililotafsiriwa kwa mashine la maudhui ya Wikipedia ambayo hayapatikani katika lugha yao, tutajifunza kama shughuli ya kusoma itaongezeka, ikipimwa kama ongezeko la 3% la mwingiliano wa kurasa, kuwavuta wasomaji kwenye wiki ya lugha ya ndani yenye uwezekano wa ongezeko la shughuli za uhariri wa ndani. Hii itatolewa kama mpangilio wa majaribio ya A/B unaodhibitiwa kwa muda usiozidi miezi 6, na katika Wikipedia 13 kwa idhini ya awali, kwa kutumia huduma za utafsiri za mashine wazi ambazo tayari zinapatikana kwa wahariri wa Wikipedia.
WE3.1.6	Kama tutatoa mfano wa utafutaji wa kisemantiki na Maswali na Majibu ya ndani ya kifungu, uliyotolewa kama kikusa cha onyesho kinachotofautisha mbinu ya sasa na mbinu mpya za uchunguzi, basi timu za Reader zitaweza kutathmini kimaelezo jinsi kila mbinu inavyofanya kazi katika safari tofauti za watumiaji na mapungufu ya juu au fursa za kurudiwa zaidi.
WE3.1.7	Tukipitia utafiti uliopo kuhusu jinsi wasomaji wanavyoingiliana na zana za utafutaji na urambazaji kwenye Wikipedia, na jinsi wanavyotumia utafutaji wa nje kupata maarifa kwenye Wikipedia, tutaweza kuzipa timu za Reader ≥3 mapendekezo na matokeo yanayoweza kutekelezwa ambayo yanazisaidia kupanua utafutaji na ugunduzi wa MVP ili kushughulikia mapengo katika matarajio na mahitaji ya wasomaji.
WE3.1.8	Tukitathmini miundo 2 ya utafutaji ya kimantiki (utafutaji wa lugha asilia, Maswali na Majibu) na washiriki wa nje, tunaweza kujifunza kama watumiaji wanaona thamani katika zana za utafutaji zilizoboreshwa, na kuzipa timu za Wasomaji pendekezo la jinsi ya kusonga mbele na MVP ya utafutaji na ugunduzi.
WE3.1.9	Iwapo tutaonyesha dhana za muundo wa uaminifu wa hali ya juu za ugunduzi wa maudhui kupitia utafutaji wa kimaana kwa wasomaji 10-20 wa Wikipedia wa kawaida katika utafiti wa kimaelezo, tutaona hisia chanya kwa kipengele hiki na kupata ujasiri unaohitajika ili kuendelea na utafutaji na ugunduzi wa MVP ambao unategemea dondoo fupi zilizoandikwa na binadamu kutafuta maswali.
WE3.1.10	Tukionyesha wasomaji 10 wa kawaida mfano wa moja kwa moja wa hali mpya ya kuvinjari picha katika utafiti usiodhibitiwa wa mtumiaji, tutagundua angalau uboreshaji mmoja wa UX kwa marudio ya kipengele cha siku zijazo.
WE3.1.11	Ikiwa tutalegeza ulinganifu wa maneno muhimu katika Utafutaji, basi tutatumia vyema maswali ya lugha asilia, na kuwezesha Bidhaa kutathmini uwezo huu, kuujumuisha katika jinsi wanavyosanifu, kuweka kipaumbele na kutoa kazi katika nafasi ya Utafutaji wa Maana.
WE3.1.14	If we launch an A/B test of a version of the mobile site which introduces navigation that opens all sections by default, we will see early indicators that signal towards an increase in session length (will report on full A/B test results in Q3)	T409163
WE3.2.5	Tukianzisha kipengele cha Maoni ya Mwaka kwenye Android ambacho huangazia athari za mtumiaji na kujumuisha ujumbe jumuishi wa wafadhili, tutaendeleza tabia mpya ya uchangiaji—na tutaona ongezeko la 5% la menyu ya programu ikilinganishwa na 2024.
WE3.2.6	Ikiwa tutatoa slaidi za wafadhili katika Mwaka wa Mapitio wa iOS, zikiwa zimeunganishwa zaidi, na za kibinafsi, tutaona ongezeko la 5% la michango ikilinganishwa na 2024.
WE3.3.3	Tukitambulisha angalau avatar moja ambayo inaweza kufunguliwa katika programu ya Android kwa wamiliki wa akaunti—iliyopatikana kupitia vitendo vya maana vya usomaji kama vile kuhifadhi idadi fulani ya makala — tutaongeza ushiriki unaorudiwa na vitendo vinavyohusishwa na watumiaji walioingia kwa 10% kwa siku nyingi.
WE3.3.4	Ikiwa tutawapa wasomaji walioingia katika akaunti uwezo wa kuhifadhi makala kwenye orodha ya faragha ya usomaji, tunatarajia ushiriki kwenye tovuti utaongezeka, kama inavyopimwa na ongezeko la 5% la trafiki ya rufaa ya ndani kwa wasomaji wanaotumia kipengele, na ongezeko kubwa la takwimu kwa watumiaji wote.
WE3.3.6	Iwapo tutafanya data ya makisio ya mada ya makala ipatikane kupitia huduma ambayo inakidhi mahitaji yaliyokubaliwa ya uwekaji na upatikanaji, pamoja na ujazo wowote muhimu wa data, basi tutakuwa tumeanzisha msingi wa kiufundi unaohitajika ili kusaidia matumizi yajayo ya msomaji ya kibinafsi ambayo yanategemea data hii.
WE3.3.7	Iwapo tutaboresha uwezo wa uchakataji wa mfumo wa data ili kujumlisha vipimo vilivyoboreshwa vya kihariri na data ya athari na kutoa data iliyojumlishwa kupitia huduma zinazofaa na SLO zilizobainishwa, tunaweza kuboresha marudio ya Mwaka katika Maoni WE3.3.1 na Kichupo cha Shughuli WE3.3.2.
WE3.3.9	Kama tutatoa Year in Review kwenye Android na jaribio la A/B yakiwapa watumiaji wanaojishughulisha zawadi ya kuhifadhi orodha maalum ya usomaji, tutaona ongezeko la 1% la kiwango cha jumla cha uhifadhi wa programu tumizi kati ya wasomaji waliyopewa zawadi ikilinganishwa na wale ambao hawakupewa.
WE3.3.10	Kama tukifanya kipimo cha A/B na kuhitaji akaunti ili kuona maarifa ya kusoma yakibinafsi ya Year in Review, tutaona ongezeko la 1% la jumla ya asilimia ya uhifadhi wa watumiaji ambao walihitajika kuwa na akaunti, ikilinganishwa na wale ambao hawakuwa na akaunti.
WE3.3.11	Kama tutafanya kipimo cha A/B toleo lililoboreshwa la kichupo cha "Shughuli" kwenye iOS ambalo huangazia usomaji, uhariri na tabia zingine za ushiriki, tutaona ongezeko la 5% la kutembelewa kwa siku nyingi kwa wasomaji walioingia kwenye kichupo ikilinganishwa na toleo la mfano.
WE3.4.1	Iwapo tutafanyia kazi sehemu ya mseto ya uwepo wa utumiaji wa (PoP/CDN), itaturuhusu kuleta PoP kamili na PoP ndogo (jisimu na wingu) kama inavyohitajika, na kuweka msingi wa uwekaji wa mfano mdogo wa PoP katika siku zijazo.
WE3.5.1	Ikiwa Bidhaa na Teknolojia na Uchangishaji Pesa zitatathmini kwa pamoja na kuweka kumbukumbu za mbinu za kiufundi za kutambua wafadhili ndani ya majukwaa yetu, tutaweza kupendekeza suluhisho la muda mfupi na la muda mrefu ambalo linasawazisha faragha, uwezekano na athari. Uelewa huu ulioshirikiwa utasaidia kupanga maamuzi, kuwezesha utambuzi wa wafadhili unaoendelea kwenye majukwaa yote, pamoja na majaribio yaliyolengwa zaidi katika vipengele vinavyohusiana na uchangishaji fedha siku zijazo.
WE3.6.3	Ikiwa tutashirikisha jumuiya katika mazungumzo kuhusu mahitaji yanayoendelea ya wasomaji, na kuhusu mabadiliko ya asili ya maarifa kwenye mtandao, tunaweza kujenga mtazamo wa pamoja wa jinsi ya kuwahudumia wasomaji na kufanya kazi pamoja kuhusu kama na jinsi ya kujaribu mawazo yetu mbalimbali (ikiwa ni pamoja na wale walio karibu na mediatutiko, utafutaji na ugunduzi, na kujifunza kwa mashine).
WE3.6.4	Ikiwa tutatafiti motisha tofauti, mienendo na mahitaji mahususi nyuma ya lini, kwa nini na jinsi wasomaji wanavyotumia Wikipedia na majukwaa mengine ya maarifa, tutaweza kupendekeza maeneo ya kipaumbele na mipango mahususi ya mkakati wa watumiaji.
WE3.6.5	Ikiwa Idara ya Bidhaa na Teknolojia na Idara ya Uchangishaji Fedha zitashirikiana katika mkakati wa pamoja wa kuongeza fursa mbalimbali za uchangiaji fedha kupitia mifumo ya mtandaoni na kuwatambua wasomaji wanaochangia, tutaweka malengo na vipimo vilivyo wazi na vilivyounganishwa ambavyo vimefungamanishwa na mikakati yetu ya walaji na uchangishaji fedha.
WE3.6.6	Tukitengeneza mkakati wa umoja wa kipimo, tutawezesha kutathminiwa kwa mkakati wa miaka mingi wa watumiaji na kufafanua ramani ya mwongozo ya kuendeleza vipimo na uwezo wa kuripoti.
WE4.1.1	Iwapo tutaiga mtiririko usio wa dharura unaoweza kutumika kwa kiasi kidogo, na kuweka wazi kitanzi cha maoni cha kurudia tunapoyatengeneza na watumiaji walio na haki za ziada, basi vikundi hivi vitasaidia uenezaji zaidi wa mtiririko huu.
WE4.1.3	Iwapo tutasasisha Wikipedia 7 (Kifaransa, Kijerumani, Kihispania, Kihungari, Kiitaliano, Kipolandi, Kireno) kufikia mwisho wa Oktoba, tutakamilisha awamu ya 1 ya utekelezaji wa Sehemu mpya ya chini ya ukurasa wa Kisheria iliyoanzishwa kukidhi mahitaji ya DSA.
WE4.1.4	Tukipeleka MVP ya Mfumo wa Kuripoti Matukio kwa angalau wiki 15, kwa kulenga jumuiya kubwa zaidi changamano, tutaona kuwa inatumiwa kama ilivyokusudiwa na jumuiya, na tutakuwa tumeonyesha mtindo wa kufanya kazi wa kuripoti matukio yasiyo ya dharura.
WE4.1.5	Tukibuni mchoro wa mtiririko wa kuripoti matukio ya unyanyasaji kwa wiki bila taratibu zilizowekwa za kushughulikia matumizi mabaya, hii itahimiza kupitishwa kwa Mfumo wa Kuripoti Matukio kwenye wiki kama hizo na kuwawezesha watumiaji kwenye wiki hizo kuwa na njia ya usaidizi iliyo wazi na inayoweza kutumika.
WE4.2.3	Tukichanganua data kutoka kwa jaribio la kuunda akaunti ya hCaptcha, tutaelewa njia ya kufungua akaunti, ufanisi wa mafumbo na alama za hCaptcha, na kuwa na data inayohitajika ili kufahamisha uchapishaji zaidi wa hCaptcha kwenye ufunguaji akaunti.
WE4.2.5	Ikiwa tutafanya utafiti, kushauriana na jumuiya, na kuchunguza suluhu za kiufundi, tutaweza kufafanua seti ya sababu zilizopangwa za kuzuia ambazo zinaweza kutumika katika wiki zote za WMF.
WE4.2.6	Tukikuza uwezo wa kuweka makundi kulingana na OpenSearch kwenye Jukwaa la Data, timu za uhandisi wa vipengele vya bidhaa zitawezeshwa kuunda mifumo inayounganisha uwezo huu, kwa uhuru, uthabiti na kutengwa na mifumo mingine inayotegemea utafutaji. Mpangaji wa kwanza na mkuu wa mfumo huu atakuwa huduma ya IPoid.
WE4.2.7	Tukifanya ujumuishaji wa hCaptcha Enterprise kwenye Wikipedia kadhaa za uzalishaji kama jaribio la awali, tutaweza kukusanya data kuhusu ufanisi na thamani ya hCaptcha Enterprise juu ya kupambana na matumizi mabaya, utambuzi wa roboti, utumiaji na ufikiaji.
WE4.2.8	Tukiweka tayari uzalishaji wa seva mbadala ya hCaptcha kwa kuboresha upatikanaji na uangalizi wake, tutakuwa tukitoa huduma thabiti na ya kuaminika kwa Wikipedia za uzalishaji katika Q1.
WE4.2.9	Tukiunganisha SDK ya hCaptcha kwenye programu asili za vifaa vya mkononi, kutathmini hali ya mtumiaji wa programu asilia na kutathmini kuwezesha changamoto za hCaptcha kama sehemu ya API ya kuunda akaunti, tutakuwa na uelewa wa kutosha ili kufahamisha Utolewaji zaidi wa hCaptcha kwa API ya kuunda akaunti.
WE4.2.11	Kama tukiiwezesha hCaptcha kwa ajili ya kugundua roboti katika hali hatari zaidi za uhariri, tutaona kuwa hCaptcha inaweza kupunguza matumizi mabaya ya kiotomatiki.
WE4.2.16	Tukishauriana na timu husika za WMF, Tutaweza kuunda mpango uliokubaliwa wa kudhibiti ufikiaji wa kina zaidi wa mtumiaji kwa data isiyo ya umma, na kusaidia utumiaji wa sheria za kinga za programu zisizo za umma.
WE4.2.17	Tukichanganua mifano ya ulimwengu halisi na kuwahoji CheckUsers ili kubaini angalau ishara 2 za tabia mbaya inayoweza kutokea kutoka kwa mfano wa historia ya wahariri, timu ya Usalama na Uadilifu wa Bidhaa itaweza baadaye kujumuisha mawimbi haya kwenye kipengele cha Uchunguzi Unaopendekezwa kwa kiwango cha juu cha uhakika kwamba mawimbi yatatoa thamani.
WE4.3.2	Ikiwa tutatumia alama za vidole za JA4H, ambazo ni muhtasari wa tabia ya mteja wa HTTP, tutaweza vyema kutambua na kuainisha trafiki ya roboti.
WE4.4.1	Ikiwa tunaweza kufanya maboresho kulingana na maoni ya majaribio na kupeleka Akaunti za Muda kwa miradi yote tutaweza kulinda ufichuaji wa taarifa zinazotambulika kibinafsi (anwani za IP) za watumiaji ambao hawajasajiliwa kwenye miradi yetu yote ili zipatikane kwa chini ya 0.1% ya watumiaji wote (waliosajiliwa)
WE4.4.2	Ikiwa tutawasiliana na wadau husika wa harakati (pamoja na jumuiya za wiki na watendaji wa kimataifa) kwa uwazi na kwa wakati, tutaweza kutumia kwenye Wiki zote zilizosalia, kupunguza mzigo wa kazi uliogunduliwa katika dakika ya mwisho, na kuepuka kurudisha nyuma utumiaji.
WE4.4.5	Tukipunguza msuguano kwa wafanya doria kutambua watendaji wabaya wanaotumia akaunti za muda kuharibu, tutaweza kuzuia ongezeko la uharibifu kwa kupima hakuna ongezeko la kiwango cha kurejesha katika wiki zote zilizo na akaunti za muda.
WE4.4.6	Tukisitisha kiendelezi cha LiquidThreads, tutafungua Akaunti za Muda zinazotumwa kwa miradi yote inayotumia kiendelezi hiki kwa sasa.
WE4.6.1	Tukiweka kiotomatiki mchakato wa kusawazisha akaunti ndani ya Zendesk kwa kuweka upya nywila, hii itapunguza mzigo kwenye T&S na kuwaruhusu kushughulikia maombi zaidi yanayokuja ya uwekaji upya wa 2FA.
WE4.6.3	Tukiruhusu watumiaji wote walio na anwani ya barua pepe iliyothibitishwa waweze kuwasha 2FA kwa akaunti zao, lakini tusitangaze mabadiliko haya kwa watumiaji, mzigo wetu wa dawati la usaidizi wa urejeshaji utasalia katika kiwango endelevu.
WE4.6.4	Ikiwa tutaendelea na urekebishaji wa matumizi ya mfumo wetu wa 2FA, na kuongeza usaidizi kwa nywila, basi watumiaji zaidi watasajili vipengele vingi vya uthibitishaji na kulindwa vyema dhidi ya kupoteza ufikiaji wa akaunti.
WE4.6.5	Iwapo tutabuni na kuunda mfumo wa jumla wa kubainisha mahitaji ambayo washiriki wa kikundi cha ndani au kimataifa wanapaswa kutimiza, tutatumia mfumo huu kutekeleza kwamba washiriki wa kikundi cha mwangalizi wa-ip-za akaunti-ya muda watimize mahitaji yaliyopo ya sera.
WE4.6.6	Iwapo tutatafiti jinsi watumiaji walio na haki za ziada (UWER) wanategemea Hati za Mtumiaji, tutaweza kupendekeza mpango, ambao jumuiya ya UWER inaweza kuunga mkono, kufanya uingiliaji kati muhimu wa kiufundi mmoja au zaidi ambao unaweza kulinda mfumo wa Hati za Mtumiaji.
WE4.6.7	Iwapo tutatathmini hali ya mtumiaji na mabadiliko ya kiufundi yanayohitajika kwa programu asilia za vifaa vya mkononi ili kuoanisha utumiaji wa kuingia katika akaunti ya simu ya mkononi na mfumo wa wavuti, kupitia kuchunguza mbinu mbadala kama vile OAuth, tunaweza kubainisha uwezekano wa ujumuishaji, kwa maslahi ya kutoa matumizi salama na thabiti zaidi kwa watumiaji.
WE4.6.8	Iwapo tutafuatilia athari za fomu za Zendesk na MediaWiki tulizounda katika Q1, basi tunaweza kupendekeza uingiliaji kati wa kiufundi kwa robo za siku zijazo ambazo zitafanya vizuri zaidi mchakato uliosalia wa kurejesha akaunti.
WE5.1.2b	Tukiunganisha mbinu nyingi za utambulisho na uthibitishaji wa wasanidi programu katika lango la API, tutaweza kuweka kikomo cha kiwango kinachofaa kwa kila ombi, kwa kutambua kwa usahihi maombi yanayotoka kwa makundi mbalimbali ya watumiaji.
WE5.1.3b	Tukifanya jaribio la awali la upunguzaji wa kazi ya maombi kwenye angalau njia 3 za lango la REST, hii itaturuhusu kuthibitisha upembuzi yakinifu wa kikwazo cha viwango kuhusiana na matumizi ya rasilimali na kufafanua seti ya awali ya vikomo ambavyo vinaweza kutekelezwa kwa athari ndogo ya mtumiaji.
WE5.1.4b	Tukithibitisha mbinu zinazopendekezwa za utengaji wa watumiaji wa API kwa seti pana za data na upitiaji wa mikono wa vikundi vilivyotambuliwa, tutaweza kukamilisha makundi ya watumiaji, kuboresha mbinu zinazotumiwa kuhesabu, na kuelewa vyema utendakazi wao.
WE5.1.5	Ikiwa tutashirikiana na timu ya Jukwaa la MediaWiki kuhusu utambulisho wa trafiki na upunguzaji wa viwango, tutaweza kutekeleza udhibiti kasi ya trafiki ya mtandao kwa ajili ya majaribio ya awali katika uzalishaji, kwa kusaidia timu ya Mfumo katika uundaji na utekelezaji wa uwezo huu.
WE5.2.1b	Tukishirikiana na watumiaji watarajiwa wa Kivinjari kipya cha REST API, hii itatusaidia kutambua maarifa muhimu ya utumiaji ambayo yanaonyesha kama muundo mpya ni rahisi kutumia na kulinganishwa na muundo wa akili wa wasanidi programu.
WE5.2.2b	Tukielekeza Action API kupitia lango kuu la API, tunaweza kuanza kupima trafiki na mifumo ya matumizi kila mara ili kupata maarifa ambayo yataarifu maamuzi na vitendo vya siku zijazo.
WE5.2.4	Kama tutatekeleza mifumo ya kawaida ya uhifadhi wa API 2, tutaweza kuboresha miongozo ya maudhui, kuelewa kile ambacho wamiliki wa API wanahitaji ili kupitisha miongozo hiyo, na kubainisha juhudi zinazohitajika ili kutekeleza miongozo kwenye hati zilizosalia za API za Wikimedia.
WE5.2.5	Tukijaribu kufafanua na kutumia sheria za ukaguzi wa vipimo vya OpenAPI kwenye API za MediaWiki RESTI, tutaonyesha njia ya kutekeleza kiprogramu miongozo ya mitindo ya API ili kuboresha ubora na uthabiti wa API zilizochapishwa kote kwenye Wikimedia na jumuiya zetu.
WE5.3.1	Tukipanua na kurahisisha miongozo ya utambuzi wa UX huku tukisasisha miongozo yoyote iliyopo,tutaanzisha seti kuu ya miongozo iliyoboreshwa tayari kwa majaribio ya ndani na uboreshaji wa mara kwa mara ili iweze kutumiwa na umma kwa upana zaidi.
WE5.3.1b	Tukichapisha na kuboresha miongozo ya awali ya UX na maonyesho, tutaanzisha mfumo mkuu ulio tayari kujaribiwa ndani na kuboreshwa hatua kwa hatua ili kuwa tayari kwa matumizi mapana ya umma.
WE5.3.2	Tukiunda wasilisho linaloonyesha manufaa ya kutaja Wikipedia kwa wanaotumia tena maudhui ya wahusika wengine na watumiaji wao wa mwisho, tunaweza kusaidia WME4.1 & WME4.2 kwa kumwezesha angalau mshirika mmoja wa ziada wa matumizi ya kurudia maudhui kukubali kuonekana katika uchunguzi kifani wa utajaji au onyesho ifikapo mwisho wa Q1.
WE5.4.2b	Iwapo tutaunda njia kubwa ya kutambua wateja wanaojulikana, tunaweza kuruhusu vizuizi vya viwango vya jumla vya roboti za asili iliyothibitishwa, na kuelekea kwenye utekelezaji wa utaratibu wa sheria zetu.
WE5.4.5	Iwapo tutaanza kutekeleza mipaka ya viwango iliyoundwa mahsusi kwa aina tofauti za wateja binafsi, tutapunguza mzigo wa upakuaji wa data kwenye miundombinu yetu.
WE5.4.6	Iwapo kufikia mwisho wa Q2 tutakuwa tumetambua roboti wakuu wa N kama roboti roboti wanaojulikana, tutaweza kudhibiti kiasi cha rasilimali wanazotumia.
WE5.4.7	Ikiwa tutazingatia seti sanifu za ukubwa unaoruhusiwa wa vijipicha kwenye miundombinu ya maudhui yetu, na tukatayarisha zile za bei ghali zaidi huku tukiweka kikwazo cha uzalishaji wa ukubwa tofauti wa picha, tutapunguza mzigo kwa miundombinu inayohudumia vyombo vya habari.
WE6.1.2	Tukiongeza wikifarms kwenye mazingira ya majaribio ya kabla ya kuunganisha hii itawezesha timu za maendeleo zinazojenga dhidi ya uzalishaji ambazo zinahitaji Wiki nyingi kupima visasisho vyao kwa kutengwa na kuzipa imani kubwa zaidi ya utayarishaji wa awali na kusababisha kuepuka kasoro chache.
WE6.2.1	Tukikagua na kuchapisha Orodha yetu ya Kujitayarisha kwa Uzalishaji ambayo inafafanua kwa uwazi sharti la huduma itakayochukuliwa kuwa tayari kwa uzalishaji, pamoja na kazi zinazoweza kujiendesha, tutapanga matarajio kati ya SRE na timu za uendelezaji, kuboresha ufanisi wetu wa jumla wa uendeshaji na uwezo wa kuongezeka.
WE6.2.2	Tukitangaza kuunda maktaba ya Golang na nodejs inayoondoa kazi nyingi ngumu kwa wasanidi programu, watatujibu wakitoa maoni na mambo yanayowavutia.
WE6.2.4	Tukituma ombi, na kuunga mkono kwa dhati ukaguzi wa muundo wa Kudumu kwa Data, tunaweza kutambua njia zilizojengwa kwa ajili ya uzalishaji.
WE6.3.2	Tukitengeneza vipimo vipya, kuboresha miundombinu ya akiba ya Parsoid, na kutumia wikipedia mbili za "kumi bora", tutaunda vigezo vya utendaji vya mfumo wa uaminifu, ambao utasaidia kuthibitisha utayari wetu wa utumiaji kwa wiki nyingine kubwa na kuonyesha uwezo wetu wa kushughulikia viwango vya trafiki kwa kiwango kikubwa.
WE6.3.3	Tukitekeleza uboreshaji muhimu wa Usaidizi wa Lahaja ya Lugha tofauti na kusambaza Parsoid kwa angalau Wiki 3 za Kibadala cha Lugha katika Q2, tutatambua na kutatua changamoto kuu za kiufundi zinazohitajika ili kusambaza kwa ujasiri Wiki zote za Kibadala cha Lugha.
WE6.4.6	Iwapo SRE itatoa usaidizi kwa timu za uhandisi za MediaWiki - kupitia uwezo na usimamizi wa trafiki, utayarishaji na ukaguzi wa mabadiliko ya usanidi, na ushirikiano ili kuchunguza na kutatua matatizo - kwa pamoja tutakamilisha sasisho la uzalishaji wa PHP 8.3 katika Q2 na kuweka kumbukumbu za mapendekezo ili kupunguza utegemezi wa njia muhimu kwenye SRE kwa masasisho yajayo.	T360995
WE6.4.7	Ikiwa tutahamisha angalau 90% ya watumiaji wote walio na ufikiaji wa mizizi duniani kote ili kutumia ufunguo wa SSH unaoungwa mkono na maunzingumu kufikia seva za uzalishaji za Wikimedia, tutapunguza hatari kwamba kompyuta ndogo iliyoathiriwa itasababisha ukiukaji mkubwa wa usalama.
WE6.4.8	Ikiwa Timu ya Uhandisi ya MediaWiki itafuatilia na kurekebisha masuala katika MediaWiki kikamilifu yanayohusiana na uboreshaji wa PHP, hii itawezesha timu ya SRE kukamilisha uboreshaji wa PHP 8.3 kufikia Novemba 2025.	T360995

Nadharia tete ya Ishara na Huduma za Data (SDS) [ Matokeo Muhimu ya SDS ] Majadiliano
Jina fupi la nadharia tete	Maandiko ya Q2	Maelezo na Majadiliano
SDS1.2.1	Tukihamisha mchakato wa XML Dumps kutoka kwa miundombinu ya sasa ya 'Dumps 1' hadi bomba la data linalotumia Mabomba ya Maudhui ya MediaWiki tutaweza kudhamini SLO na kuzima uhamishaji wa XML unaotegemea 'Dumps 1'.
SDS1.2.2	Tukifanya mapitio na kukagua SLO za Historia ya Maudhui ya MediaWiki na Jukwaa la Tukio/Lango la Tukio, tunaweza kuthibitisha wateja, vipimo na wadau tegemezi, na kutambua maboresho ambayo yanaweza kuhitajika kwa SLO, ambayo yatatusaidia kufafanua mapengo yoyote katika dhamana zetu za kila wiki za uwasilishaji.
SDS1.3.1	Ikiwa tutaanzisha ishara za upande wa mteja na kuzikagua kwa kulinganisha na kumbukumbu za ombi la tovuti la upande wa seva, tutapata miundo ya ziada ya roboti ambayo inaweza kubainishwa.
SDS1.3.2	Iwapo tutachukulia kuwa usambazaji wa sasa wa roboti dhidi ya binadamu kama msingi na kuunda tahadhari za kiotomatiki za mabadiliko katika usambazaji, tutapunguza muda wa utambuzi wa muundo unaofuata usiotarajiwa wa trafiki otomatiki kutoka wiki hadi dakika.
SDS1.3.3	Tukiweka kiotomatiki utaratibu wa kujaza ombi la wavuti na kuutumia kwenye kumbukumbu za Mei, tutapunguza muda wa urekebishaji wa matukio yajayo kutoka miezi hadi siku na kutatua tukio la "kuongezeka kwa mara ambazo kurasa zimetazamwa Mei".
SDS1.3.4	Ikiwa tutaunda mchakato wa ukaguzi wa ndani wa mara kwa mara, unaoendeshwa kwa matokeo ya uainishaji wa roboti, tutajenga imani katika masuluhisho yetu na kutarajia mabadiliko katika mifumo ya trafiki ambayo haitatambuliwa kiotomatiki.
SDS1.3.5	Tukichanganua ishara ya msingi ya upande wa mteja na kuijumuisha kwenye utabiri wetu, tutagundua mifumo ya ziada ya roboti katika Mfumo wa Data.
SDS1.3.6	Tukiingiza, kuchambua na kujumuisha katika ufahamu wetu sifa ya IP ya Spur.us, tutagundua mifumo ya ziada ya roboti katika Mfumo wa Data.
SDS1.3.7	Ikiwa tutaingiza, kuchanganua na kujumuisha ishara moja kutoka ukingo katika mfumo wetu wa kuhesabu data, tutagundua mifumo ya ziada ya roboti katika Mfumo wa Data.
SDS1.4.1	Tukithibitisha upya uchanganuzi uliopo wa mitindo ndani ya mfumo ikolojia wa Wikimedia - mara ambazo kurasa zimetazamwa, vipimo vya wachangiaji na wasomaji, trafiki, n.k. - tutaweza kuunga mkono kwa ujasiri hoja kuu za mazungumzo kwa maarifa yetu muhimu zaidi ya harakati.
SDS1.4.2	Tukithibitisha upya uchanganuzi uliopo wa mitindo ndani ya mfumo ikolojia wa Wikimedia - mara ambazo kurasa zimetazamwa, vipimo vya wachangiaji na wasomaji, trafiki, n.k. - tutaweza kuunga mkono kwa ujasiri hoja kuu za mazungumzo kwa maarifa yetu muhimu zaidi ya harakati.
SDS2.1.1	tukioanisha kwa karibu na timu zinazoendesha majaribio, tutajifunza jinsi ya kufanya mfumo ujihudumie zaidi katika siku zijazo na ni changamoto zipi za kimawazo au za kiufundi ambazo wanaweza kukabiliana nazo.
SDS2.1.2	Ikiwa tunaweza kutekeleza utatuzi bora zaidi wa uwekaji kumbukumbu za matukio, basi timu za bidhaa zitajua kuwa jaribio lao linakusanya data ya matukio kama inavyotarajiwa, na hivyo kuongeza imani ya wamiliki wa majaribio.
SDS2.1.3	Tukiboresha ukataji miti na uangalizi wa kijenzi cha mfumo wa majaribio wa A/B (xLab) wa jukwaa la majaribio, na kwa sehemu zake zinazohusiana za MediaWiki, tutaweza kuweka misingi ya utendaji wa mfumo na kujibu mapungufu yanayohusiana na majaribio.
SDS2.1.4	Ikiwa tutashiriki hadithi za majaribio na matokeo katika shirika mara moja kwa mwezi (kupitia mikutano ya Watendaji wa Bidhaa, mikutano ya timu ya Usanifu, na mawasilisho ya timu mbalimbali), kisha tutawesesha watumiaji kuanza kutumia jukwaa la majaribio kwa njia ya kawaida na ya hiari.
SDS2.1.5	Tukiwaambia watumiaji kuwa zana yao, ikiwa imeundwa katika xLab, ina kundi la sifa zinazobadilisha kundi la hatari, tutazuia watumiaji wa zana kutoka kwa kukusanya data kupita kiasi na kuongeza uwazi kuhusu mchanganyiko wa sifa gani unahitaji ukaguzi wa faragha.
SDS2.1.6	Iwapo Timu ya Ukuaji itafanya kazi katika kutumia visa 2 (kimoja kikiwa na jaribio la A/B ili kupata maarifa kuhusu uwezo wa kuweka makundi, na kimoja kikiwa na zana za muda mrefu ili kujifunza kuhusu usaidizi wa vipimo vinavyofanana na KPI) kwa kutumia Maabara ya Majaribio, basi tunaweza kutathmini kama inatimiza mahitaji ya kuchukua nafasi ya usanidi wetu wa majaribio tuliyoiweka katika GrowthExperiments.

Nadharia tete za Hadhira ya Baadaye (FA). [ Matokeo Muhimu ya FA ] Majadiliano
Jina fupi la nadharia tete	Maandiko ya Q2	Maelezo na Majadiliano
FA1.1.4	[Imeendelea kutoka Mwaka wa Fedha uliyopita] Ikiwa tutaunda matumizi mapya ya Wikipedia kwenye Roblox, tutajifunza ikiwa hii inaweza kuwa njia mwafaka ya kutambulisha chapa yetu kwa hadhira ya vijana (Gen Alpha).
FA1.1.2	Iwapo tutaunda hebu kuu ya matumizi uzoefu mpya wa Wikipedia kwenye itch.io, basi tutaweza kuongeza hadhira ya > watu 50 wasio Wanawikipedia wanaovutiwa wakitupa maoni, ambayo yatatusaidia kujifunza kinachofaa na kisichofanya kazi katika michezo.
FA2.2.1	Ikiwa tutawekeza katika usimamizi wa jumuiya kwenye majukwaa ya video fupi, basi kufikia mwisho wa Q2 (Desemba 2025) tutaona ongezeko la 30% la QoQ katika asilimia ya utazamaji ambazo Watazamaji Wapya kwenye TikTok - na kwenye majukwaa yote ya SFV, tutapata jumla ya miamala 50,000 (ya kupenda na kujibu maoni) kwenye maoni yaliyoachwa kwenye maudhui ya nje, ambayo itatusaidia kuongeza mwonekano wa chapa kwa sasa.
FA2.2.2	Tukitengeneza na kujiondoa kwenye Mpango wa Ushirikiano wa Waundaji wa Wikipedia mkakati wa ndani na unaoweza kushirikiwa kutoka nje (pamoja na muhtasari wa thamani yetu kwa waundaji, vigezo vya ushirika, mchakato wa mkataba na jinsi maudhui ya waundaji yatakavyoonekana katika vituo vinavyomilikiwa na waundaji), tutaweza kuanzisha mkakati thabiti wa waundaji ambao utatusaidia kufikia hadhira mpya kwenye mitandao ya kijamii na maudhui yetu ya maarifa.

Nadharia tete za Usaidizi wa Bidhaa na Uhandisi (PES). [ Matokeo Muhimu ya PES ] Majadiliano
Jina fupi la nadharia tete	Maandiko ya Q2	Maelezo na Majadiliano
PES1.1.5	Ikiwa tutaingia kwenye malengo ya kiwango cha huduma (SLO) kwa Historia ya Maudhui ya MediaWiki na Wikifunctions hadi Sloth/Pyrra, tutaweka SLO 2 zaidi katika uzalishaji.
PES1.1.6	Iwapo tutajaribu Sloth kwa kutumia data inayorejea kutoka kwa SLO zilizopo, tutaelewa kama Pyrra au Sloth (au kitu kingine) ndiyo zana inayofaa kwa mbinu yetu ya dirisha lisilobadilika ya makosa ya madirisha ya bajeti. Tutajifunza kuhusu jinsi ya kusaidia wamiliki wa huduma kwa mbinu ya kujitegemea kwa vipimo vya SLO na kuvitumia katika kufanya maamuzi.
PES1.2.4	Ikiwa tutafanyia majaribio mchakato wa matamanio ya kila robo mwaka na kuashiria mchakato wa ukaguzi wa jumuiya na timu 3 katika Q1, tutashirikisha Wasimamizi wa Bidhaa ili kujumuisha ishara za jumuiya katika michakato yao ya kupanga kila robo mwaka na kila mwaka.
PES1.2.5	Tukiongeza uwezo wa kuchuja na kupanga matamanio kwenye kiendelezi cha Orodha ya Matamanio, kwenye maboresho ambayo huruhusu kuainisha kwa kutumia lebo na kupiga kura, maboresho 3 yataongeza washiriki wa kipekee zaidi katika Orodha ya Matamanio kwa angalau 30%.
PES1.3.3	Ikiwa tutaunda angalau uingiliaji kati 5 wa kupendeza kwenye jukwaa unaotokea kulingana na mwingiliano wa watumiaji, tutafafanua vichochezi vitakuwa vipi kwa ukurasa wa tovuti na kifaa cha Hali ya Kuzaliwa. Upimaji wa utumiaji utatuambia ni hatua zipi zinazounda uhusiano mzuri na chapa yetu. Nadharia tette hii itamalizwa na WikiCon Marekani Kaskazini mwishoni mwa Oktoba.
PES1.3.4	Ikiwa tutaunda tovuti dhabiti inayochunguza historia ya Wikipedia, ya sasa na ya baadaye, kwa ushirikiano na washiriki wa idara ya Mawasiliano, inayolenga kushirikisha hadhira mtandaoni kati ya miaka 18-34 katika maeneo yanayolengwa na kampeni, itazaa muunganisho mkubwa zaidi na Wikipedia kupitia shiriki za kijamii na shughuli nyingine za mtandaoni. Hili litachangia KR ya Mawasiliano kuongeza uwepo wa chapa kwa asilimia 10, huku ikituambia ikiwa mbinu madhubuti za maudhui zitaboresha mvuto wa chapa.

Q3

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

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

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

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

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

Q4

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

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

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

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

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

Kupanga Pamoja

Sasisho la Januari 2025.

Mpango wa Mwaka ni maelezo ya Wikimedia Foundation ya kile tunachotarajia kufikia katika mwaka ujao.Tunafanya kazi kwa bidii ili kufanya mpango kuwa shirikishi, wenye matamanio na kufanikishwa. Kila mwaka, tunawaomba wachangiaji kutoa mitazamo yao, matumaini na maombi mahususi tunapounda mpango. Baadhi ya njia tunazotafuta maoni ni kupitia mazungumzo ya timu ya bidhaa na jumuiya, Orodha ya Matamanio ya Jumuiya, mazungumzo ya jumuiya kama vile mfululizo wa mazungumzo ya Commons, kwenye mikutano, na kupitia kurasa za wiki kama huu.

Kwa mpango wetu ujao wa mwaka, kuanzia Julai 2025 hadi Juni 2026, tunafikiria jinsi tunavyoweza kutumikia vyema maono ya vizazi vingi, ukizingatia mabadiliko ya haraka katika dunia na mtandao na jinsi hiyo inavyoathiri dhamira yetu ya maarifa huria.

Kama nilivyosema mwaka jana, tunahitaji kuangazia kile kinachotutofautisha: uwezo wetu wa kutoa maudhui ya kuaminika hata kama taarifa potofu na mbaya zinapoenea kwenye mtandao na kwenye majukwaa yanayoshindania umakini wa vizazi vipya. Hii ni pamoja na kuhakikisha tunafanikisha dhamira ya kukusanya na kutoa jumla ya maarifa yote ya binadamu kwa ulimwengu kwa kupanua wigo wetu wa taarifa zinazokosekana, ambazo zinaweza kusababishwa na ukosefu wa usawa, ubaguzi na upendeleo. Maudhui yetu yanahitaji pia kutumika na kubaki kuwa muhimu katika mabadiliko ya intaneti yanayoendeshwa na akili mnemba na uzoefu tele. Na hatimaye, tunahitaji kutafuta njia za kufadhili harakati zetu kwa uendelevu kwa kujenga mkakati wa pamoja wa bidhaa zetu na kukusanya pesa ili tuweze kusaidia kazi hii kwa muda mrefu.

Ili kufanya chaguo na maelewano kuhusu mahali pa kuelekeza juhudi zetu katika mwaka ujao, tulikusanya maswali pamoja na kufikiria jinsi ya kutenga rasilimali zetu zenye kikomo ili kupata matokeo makubwa zaidi.

Ikiwa una nia mahususi katika sifa au huduma ambazo idara ya Bidhaa na Teknolojia itaunda kulingana na vipaumbele vilivyowekwa hapa, kutakuwa na wakati Machi wa kutoa maoni kuhusu malengo mahususi na matokeo muhimu. (Haya hapa ni malengo na matokeo muhimu ya mpango wa sasa wa mwaka, kwa marejeo.)

Iwapo ungependa kufikiria kuhusu changamoto na fursa katika mazingira yetu ya kiufundi na mwelekeo tunaopaswa kuweka katika mpango ujao wa mwaka, tafadhali zingatia maswali yaliyo hapa chini pamoja nasi.

Tunaendelea kupokea taarifa kuhusu maswali haya kwa njia nyingi -- kutoka mazungumzo ya jumuiya, data tunazokusanya, mahojiano ya utafiti tunayofanya, na zaidi. Hii si mara ya kwanza tunauliza na kujifunza kuhusu mengi ya mambo haya–na tayari tumekuwa tukifanya kazi karibu na wengi wao! Tunataka kuwauliza tena sasa na kuendelea kujifunza, kwasababu ni wa umuhimu kwetu katika hatua hii ya upangaji wetu.

Maswali:

Vipimo na data
- Ni njia zipi ambazo data na vipimo vinaweza kusaidia vyema kazi yenu kama wahariri? Unaweza kufikiria data kuhusu kuhariri, kusoma, au kupanga ambazo zingeweza kukusaidia kuchagua jinsi ya kutumia wakati wako, au wakati jambo fulani linahitaji kushughulikiwa? Hii inaweza kuwa data kuhusu shughuli yako mwenyewe au shughuli za wengine.
Kuhariri
- Ni wakati gani ambapo kuhariri kunakufaa zaidi na kukufurahisha? Ni wakati gani inakatisha tamaa na ngumu zaidi?
- Tunataka wachangiaji wapokee maoni zaidi na kutambuliwa kwa kazi zao, ili isionekane kama hakuna mtu anayetambua juhudi wanazotumia kwenye wiki. Ni aina gani ya maoni na utambuzi yanayokupa hamasa? Ni nini kinachokugusa uendelee kuhariri?
- Kwa sababu wiki ni kubwa sana, inaweza kuwa vigumu kwa wahariri kuamua ni kazi gani ya wiki ni muhimu zaidi kwao kutumia muda wao kila siku. Ni habari au zana gani zinaweza kukusaidia kuchagua jinsi ya kutumia wakati wako? Je, ingeweza saidia kuwa na sehemu kuu, ya binafsi ambayo inakuruhusu kupata fursa mpya, kudhibiti kazi zako na kuelewa matokeo yako?
- Tunataka kuboresha uzoefu wa ushirikiano kwenye wiki, ili iwe rahisi kwa wachangiaji kutafutana na kufanya miradi pamoja, iwe ni kupitia hifadhi rudufu, warsha za hariri, Miradi ya Wiki, au hata wahariri wawili wanaofanya kazi pamoja. Unafikiri tunaweza kuwasaidia vipi wachangiaji zaidi kutafutana, kuunganika na kufanya kazi pamoja?
Kusoma/Kujifunza
- Wiki hupakia haraka au polepole kulingana na mahali ambapo watu wanaishi ulimwenguni. Je, kuna sehemu yoyote duniani ambapo unafikiri kwamba utendakazi ulioboreshwa unahitajika zaidi?
- Tunawezaje kusaidia vizazi vipya vya wasomaji kupata maudhui ya Wikipedia ya kuvutia na shirikishi? Tumejadili mawazo kuhusu maudhui na video zenye mwingiliano hapo awali, na katika mwaka huu tumeangazia kwenye chati na kwenye kujaribu njia mpya za kuibua yaliyomo kwenye Wikipedia. Je, tunawezaje kuendelea na mwendo huu ili kutumia maudhui yetu yaliyopo kwa njia mpya ambazo ni za kipekee kwa Wikimedia?
Wasimamizi
- Ni nini kinachoweza kuhitaji kubadilishwa kuhusu Wikipedia ili watu wengi zaidi watake kujihusisha katika majukumu ya juu ya kujitolea, kama vile wafanya doria au wakabidhi?
- Ni taarifa au muktadha gani kuhusu hariri au watumiaji unaweza kukusaidia kufanya doria au maamuzi ya mkabidhi kwa haraka au kwa urahisi zaidi?
Mitindo ya Nje
- Ni mabadiliko gani muhimu zaidi unayoona duniani nje ya Wikimedia? Hizi zinaweza kuwa mitindo ya teknolojia, elimu, au jinsi watu wanavyojifunza.
- Nje ya harakati za Wikimedia, ni jumuiya gani nyingine za mtandaoni unazoshiriki? Tunaweza kujifunza nini kutoka kwenye zana na michakato kwenye majukwaa mengine ya jumuiya?
- Unatumia vipi zana za AI ndani na nje ya kazi yako ya Wikimedia? Je, unaona AI inakufaa kwa nini?
Commons
- Ni maamuzi gani tunaweza kufanya na jumuiya ya Commons ili kuunda mradi endelevu unaosaidia kuunda maarifa ya ensaiklopidia?
Wikidata
- Ungependa kuona Wikidata inakua vipi katika siku zijazo? Je, inawezaje kuwa muhimu zaidi kwa ajili ya kujenga maudhui ya ensaiklopidia ya kuaminika?

Majadiliano

–– Selena Deckelmann