Mpango wa Mwaka wa Shirika la Wikimedia Foundation/2024-2025/OKRs za Bidhaa na Teknolojia

Hati hii inawakilisha sehemu ya kwanza ya mchakato wa Upangaji wa Kila Mwaka wa 2024-2025 ya idara ya Bidhaa na Teknolojia ya Shirika la Wikimedia Foundation. Inafafanua kwenye rasimu ya idara "malengo na matokeo muhimu" (OKRs). Huu ni mwendelezo wa muundo wa portfolio za kazi (zinazoitwa "ndoo") ambazo zilianza mwaka jana.

Wikimedia Foundation
Mpango wa Mwaka 2024-2025

Mpango wa Mwaka wa Shirika la Wikimedia Foundation 2024-2025

• Muhtasari
• Historia
• Mitindo ya Nje
• Malengo
  • Miundombinu
  • Usawa
  • Usalama na Uadilifu
  • Ufanisi
• Muundo wa Kifedha
• Maelezo ya Bajeti
• Ushirikiano

Nilizungumza nanyi nyote hapo nyuma mnamo mwezi Novemba kuhusu kile ninachoamini kuwa swali muhimu zaidi linalozzikabili harakati za Wikimedia: je, tunahakikishaje kwamba Wikipedia na miradi yote ya Wikimedia ni ya vizazi vingi? Ningependa kumshukuru kila mtu ambaye alichukua muda kulitafakari swali hilo na kunijibu moja kwa moja, na sasa kwa kuwa nimepata nafasi ya kutumia muda kutafakari majibu yenu, nitawashirikisheni nilichojifunza.

Awali ya yote, hakuna sababu moja ya watu wanaojitolea kuchangia. Ili kukuza vizazi vingi vya watu wa kujitolea, tunahitaji kuelewa vyema sababu nyingi za watu kuchangia wakati wao kwa miradi yetu. Kisha, tunahitaji kuangazia kile kinachotutofautisha: uwezo wetu wa kutoa maudhui ya kuaminika huku taarifa potofu na upotoshaji zikienea kwenye intaneti na kwenye mifumo inayoshindana ili vizazi vipya vivutiwe. Hii ni pamoja na kuhakikisha tunafanikisha dhamira ya kukusanya na kuwasilisha jumla ya maarifa yote ya binadamu kwa ulimwengu kwa kupanua wigo wetu wa taarifa zinazokosekana, ambazo zinaweza kusababishwa na ukosefu wa usawa, ubaguzi au upendeleo. Maudhui yetu yanahitaji pia kutumika na kubaki kuwa muhimu katika mabadiliko ya intaneti yanayoendeshwa na akili bandia na uzoefu tele. Mwisho tunahitaji kutafuta njia za kufadhili harakati zetu kuwa uendelevu kwa kujenga mkakati wa pamoja wa bidhaa na mapato yetu ili tuweze kufadhili kazi hii kwa muda mrefu.

Mawazo haya yataonyeshwa katika mpango wa kila mwaka wa Shirika la Wikimedia wa 2024-2025, sehemu ya kwanza ambayo ninawashirikisheni ninyi leo katika muundo wa malengo ya rasimu ya kazi yetu ya bidhaa na teknolojia. Kama ilivyokuwa mwaka jana. , mpango wetu wote wa kila mwaka utazingatia mahitaji ya teknolojia ya hadhira na mifumo yetu, na tungependa kusikia maoni yako ili kujua kama tunaangazia matatizo yanayofaa. Malengo haya yanajenga mawazo ambayo tumekuwa tukiyasikia kutoka kwa wanajamii kwa muda wa miezi kadhaa iliyopita kupitia Mazungumzo:2024, kwenye orodha za wanaopokea barua pepe na kurasa za mazungumzo, na katika matukio ya jumuiya kuhusu bidhaa na mkakati wa teknolojia kwa mwaka ujao. . Unaweza kutazama orodha kamili ya rasimu ya malengo hapa chini.

"Lengo" ni mwelekeo wa kiwango cha juu ambao utaunda miradi ya bidhaa na teknolojia tunayochukua kwa mwaka ujao wa fedha. Malengo ni mapana kwa makusudi, yanawakilisha mwelekeo wa mkakati wetu na, muhimu zaidi, ni changamoto zipi tunazopendekeza kuzipa kipaumbele kati ya maeneo mengi yanayoweza kuangaziwa kwa mwaka ujao. Tunawashirikisheni hili sasa ili wanajamii waweze kusaidia kuunda mawazo yetu ya mapema na kabla ya bajeti na malengo yanayoweza kupimika kutekelezwa kwa mwaka.

Maoni

Sehemu moja ambayo tungependa kusikia maoni haswa ni kuhusu kazi yetu iliyopangwa chini ya jina "Matukio ya Wiki." "Matukio ya Wiki" inahusu jinsi tunavyowasilisha, kuboresha, na kuvumbua kwa ufanisi jinsi watu wanavyotumia Wiki moja kwa moja, iwe kama wachangiaji, watumiaji au wafadhili. Hii inahusisha kazi ya kusaidia teknolojia na uwezo wetu mkuu na kuhakikisha kuwa tunaweza kuboresha matumizi ya wahariri wanaojitolea - hasa, wahariri walio na haki nyingi - kupitia vipengele na zana bora zaidi, huduma za tafsiri na uboreshaji wa mifumo.

Haya hapa ni baadhi ya maswali ya tafakari kutoka kwenye mijadala yetu ya hivi majuzi ya kupanga, na baadhi ya maswali kwa ajili yenu nyote ili kutusaidia kuboresha mawazo yetu:

1. Kujitolea kwenye miradi ya Wikimedia kunapaswa kuhisiwa kuwa ni kitu chenye kutoa motisha. Pia tunafikiri kwamba uzoefu wa ushirikiano wa mtandaoni unapaswa kuwa sehemu kuu ya kinachowafanya wajitoleaji warudi. Je, tunapaswa kuwafanyia nini wanaojitolea kupata manufaa ya uhariri, na kufanya kazi vizuri zaidi ili kuunda maudhui ya kuaminika?
2. Uaminifu wa maudhui yetu ni sehemu ya mchango wa kipekee wa Wikimedia kwa ulimwengu, na kinachowafanya watu kuja kwenye jukwaa letu na kutumia maudhui yetu. Tunaweza kuunda nini kitakachosaidia kukuza maudhui ya kuaminika kwa haraka zaidi, lakini bado kiwe ndani ya ulinzi wa ubora uliowekwa na jumuiya kwenye kila mradi?
3. Ili kusalia kuwa muhimu na kushindana na mifumo mingine mikubwa ya mtandaoni, Wikimedia inahitaji kizazi kipya cha watumiaji ili kuhisi kuwa wameunganishwa kwenye maudhui yetu. Je, tunawezaje kurahisisha maudhui yetu kugundulika kiurahisi na kuingiliana nayo kwa wasomaji na wafadhili?
4. Katika enzi hizi ambapo matumizi mabaya ya mtandaoni yanashamiri, tunahitaji kuhakikisha kuwa jumuiya zetu, mifumo na mfumo wa huduma vinalindwa. Pia tunakabiliwa na kubadilika kwa majukumu ya utiifu, ambapo watunga sera wa kimataifa wanatazamia kuchagiza faragha, utambulisho, na kushirikisha habari mtandaoni. Je, ni maboresho gani ya uwezo wetu wa kupigana na unyanyasaji yatatusaidia kushughulikia changamoto hizi?
5. MediaWiki, jukwaa la programu na violesura vinavyoruhusu Wikipedia kufanya kazi, inahitaji usaidizi unaoendelea kwa muongo mmoja ujao ili kutoa uundaji, udhibiti, uhifadhi, ugunduzi, na utumiaji wa maudhui wazi ya lugha nyingi kwa kiwango. Ni maamuzi gani na uboreshaji wa jukwaa tunaweza kufanya mwaka huu ili kuhakikisha kuwa MediaWiki ni endelevu?

Majadiliano

–– Selena Deckelmann

Rasimu ya Malengo

Kilichochapishwa kwa sasa ni kiwango cha juu zaidi cha kupanga - "Malengo".

Sehemu inayofuata - rasimu "Matokeo Muhimu" (KR) kwa kila lengo lililokamilishwa imetolewa hapa chini.

Msingi wa "Makisio" kwa kila KR utasasishwa kwenye kurasa za wiki za mradi/timu husika mwaka mzima ili kusasishwa mwaka mzima kadri masomo yanavyojifunza.

Matukio ya Wiki (WE) rasimu ya malengo
Lengo	Eneo la lengo	Lengo	Muktadha wa lengo	Mmiliki
WE1 Majadiliano	Uzoefu wa mchangiaji	Wachangiaji wazoefu na wapya wanakusanyika pamoja mtandaoni ili kuunda ensaiklopidia ya kuaminika, kwa urahisi zaidi na mfadhaiko mdogo.	Ili Wikipedia iwe hai kwa miaka ijayo, ni lazima tufanye kazi ambayo inakuza vizazi vingi vya watu wa kujitolea na kufanya kuchangia kitu ambacho watu wanataka kufanya. Vizazi tofauti vya watu waliojitolea wanahitaji uwekezaji tofauti -- wachangiaji wenye uzoefu zaidi wanahitaji utiririshaji wao wa kazi wenye nguvu kuratibiwa na kurekebishwa, huku wachangiaji wapya wanahitaji njia mpya za kuhariri zinazoeleweka kwao. Na katika vizazi hivi, wachangiaji wote wanahitaji kuweza kuunganishwa na kushirikiana wao kwa wao ili kufanya kazi yao yenye matokeo zaidi. Kwa lengo hili, tutafanya uboreshaji wa mtiririko muhimu wa kazi kwa wachangiaji wenye uzoefu, tutapunguza vikwazo kwa michango ya kujenga kwa wageni, na tutawekeza katika njia ambazo watu wa kujitolea wanaweza kupata na kuwasiliana na kila mmoja kwa maslahi ya kawaida.	Marshall Miller
WE2 Majadiliano	Maudhui ya Kiensaiklopidia	Jumuiya zinasaidiwa ili kuziba mapengo ya maarifa kwa njia ya zana na mifumo ya usaidizi ambayo ni rahisi kufikiwa, kubadilika, na kuboresha, kuhakikisha ongezeko la ukuaji wa maudhui ya ensaiklopidia yanayoaminika.	Maudhui ya ensaiklopidia hasa kwenye Wikipedia yanaweza kuongezwa na kuboreshwa kupitia ushirikiano endelevu na uvumbuzi. Zana na rasilimali (za kiufundi na zisizo za kiufundi) ambazo zinapatikana kwa wachangiaji kutumia kwa mahitaji yao zinaweza kufanywa kutambulika zaidi, na kutegemewa. Zana hizi zinapaswa kuungwa mkono vyema na WMF, kupitia uboreshaji wa vipengele vinavyoweza kufikiwa katika mizunguko mifupi. Kwa kuzingatia mienendo ya hivi majuzi kuhusu uundaji wa maudhui uliosaidiwa na AI na kubadilisha tabia ya mtumiaji, tutachunguza pia misingi ya mabadiliko makubwa (k.m. Wikifunctions) ambayo yanaweza kusaidia ukuaji wa kasi katika kuunda na kutumia tena maudhui. Mbinu za kutambua mapungufu ya maudhui zinapaswa kuwa rahisi kugundua, na kupanga nazo. Nyenzo zinazosaidia ukuaji wa maudhui ya ensaiklopidia, ikiwa ni pamoja na maudhui kwenye miradi dada, miradi kama vile Maktaba ya Wikipedia, na kampeni zinaweza kuunganishwa vyema na mtiririko wa kazi wa michango. Wakati huo huo, mbinu zinazotumiwa kwa ukuaji zinapaswa kuwa na mielekeo ya ulinzi dhidi ya matishio yanayoongezeka, ambayo yanaweza kuhakikisha kuwa kuna imani endelevu katika mchakato huku ikizingatia kanuni za msingi za maudhui ya ensaiklopidia kama inavyotambuliwa katika miradi yote ya Wikimedia. Hadhira: Wahariri, Watafsiri	Runa Bhattacharjee
WE3 Majadiliano	Uzoefu wa watumiaji (Usomaji na Media)	Kizazi kipya cha watumiaji hufika kwenye Wikipedia ili kugundua mahali panapopendekezwa kwa ajili ya kugundua, kushirikisha, na kujenga muunganisho wa kudumu na maudhui ya ensaiklopidia.	Malengo: Kubakisha vizazi vilivyopo na vipya vya watumiaji na wafadhili. Kuongeza umuhimu kwa vizazi vilivyopo na vipya vya watumiaji kwa kufanya maudhui yetu kuwa rahisi kugundua na kuingiliana nayo. Kufanya kazi kwenye majukwaa mbalimbali ili kurekebisha uzoefu wetu na maudhui yaliyopo, ili maudhui ya ensaiklopidia yaweze kuchunguzwa na kuratibiwa na na kwa kizazi kipya cha watumiaji na wafadhili.	Olga Vasileva
WE4 Majadiliano	Uaminifu na Usalama	Kuboresha miundombinu, zana na michakato yetu ili tuwe na vifaa vya kutosha kulinda jamii, jukwaa na mifumo yetu ya huduma kutoka kwa aina tofauti za matumizi mabaya ya viwango na kuelekezwa huku tukidumisha utiifu wa mazingira ya udhibiti.	Baadhi ya vipengele vya uwezo wetu wa kupigana na matumizi mabaya vinahitaji kusasishwa. Udhibiti wa unyanyasaji unaotegemea IP unapungua ufanisi, zana kadhaa za wasimamizi zinahitaji uboreshaji wa utendakazi, na tunahitaji kuweka pamoja mkakati mmoja ambao hutusaidia kukabiliana na unyanyasaji uliokithiri kwa kutumia mawimbi mbalimbali na mbinu za kupunguza (captcha, vizuizi, n.k) katika tamasha. Katika mwaka huu, tutaanza kufanya maendeleo juu ya shida kubwa zaidi katika nafasi hii. Zaidi ya hayo, uwekezaji huu katika ulinzi wa unyanyasaji unapaswa kusawazishwa na uwekezaji katika kuelewa na kuboresha afya ya jamii, vipengele kadhaa ambavyo vimejumuishwa katika mahitaji mbalimbali ya udhibiti.	Suman Cherukuwada
WE5 Majadiliano	Jukwaa la Maarifa I (Kukua kwa Jukwaa)	Kutengeneza jukwaa la MediaWiki na violesura vyake ili kukidhi vyema mahitaji ya msingi ya Wikipedia.	MediaWiki imeundwa ili kuwezesha uundaji, udhibiti, uhifadhi, ugunduzi na utumiaji wa yaliyomo wazi, ya lugha nyingi kwa kiwango. Katika mwaka huu wa pili wa Jukwaa la Maarifa tutachunguza mfumo na kuanza kufanyia kazi uboreshaji wa jukwaa ili kusaidia kikamilifu mahitaji ya msingi ya miradi ya Wikimedia katika muongo ujao, kuanzia Wikipedia. Hii ni pamoja na kuendelea na kazi ya kufafanua jukwaa letu la uzalishaji wa maarifa, kuimarisha uendelevu wa jukwaa, kulenga mfumo wa viendelezi/kulabu ili kufafanua na kuboresha uundaji wa vipengele, na kuendelea kuwekeza katika kubadilishana maarifa na kuwezesha watu kuchangia kwenye MediaWiki.	Birgit Müller
WE6 Majadiliano	Jukwaa la Maarifa II (Huduma za Wasanidi Programu)	Wafanyakazi wa kiufundi na watengenezaji wa kujitolea wana zana wanazohitaji ili kusaidia vyema miradi ya Wikimedia.	Tutaendelea na kazi iliyoanzishwa ili kuboresha (na kuongeza) uendelezaji, majaribio na uwekaji wa mtiririko wa kazi katika Uzalishaji wa Wikimedia na kupanua ufafanuzi ili kujumuisha huduma kwa wasanidi wa zana. Pia tunalenga kuboresha uwezo wetu wa kujibu maswali yanayoulizwa mara kwa mara katika nyanja ya utendakazi wa wasanidi/wahandisi na hadhira na kufanya data muhimu ipatikane ili kuwezesha kufanya maamuzi kwa ufahamu. Sehemu ya kazi hii ni kuangalia desturi (au ukosefu wa hizo) ambazo kwa sasa zinaleta changamoto kwa mfumo wetu wa ikolojia.	Birgit Müller

Mawimbi na Huduma za Data (SDS) rasimu ya malengo
Lengo	Eneo la lengo	Lengo	Muktadha wa lengo	Mmiliki
SDS1 Majadiliano	Shared insights	Maamuzi yetu kuhusu jinsi ya kuunga mkono misheni na harakati za Wikimedia yanatokana na vipimo na maarifa ya kiwango cha juu.	Ili tuweze kuunda teknolojia kwa ufanisi na kwa ustadi, kusaidia watu wanaojitolea, na kutetea sera zinazolinda na kuendeleza ufikiaji wa maarifa, tunahitaji kuelewa mfumo wa ikolojia wa Wikimedia na kupatanisha jinsi mafanikio yanavyoonekana. Hii inamaanisha kufuatilia seti ya vipimo vya kawaida vinavyotegemewa, vinavyoeleweka na vinavyopatikana kwa wakati ufaao. Inamaanisha pia kutoa utafiti na maarifa ambayo hutusaidia kuelewa sababu na jinsi nyuma ya vipimo vyetu.	Kate Zimmerman
SDS2 Majadiliano	Jukwaa la majaribio	Wasimamizi wa bidhaa wanaweza kutathmini kwa haraka, kwa urahisi na kwa uhakika athari za vipengele vya bidhaa.	Ili kuwezesha na kuharakisha uamuzi wa data kwa ufahamu kuhusu uundaji wa vipengele vya bidhaa, wasimamizi wa bidhaa wanahitaji jukwaa la majaribio ambapo wanaweza kufafanua vipengele, kuchagua hadhira ya matibabu ya watumiaji na kuona vipimo vya athari. Kuharakisha muda kutoka kwa 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 kati mdogo au bila mwongozo kutoka kwa wahandisi na wachambuzi.	Tajh Taylor

Hadhira za Baadaye (FA) rasimu ya lengo
Lengo	Eneo la lengo	Lengo	Muktadha wa lengo	Mmiliki
FA1 Majadiliano	Kujaribu Makisio	Toa mapendekezo kuhusu uwekezaji wa kimkakati kwa Shirika la Wikimedia Foundation kufuata - kulingana na maarifa kutoka kwa majaribio ambayo yanaboresha uelewa wetu wa jinsi maarifa yanavyoshirikiwa na kutumiwa mtandaoni - ambayo husaidia harakati zetu kuhudumia hadhira mpya katika mtandao unaobadilika.	Kutokana na mabadiliko yanayoendelea katika teknolojia na tabia ya mtumiaji mtandaoni (k.m., kuongeza upendeleo wa kupata taarifa kupitia programu za jamii, 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 vuguvugu hatuna picha wazi iliyo na data ya manufaa na maelewano ya mikakati tofauti tunayoweza kufuata ili kushinda changamoto au kuchangamkia fursa mpya. Kwa mfano, tunapaswa... Tuwekeze katika kwa kiwango kikubwa vipengele vipya kama vile vikaragozi vya gumzo au video za kijamii kwenye jukwaa letu? Je, Tulete maarifa na njia za Wikimedia za kuchangia kwenye majukwaa maarufu ya watu wengine? Una kitu kingine chochote? Ili kuhakikisha kuwa Wikimedia inakuwa mradi wa vizazi vingi, tutajaribu dhahania ili kuelewa vyema na kupendekeza mikakati ya kuahidi - kwa Shirika la Wikimedia na harakati za Wikimedia - kufuata ili kuvutia na kuhifadhi watazamaji wa siku zijazo.	Maryana Pinchuk

Usaidizi wa Bidhaa na Uhandisi ​​(PES) rasimu ya lengo
Lengo	Eneo la lengo	Lengo	Muktadha wa lengo	Mmiliki
PES1 Majadiliano	Ufanisi wa shughuli	Kulifanya kazi za shirika ziende kwa uharaka, nafuu, na ziwe yenye matokeo zaidi.	Wafanyakazi hufanya mengi katika kazi zao za kawaida ili kufanya shughuli zetu ziwe haraka, nafuu na zenye matokeo zaidi. Lengo hili linaangazia mipango mahususi ambayo a) italeta faida kubwa kuelekea kasi, nafuu, au athari zaidi; na b) kuchukua juhudi zilizoratibiwa na mabadiliko ya mazoea rasmi na yasiyo rasmi katika Shirika. Kimsingi, KR zilizojumuishwa katika lengo hili ni maboresho magumu na bora zaidi tunaweza kufanya mwaka huu kwa ufanisi wa utendaji wa kazi inayogusa bidhaa na teknolojia yetu.	Amanda Bittaker

Rasimu ya Matokeo Muhimu

Rasimu ya "Matokeo Muhimu" (KR) kwa kila lengo lililokamilishwa iko hapa. Zinalingana na kila moja ya malengo, hapo juu.

Mada ya msingi "Dhana" kwa kila KR itasasishwa kuhusu mradi husika au kurasa za wiki za timu mwaka mzima kadri masomo yanavyojifunza.

Uzoefu wa Wiki (WE) Rasimu ya Matokeo Muhimu [ Malengo-rasimu ]
Jina fupi la Matokeo Muhimu	Maandishi ya Matokeo Muhimu	Muktadha wa Matokeo Muhimu	Mmiliki
WE1.1 Majadiliano	Kutengeneza au kuboresha mtiririko mmoja wa kazi unaosaidia wachangiaji walio na mambo yanayowavutia washirikiane na kuchangia pamoja.	Tunafikiri nafasi za jumuiya na mwingiliano kwenye wiki huwafanya watu kuwa na furaha na tija zaidi kama wachangiaji. Zaidi ya hayo, nafasi za jumuiya husaidia kuwakaribisha na kuwashauri wanaojiunga, modeli ya mbinu bora za kuchangia, na kusaidia kushughulikia mapungufu ya maarifa. Hata hivyo, rasilimali zilizopo, zana, na nafasi zinazotumia mwingiliano wa binadamu kwenye tovuti za Wiki ni ndogo na hazikidhi changamoto na mahitaji ya wengi wa wahariri leo hii. Wakati huo huo, kazi ya timu ya Kampeni imeonyesha kuwa waandaaji wengi wana hamu ya kupitisha na kujaribu zana mpya zilizo na mtiririko mzuri wa kazi ambao huwasaidia katika kazi zao za jumuiya. Kwa sababu hizi, tunataka kujikita katika kuhimiza na kukuza hali ya kuhusishwa miongoni mwa wachangiaji kwenye wiki.	Ilana Fried
WE1.2 Majadiliano	Uamilisho Unaojenga: #% Mwaka baada ya Mwaka (YoY) kuongezeka kwa asilimia ya wageni wanaochapisha zaidi ya hariri moja (≥1) la mabadiliko yenye kujenga katika nafasi kuu ya maeneo ya wiki kwenye simu ya mkononi.	Uzoefu wa sasa wa uhariri wa ukurasa mzima unahitaji muktadha mwingi, uvumilivu, na majaribio na hitilafu kwa wageni wengi kuchangia kwa njia yenye kujenga. Ili kusaidia kizazi kipya cha wafanyakazi wa kujitolea, tutaongeza idadi na upatikanaji wa mitiririko ya kazi ndogo, iliyopangwa, na mahususi zaidi ya kuhariri (Mf. Kuangalia Hariri na Kazi zilizopangwa tayari). Kumbuka: Mambo ya msingi itaanzishwa mwishoni mwa robo-mwaka ya 4 (Q4) ya mwaka huu wa fedha (FY), na kisha asilimia ya vipimo lengwa vya KR yetu vitawekwa.	Peter Pelberg
WE1.3 Majadiliano	Kuongeza kuridhika kwa watumiaji katika bidhaa 4 za udhibiti kwa X%.	Wahariri walio na haki zilizopanuliwa hutumia anuwai ya vipengele vilivyopo, viendelezi, zana na hati ili kutekeleza kazi za udhibiti kwenye miradi ya Wikimedia. Mwaka huu tunataka kuangazia katika kufanya maboresho ya zana hii, badala ya kufanya miradi ya kujenga utendaji mpya katika nafasi hii. Tunalenga kugusa idadi ya bidhaa katika kipindi cha mwaka, na tunataka kufanya maboresho yenye matokeo kwa kila moja. Kwa kufanya hivyo tunatarajia kuboresha matumizi ya kudhibiti maudhui kwa ujumla. Tutafafanua X% tunapopima misingi ya baadhi ya zana za kawaida za msimamizi ambazo tunaweza kulenga na mkondo huu wa kazi. Orodha ya Matamanio ya Jumuiya itakuwa na mchango mkubwa katika kuamua juu ya vipaumbele vya KR hii. We will define baselines for common moderator tools that we may target with this workstream to determine increase in satisfaction per tool. The Community Wishlist will be a substantial contributor to deciding on the priorities for this KR.	Sam Walton
WE2.1 Majadiliano	Kufikia mwisho wa robo-mwaka ya 2 (Q2), tutawasaidia waandaaji wa matukio, wachangiaji na taasisi wanasaidia zana mahususi, maarifa na mbinu za kupanga ambazo huongeza utangazaji wa maudhui bora katika maeneo muhimu ya mada [vitajadiliwa] kwa X%.	KR hii inahusu kuboresha ushughulikiaji wa mada kuelekea kupunguza mapengo ya maarifa yaliyopo . Tumegundua kuwa jumuiya zinanufaika kutokana na zana bora zinazounganishwa na kampeni zinazolenga kuongeza ubora wa maudhui katika miradi yetu. Mwaka huu tunataka kuangazia kuboresha zana zilizopo na kujaribu njia mpya za kuweka kipaumbele maeneo ya mada ambayo yanashughulikia mapungufu ya maarifa. Lengo letu la ongezeko la X% la ufikiaji litabainishwa kwa kuangalia misingi iliyopo ya uundaji wa maudhui ya ubora. Pia, maeneo ya mada tutakayozingatia na jumuiya na taasisi yataamuliwa kufikia robo ijayo. Our target 138 articles will be determined by looking at existing baselines of quality content creation.	Purity Waigi & Fiona Romeo
WE2.2 Majadiliano	Kufikia mwisho wa robo-mwaka ya 2 (Q2), tutatekeleza na kujaribu mapendekezo mawili, ya kijamii na kiufundi, ili kusaidia ushiriki wa lugha kwa jumuiya za lugha ndogo, pamoja na tathmini ya kuchanganua maoni ya jumuiya.	Kuna matoleo ya Wikipedia katika takriban lugha 300. Na bado, kuna lugha nyingi zaidi zinazozungumzwa na mamilioni ya watu, ambayo hakuna Wikipedia na hakuna Wiki kabisa. Hiki ni kizuizi cha kutimiza maono yetu: kwamba kila mwanadamu anaweza kushiriki kwa uhuru katika jumla ya maarifa yote. Wikimedia Incubator, ndipo ambapo wiki za mradi wa Wikimedia katika matoleo ya lugha mpya zinaweza kupangwa, kuandikwa, kujaribiwa na kuthibitishwa kuwa zinastahili kuandaliwa na Shirika la Wikimedia. Incubator ilizinduliwa mwaka wa 2006 kwa dhana kuwa watumiaji wake wangekuwa na maarifa ya awali ya kuhariri wiki. Tatizo hili linazidi kwenye ukweli kwamba mchakato huu unatakiwa kufanywa zaidi na watu ambao ni wapya zaidi na wenye uzoefu mdogo zaidi katika harakati zetu. Wakati uhariri kwenye Wikimedia wiki umeboreka kwa kiasi kikubwa tangu wakati huo, Incubator haijapokea masasisho haya kutokana na mapungufu ya kiufundi. Kwa sasa, inachukua wiki kadhaa kwa mradi mpya wa wiki kukidhi vigezo vya kutoka kwenye Incubator na karibu miradi ya wiki 12 pekee huundwa kila mwaka, jambo hili likinaonesha shida kubwa. Utafiti uliopo na nyenzo hufichua changamoto za kiufundi katika kila awamu ya uingizaji lugha: kuongeza lugha mpya kwenye Incubator, matatizo katika kutengeneza na kukagua maudhui, na mchakato wa polepole katika kuunda tovuti ya wiki wakati lugha inapokidhi vigezo kutoka kwenye Incubator. Kila awamu ni polepole, ya kawaida, na ngumu, ikionyesha hitaji la uboreshaji. Kushughulikia tatizo hili kutaruhusu kuunda wiki katika lugha mpya kwa haraka na kwa urahisi zaidi, na kuruhusu watu zaidi kushirikisha maarifa. wadau mbalimbali, utafiti na nyenzo zilizopo zimeangazia mapendekezo yaliyopendekezwa kijamii na kiufundi. Matokeo haya muhimu yanapendekeza kupima mapendekezo mawili ya kijamii na kiufundi na kutathmini maoni ya jumuiya.	Satdeep Gill & Mary Munyoki
WE2.3 Majadiliano	Kufikia mwisho wa robo-mwaka ya 2 (Q2), vipengele 2 vipya huwaongoza wachangiaji kuongeza nyenzo-chanzo ambazo zinatii miongozo ya mradi, na washirika 3-5 wamechangia nyenzo-chanzo ambazo hushughulikia mapungufu ya lugha na jiografia.	Ili kukuza ufikiaji wa nyenzo-chanzo bora zinazohitajika ili kuziba mapungufu ya kimkakati ya maudhui, tutafanya yafuatayo: Kushirikiana na Maktaba ya Urithi wa Bioanuwai; AfLIA; na mtandao wa kujifunza uitwao Wikisource Loves Manuscripts learning network. Tumia upataji na uhifadhi wa washirika wa maudhui kupitia vipimo vinavyoweza kufikiwa zaidi vya utumiaji tena. Kuwaongoza wachangiaji kuongeza picha na marejeleo ambayo yanaendana na mwongozo wa mradi na kuongeza imani katika maudhui, kwa mfano, kwa kuripoti matatizo yanayoweza kutokea wakati wa upakiaji/uongezaji.	Fiona Romeo & Alexandra Ugolnikova
WE2.4 Majadiliano	Kufikia mwisho wa robo-mwaka ya 2 (Q2), tutawezesha wito wa Wikifunctions kwa angalau lugha moja ndogo ya Wikipedia kutoa njia panuka zaidi kwa maudhui-mbegu mapya.	Ili kupunguza mapengo yetu ya maarifa ipasavyo, tunahitaji kuboresha mtiririkko wa kazi unaosaidia ukuaji mkubwa wa maudhui yenye ubora, hasa katika jumuiya za lugha ndogo.	Amy Tsay
WE3.1 Majadiliano	Kutoa uzoefu wa aina mbili ulioratibiwa, unaoweza kufikiwa na unaoendeshwa na jumuiya kwa wiki wakilishi, kwa lengo la kuongeza uhifadhi wa wasomaji ambao wametoka nje ya tovuti ya wiki watumiaji wenye uzoefu kwa 5%.	KR hii inalenga katika kuongeza uhifadhi wa kizazi kipya cha wasomaji kwenye tovuti yetu, kuruhusu kizazi kipya kujenga muunganiko wa kudumu na Wikipedia, kwa kuchunguza fursa kwa wasomaji kugundua na kujifunza kwa urahisi zaidi kutokana na maudhui wanayopenda. Hii itajumuisha uchunguzi na uundaji wa uzoefu mpya wa kuvinjari na kujifunza ulioratibiwa, uliobinafsishwa, na unaoendeshwa na jumuiya (kwa mfano, milisho ya maudhui husika, mapendekezo na mapendekezo ya maudhui ya mada, fursa za uchunguzi wa maudhui yaliyoratibiwa na jumuiya, n.k). Tunapanga kuanza mwaka wa fedha kwa kujaribu mfululizo wa majaribio ya matumizi ya kuvinjari ili kubaini ni kipi tungependa kupima kwa matumizi ya uzalishaji, na kwenye jukwaa lipi (wavuti, programu, au zote mbili). Kisha tutajikita katika kuongeza majaribio haya na kupima ufanisi wake katika kuongeza uhifadhi katika mazingira ya uzalishaji. Lengo letu ni kwamba kufikia mwishoni mwa mwaka ni kuzindua angalau uzoefu wa aina mbili wa matumizi kwenye wiki wakilishi na kupima kwa usahihi ongezeko la 5% la ubakishaji wa wasomaji kwa wasomaji wanaojihusisha na matumizi haya. Ili kufaulu kikamilifu katika kufikia KR hii, tutahitaji uwezo wa kufanya majaribio ya A/B na watumiaji walioondoka katika tovuti za wiki, pamoja na zana zinazoweza kupima uhifadhi wa wasomaji. Huenda pia tukahitaji API au huduma mpya zinazohitajika ili kuwasilisha mapendekezo na mbinu zingine za urekebishaji.	Olga Vasileva
WE3.2 Majadiliano	Ongezeko la 50% la idadi ya michango kupitia sehemu muhimu nje ya bango la kila mwaka na rufaa za barua pepe kwa kila jukwaa.	Lengo letu ni kutoa vyanzo mbalimbali vya mapato huku tukitambua wafadhili wetu waliopo. Kulingana na maoni na data, lengo letu ni kuongeza idadi ya michango zaidi ya mbinu ambazo Shirika lilitegemea hapo awali, haswa rufaa za mabango ya kila mwaka. Tunataka kuonyesha kwamba kwa kuwekeza katika matumizi jumuishi zaidi ya wafadhili, tunaweza kuendeleza kazi yetu na kupanua athari zetu kwa kutoa njia mbadala kwa wafadhili na wafadhili watarajiwa ambao hawaitikii rufaa za mabango. 50% ni makadirio ya awali kulingana na mwonekano uliopungua wa kitufe cha kuchangia kwenye Wavuti kama matokeo ya Vector 2022, na ongezeko la idadi ya michango kutoka kwenye mradi wa majaribio wa mwaka wa fedha (FY) wa 2023-2024 kwenye programu za Wikipedia ili kuboresha uzoefu wa wafadhili (50.1% kuongezeka kwa michango). Kutathmini kipimo hiki kulingana na mfumo kutatusaidia kuelewa mitindo katika mifumo na ikiwa mbinu tofauti zitatumika katika siku zijazo kulingana na tofauti ya tabia kulingana na hadhira ya mfumo.	Jazmin Tanner
WE3.3 Majadiliano	By the end of Q2 2024-25, volunteers will start converting legacy graphs to the new graph extension on production Wikipedia articles.	The Graph extension has been disabled for security reasons since April 2023, leaving readers unable to view many graphs that community members have invested time and energy into over the last 10 years. Data visualization plays a role in creating engaging encyclopedic content, so in FY 2024-25, we will build a new secure service to replace the Graph extension that will handle the majority of simple data visualization use cases on Wikipedia article pages. This new service will be built in an extensible way to support more sophisticated use cases if WMF or community developers choose to do so in the future. We will know we’ve achieved success when community members are successfully converting legacy graphs and publishing new graphs using the new service. We will determine which underlying data visualization library to use and which graph types to support during the initial phase of the project.	Christopher Ciufo
WE3.4 Majadiliano	Develop the capability model to improve website performance through smaller scale cache site deployments that take one month to implement while maintaining technical capabilities, security and privacy.	The Traffic team is responsible for maintaining the Content Delivery Network (CDN). This layer caches frequently accessed content, pages, etc, in memory and on disk. This reduces the time it takes to process requests for users. The second bit is storing content closer to the user in a physical sense. That reduces the time it takes for data to reach the user (latency). Last year, we enabled one site in Brazil meant to reduce latency in the Southern American region. Setting up new data centers would be great but it is expensive, time consuming, and requires a lot of work to get done – for example, last year’s work spanned the full year. We would love to have centers in Africa and Southeast Asia, and we would love to have them all around the world. Our hypothesis is to spin up smaller sites in other places around the world where traffic is lower. These would require fewer servers, of not more than four or five servers. This reduces our cost. It would still help us reduce latency for users in these regions, while being more lightweight in terms of time and effort to maintain them.	Kwaku Ofori
WE4.1 Majadiliano	Kutoa pendekezo la hatua 3 za kukabiliana na unyanyasaji na maudhui hatari yanayoarifiwa na data na kwa mujibu wa mazingira ya udhibiti yanayobadilika ifikapo robo-mwaka ya 3 (Q3).	Kuhakikisha usalama na ustawi wa mtumiaji ni jukumu la kimsingi la mifumo ya mtandaoni. Mamlaka nyingi zina sheria na kanuni zinazohitaji mifumo ya mtandaoni kuchukua hatua dhidi ya unyanyasaji, unyanyasaji wa mtandaoni na maudhui mengine hatari. Kukosa kushughulikia haya kunaweza kuweka mifumo kwenye dhima ya kisheria na vikwazo vya udhibiti. Hivi sasa hatuna wazo zuri sana kuhusu kwamba matatizo haya ni makubwa kiasi gani au sababu zinazosababisha. Tunategemea sana ushahidi wa kihistoria na michakato ya mikono ambayo hutuacha wazi kwa hatari za kisheria pamoja na matokeo mengine makubwa: kudharau tatizo, kuongezeka kwa madhara, uharibifu wa sifa na mmomonyoko wa imani ya watumiaji. Tunahitaji kujenga utamaduni thabiti wa kupima matukio ya unyanyasaji na maudhui hatari na kutekeleza kwa vitendo hatua za kupinga.	Madalina Ana
WE4.2 Majadiliano	Kutengeneza angalau mawimbi mawili kwaajili ya matumizi katika mtiririko wa kazi dhidi ya unyanyasaji ili kuboresha usahihi wa vitendo kwa watendaji wabaya kulingana ifikapo robo-mwaka ya 3 (Q3).	Miradi ya Wiki hutegemea sana kuzuia IP kama njia ya kuzuia uharibifu, barua taka na matumizi mabaya. Lakini anwani za IP hazitumiki sana kama vitambulishi thabiti vya mtumiaji mahususi, na kuzuia anwani za IP kuna athari hasi zisizotarajiwa kwa watumiaji wenye nia njema ambao watashirikisha anwani ya IP sawa na watendaji wabaya. Mchanganyiko wa kupungua kwa uthabiti wa anwani za IP na utegemezi wetu mkubwa wa kuzuia IP husababisha usahihi na ufanisi mdogo kuwalenga watendaji wabaya, pamoja na kuongezeka kwa viwango vya uharibifu wa dhamana kwa watumiaji wa nia njema. Tunataka kuona hali tofauti: viwango vilivyopungua vya uharibifu wa dhamana na usahihi ulioongezeka katika upunguzaji unaolenga watendaji wabaya. Ili kusaidia vyema kazi ya watendaji wa kupambana na unyanyasaji na kutoa vizuizi vya ujenzi kwa ajili ya matumizi tena katika zilizopo (k.m. CheckUser, Special:Block) na zana mpya, katika KR hii tunapendekeza kuchunguza njia za kumhusisha mtu binafsi na vitendo vyake kwa uaminifu (kupunguza ulaghai), na kuunganisha mawimbi yaliyopo (k.m. anwani za IP, historia ya akaunti, sifa za ombi) ili kuruhusu ulengaji sahihi zaidi wa vitendo kwa watendaji wabaya.	Kosta Harlan
WE4.3 Majadiliano	Kupunguza ufanisi wa shambulio la kiwango kikubwa kwa 50% kama inavyopimwa na muda tutakaochukua sisi kurekebisha hatua zetu na kiwango cha trafiki tunachoweza kudumisha katika majaribio.	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 maombi kwenye miundombinu yetu, au kuzidi uwezo wa jumuiya yetu kupambana na uharibifu mkubwa. Hili pia linaleta dosari isio na sababu kwa wahariri wetu wa wa thamani ya juu na jumuiya yetu ya kiufundi. Tunahitaji kwa haraka kuboresha uwezo wetu wa kutambua kiotomatiki, kustahimili, na kupunguza au kukomesha mashambulizi kama hayo. Ili kupima uboreshaji wetu, hatuwezi kutegemea tu mara kwa mara/ukubwa wa mashambulizi halisi, kwa kuwa tukiwa tunategemea vitendo vya nje itakuwa vigumu kupata picha kamili ya kiasi cha maendeleo yetu. Kwa kuanzisha mashambulizi mengi yaliyojaribiwa ya asili/utata wake/muda tofauti ili kuendeshwa kwa usalama dhidi ya miundombinu yetu, na kuyaendesha kila robo mwaka, tutaweza kupima hatua zetu mpya za kukabiliana na hali tukiwa hatushambuliwi, na kuripoti kwa ukamilifu uboreshaji wetu.	Giuseppe Lavagetto
WE4.4 Majadiliano	Launch temp accounts to 100% of all wikis.	Temporary accounts are a solution for complying with various regulatory requirements around the exposure of IPs on our platform on various surfaces. This work involves updating many products, data pipelines, functionary tools, and various volunteer workflows to cope with the existence of an additional type of account.	Madalina Ana
WE5.1 Majadiliano	Kufikia robo-mwezi ya 3 (Q3), tutakamilisha angalau hatua 5 ambazo zinakusudiwa kuongeza uendelevu wa jukwaa.	Uendelevu wa jukwaa la MediaWiki ni juhudi ya kudumu ya kijani kibichi muhimu kwa uwezo wetu wa kupanua, kuongeza au kuepuka uharibifu wa kuridhika kwa wasanidi programu, na kukuza jumuiya yetu ya kiufundi. Hii ni ngumu kupima na inategemea mambo ya kiufundi na kijamii. Hata hivyo, tunabeba maarifa ya kimyakimya kuhusu maeneo mahususi ya uboreshaji ambayo ni ya kimkakati kwa uendelevu. Hatua zilizopangwa zinaweza kusaidia kuongeza uendelevu na udumishaji wa jukwaa au kuepuka uharibifu wake. Tunapanga kutathmini athari za kazi hii katika Mfululizo wa 4 na mapendekezo ya malengo endelevu yakisonga mbele. Mifano ya uingiliaji katika uendelevu ni: kurahisisha vikoa changamano vya msimbo ambavyo ni msingi wa MediaWiki lakini ni watu wachache tu wanajua jinsi inavyofanya kazi; kuongeza matumizi ya zana za uchanganuzi wa msimbo ili kuelezea ubora wa msingi wetu wa msimbo; kusasisha michakato kama vile ufungashaji na matoleo.	Mateus Santos
WE5.2 Majadiliano	Kutambua ifikapo robo-mwaka ya 2 (Q2) na kukamilishe ifikapo robo-mwaka ya 4 (Q4) hatua moja au zaidi ili kusasisha violesura vya programu vya mfumo ikolojia wa MediaWiki ili kuwezesha ukuzaji wa vipengele vilivyotenganishwa, rahisi na endelevu zaidi.	Lengo kuu la KR 5.2 ni kuboresha na kufafanua mwingiliano kati ya jukwaa kuu la MediaWiki na viendelezi, ngozi na sehemu zake nyingine. Nia yetu ni kutoa maboresho ya utendaji kazi kwa usanifu wa MediaWiki unaowezesha urekebishaji wa vitendo na udumishaji, ambao ni rahisi kuunda viendelezi, na kuwezesha mahitaji kutoka kwa maono mapana ya bidhaa ya MediaWiki. Kazi hii pia inalenga kufahamisha kile kinachopaswa kuwepo (au kisichotakiwa kuwepo) ndani ya kiini, viendelezi, au miingiliano kati yao. Mwaka utagawanywa katika awamu mbili: utafiti wa miezi 5 na awamu ya majaribio ambayo itafahamisha awamu ya pili ambapo hatua mahususi zinatekelezwa.	Jonathan Tweed
WE5.3 Majadiliano	Kufikia mwishoni mwa robo-mwaka ya 2 (Q2), tutakamilisha mpango mmoja wa kukusanya data na jaribio moja la uboreshaji wa utendaji ili kufahamisha ufuatiliaji wa bidhaa na afua za jukwaa ili kuongeza uwezo uliofunguliwa na muundo wa MediaWiki wa ukurasa kama muundo wa vipande vilivyoundwa.	Lengo la msingi hapa ni kuwawezesha wasanidi programu na wasimamizi wa bidhaa kutumia uwezo mpya wa jukwaa la MediaWiki ili kukidhi mahitaji ya sasa na ya baadaye ya maudhui ya ensaiklopidia kwa kufanya uwezekano wa utoaji wa bidhaa mpya ambao ni vigumu kutekeleza kwa sasa na pia kuboresha utendaji na uthabiti wa jukwaa. Hasa, katika kiwango cha jukwaa la MediaWiki, tunataka kubadilisha muundo wa uchakataji wa MediaWiki kutoka kwa kuuchukulia ukurasa kama kitengo cha monolithiki hadi kuuchukulia ukurasa kama muundo wa vitengo vya maudhui vilivyoundwa. Mionekano ya kusoma kwa msingi wa Parsoid, ujumuishaji wa Wikidata, na ujumuishaji wa Wikifunctions kwenye Wiki zote ni hatua dhahiri kuelekea hilo. Kama sehemu ya KR hii, tunataka kufanya majaribio kimakusudi zaidi na kukusanya data ili kufahamisha hatua za siku zijazo kulingana na uwezo huu mpya ili kuhakikisha kuwa tunaweza kufikia miundomsingi inayolengwa na athari za bidhaa.	Subramanya Sastry
WE5.4 Majadiliano	By the end of Q2, execute the 1.43 LTS release with a new MW release process that synchronizes with PHP upgrades.	The MediaWiki software platform relies on regular updates to the next PHP version to remain secure and sustainable, which is a pain point in our process and important for the modernization of our infrastructure. At the same time, we regularly release new versions of the MediaWiki software, which e.g. translatewiki.net depends on, the platform used to translate software messages for the Wikimedia projects and many other open source projects. There’s an opportunity to improve the MediaWiki release process, including technical documentation and synchronization with PHP upgrades in alignment with the MediaWiki product strategy before the next release, which will be a long term support version (LTS). This work is part of our strategic investment in the sustainability of the MediaWiki platform (see also: 5.1) and aims to improve developer experience and infrastructure management.	Mateus Santos
WE6.1 Majadiliano	Kupatia uvumbuzi wa maswali ma 5 ili kuwezesha ufanisi na maamuzi sahihi kuhusu utendakazi na huduma za wasanidi programu na uhandisi na kufanya data inayofaa kupatikana kufikia mwisho wa robo-mwaka ya 4 (Q4).	"Jambo hili lina utata" ni jibu la mara kwa mara kwa maswali kama vile "hazina zipi zinatumwa kwa utengenezaji wa Wikimedia". Katika KR hii tutachunguza baadhi ya "kijani-endelevu" zetu katika uwanja wa tija na uzoefu wa uhandisi - maswali yanayojirudia ambayo yanaonekana kuwa rahisi lakini ni magumu kujibu, maswali ambayo tunaweza kujibu, lakini data haipatikani na yanahitaji maswali maalum kulingana na madahusika na wataalam wa masuala hayo, au maswali ambayo ni magumu kupata majibu kwa pengo la mchakato au sababu zingine. Tutafafanua maana ya "suluhisha" kwa kila moja ya maswali: Kwa baadhi jambo hili linaweza kumaanisha tu kufanya data iliyopo na sahihi ipatikane. Maswali mengine yatahitaji muda zaidi wa utafiti na uhandisi ili kuyashughulikia. Lengo kuu la kazi hii ni kupunguza muda, suluhisho na juhudi inachukua ili kupata maarifa katika vipengele muhimu vya uzoefu wa wasanidi programu na kutuwezesha kufanya maboresho ya uhandisi na mtiririko wa kazi na huduma za wasanidi programu.	[TBD]
WE6.2 Majadiliano	Kufikia robo-mwaka ya 4 (Q4), tutaboresha mradi uliopo na tufanye angalau majaribio mawili yanayolenga kutoa mazingira yanayodumishwa, yanayolengwa yanatusogeza kuelekea utoaji salama ulio na uendelevu wa kadri.	Wasanidi programu na watumiaji wanategemea Kundi la Beta la Wikimedia (beta) kupata hitilafu kabla hazijaathiri watumiaji katika toleo la umma. Baada ya muda, matumizi ya beta yamekua yakiingia kwenye mzozo-matumizi ni tofauti sana kutoshea katika aina moja ya mazingira. Tutaimarisha aina moja ya mazingira mbadala wa mazingira yaliyopo na kufanya majaribio yanayolenga kuchukua nafasi ya hitaji moja la kipaumbele la juu la upimaji linalotimizwa kwa sasa na beta na mazingira mbadala yanayodumishwa ambayo yanakidhi mahitaji ya kila kesi ya utumiaji vyema.	Tyler Cipriani
WE6.3 Majadiliano	Develop a Toolforge sustainability scoring framework by Q3. Apply it to improve at least one critical platform aspect by Q4 and inform longer-term strategy.	Toolforge, jukwaa muhimu la zana za Wikimedia zilizoundwa kwa kujitolea, ina jukumu muhimu kutoka kwenye kuhariri hadi kupinga uharibifu. Lengo letu ni kuimarisha utumiaji wa Toolforge, kupunguza vikwazo vya uchangiaji, kuboresha desturi za jumuiya na kukuza ufuasi wa sera zilizowekwa. Kwa hili, tutaanzisha mfumo wa kupima ufanisi ifikapo robo-mwaka ya 2 (Q2) ili kutathmini uendelevu wa jukwaa la Toolforge, tukizingatia vipengele vya kiufundi na kijamii. Kwa kutumia mfumo huu kama mwongozo, tunalenga kuboresha mojawapo ya vipengele muhimu vya kiufundi kwa 50%.	Slavina Stefanova

Mawimbi na Huduma za Data (SDS) Rasimu ya Matokeo Muhimu [ Malengo-rasimu ]
Jina fupi la Matokeo Muhimu	Maandishi ya Matokeo Muhimu	Muktadha wa Matokeo Muhimu	Mmiliki
SDS1.1 Majadiliano	Viongozi wa programu 2 au mipango inayoendeshwa na KR wametoa hati shirikishwa kwa wingi zinazoelezea kiungo cha kimantiki kati ya kazi ya timu yao na athari kwenye metriki moja au zaidi za msingi za Shirika.	Vipimo vyetu vya msingi vya shirika hutumika kama msingi wa kutathmini maendeleo ya Shirika kuelekea malengo yake. Tunapotenga rasilimali kwa programu na kubuni mikondo ya kazi yenye mwelekeo wa matokeo muhimu (KR), vipimo hivi vya kiwango cha juu vinapaswa kuongoza jinsi tunavyounganisha uwekezaji huu na malengo makuu ya Shirika kama inavyofafanuliwa katika mpango wa kila mwaka. Kazi katika matokeo haya muhimu tunakubali kwamba Shirika kwa ujumla liko katika hatua ya awali katika uwezo wake wa kuunganisha kwa kiasi kikubwa athari za uingiliaji kati uliopangwa kwa viwango vya juu, au vipimo vya msingi. Katika kutimiza lengo hilo la mwisho, KR hii inalenga kuendeleza mchakato ambapo tunashirikisha viungo vya kimantiki na vya kinadharia kati ya mipango yetu na vipimo vyetu vya hali ya juu. Kiutendaji, hii inamaanisha kushirikiana na wamiliki wa mpango katika Shirika lote ili kuelewa jinsi matokeo ya kazi yao katika kiwango cha mradi yanaunganishwa na kuathiri vipimo vyetu vya msingi katika ngazi ya Shirika. Miundo ya uainishaji ya athari na mazoezi kama vile 'Nadharia ya Mabadiliko ya ramani' na ujenzi wa grafu ya causal itatumika ili kuhakikisha uthabiti na umakini katika kurekodi athari muhimu ya kazi. Ili kutekeleza matokeo haya muhimu, tutahitaji pia kuunda nyenzo za usaidizi zinazosaidia wamiliki wa mpango kuelewa vipimo vya shirika na kuelewa jinsi ya kuunda nadharia za mabadiliko zinazohusiana na kazi yao.	Omari Sefu
SDS1.2 Majadiliano	Kupatia uvumbuzi maswala ma 2 ya utafiti wazi kabla ya Desemba 2024 ili kutoa mapendekezo au kuelezea upangaji wa kila mwaka wa mwaka wa fedha wa 26 (FY26).	Kuna maswali mengi ya utafiti wazi katika mfumo ikolojia wa Wikimedia, na kujibu baadhi ya maswali hayo ni suala la kimkakati kwa WMF au washirika. Majibu ya maswali haya yanaweza kufahamisha maendeleo ya bidhaa au teknolojia ya siku zijazo au yanaweza kusaidia kufanya maamuzi/utetezi katika nafasi ya sera. Ingawa baadhi ya maswali haya yanaweza kujibiwa kwa kutumia utafiti au utaalamu wa uhandisi wa utafiti, kwa kuzingatia hali ya kijamii na kiufundi ya miradi ya WM inayofikia maarifa ya kuaminika mara nyingi huhitaji ushirikiano wa timu mbalimbali kwa ajili ya ukusanyaji wa data, kujenga muktadha, mwingiliano wa watumiaji, muundo makini wa majaribio, na zaidi. Kupitia KR hii tunalenga kutanguliza baadhi ya rasilimali zetu kuelekea kujibu swali moja au zaidi kati ya hizo. Kazi katika KR hii inajumuisha kuweka kipaumbele kwa orodha ya maswali ya wazi ya kimkakati, na pia kufanya kazi ya majaribio ili kupata majibu idadi X (inakadiriwa 2 kwa sasa) kati yao. Aina bora ya maswali tunayojibu katika KR hii ni maswali ambayo yanapojibiwa yanaweza kuwa na athari ya kufungua kwa kuwezesha timu au vikundi vingine vingi kufanya kazi (bora? iliyoarifiwa) ya bidhaa, teknolojia au sera. Tunakusudia kazi katika KR hii iambatane na KR zifuatazo: PES1.3. ambapo lengo ni kujaribu bidhaa kwenye jukwaa au mawazo ya vipengele kulingana na bidhaa zilizopo. FA1.1. ambapo lengo ni majaribio kuhusu hadhira ya baadaye kwa kutumia teknolojia ya akili bandia/mashine kujifunza AI/ML.	Leila Zia
SDS1.3 Majadiliano	Kufikia angalau punguzo la 50% la muda wa wastani unaohitajika kwa wadau wa data kuelewa na kufuatilia mtiririko wa data kwa vipimo 3 vya msingi na muhimu.	Inahitajika kwa viwango vya Udhibiti wa Data. Kufuatilia nyuma mabadiliko na chanzo cha kanzidata ni ngumu na inahitaji maarifa ya repos na mifumo tofauti. Tunapaswa kufanya iwe rahisi kuelewa jinsi data inavyotiririka kwenye mifumo yetu ili wadau wa data wafanye kazi kwa njia ya kujihudumia zaidi. Kazi hii itasaidia mtiririko wa kazi ambapo data inabadilishwa na kutumika kwa uchanganuzi, vipengele, API na kazi za ubora wa data. Kutakuwa na ufuatiliaji wa KR kuhusu kuweka kumbukumbu.	Luke Bowmaker
SDS2.1 Majadiliano	Kufikia mwisho wa robo-mwaka ya 2 (Q2), tunaweza kusaidia timu 1 ya bidhaa kutathmini kipengele au bidhaa kupitia majaribio ya msingi ya A/B ambayo hupunguza muda wao wa data ya mwingiliano wa watumiaji kwa 50%.	Tunafikiri kutumia zana shirikishwa kutaongeza imani ya timu za bidhaa katika kufanya maamuzi yanayotokana na data, kuboresha ufanisi na tija na kuboresha mkakati na ubunifu wa bidhaa. Tutaangalia namna ya kutumia muda wa timu binafsi kwa misingi ya data ya mwingiliano wa watumiaji na kuiboresha kwa 50%. Pia tutachunguza jinsi tunavyoweza kuweka faida hizi katika muktadha kamili wa timu zote za bidhaa. Tunatarajia kujifunza jinsi tunavyoweza kuboresha matumizi na kutambua na kutanguliza uboreshaji wa uwezo kulingana na maoni kutoka kwa timu inayoidhinisha na matokeo ya SDS2.2.	Virginia Poundstone
SDS2.2 Majadiliano	Kufikia mwisho wa robo-mwaka ya 2 (Q2), tutakuwa na vipimo 2 muhimu vya kuchanganua majaribio (majaribio ya A/B) ili kusaidia majaribio ya bidhaa/dhana za vipengele zinazohusiana na KRs za mwaka wa fedha wa 24-25 (FY24-25 KRs).	Pale msimamizi wa bidhaa (au msanifu) akiwa na dhana kwamba bidhaa/kipengele kitashughulikia tatizo/hitaji la watumiaji au shirika, jaribio ni jinsi wanavyojaribu nadharia hiyo na kujifunza kuhusu athari inayoweza kutokea ya wazo lao kwenye kipimo. Matokeo ya jaribio humpa uelewa msimamizi wa bidhaa na kumsaidia kufanya uamuzi kuhusu hatua inayofuata ya kuchukua kama (aachane na wazo hilo na ujaribu dhana tofauti, aendeleze uundaji ikiwa jaribio lilifanywa mapema katika mzunguko wa maisha ya ukuzaji, au aache bidhaa/kipengele. kwa watumiaji zaidi). Wasimamizi wa bidhaa lazima waweze kufanya uamuzi kama huo kwa ujasiri, wakiungwa mkono na ushahidi wanaoamini na kuelewa. Kikwazo kikubwa kwa hili ni kwamba timu za bidhaa kwa sasa huunda dhana zao kwa vipimo maalum vya mradi ambavyo vinahitaji usaidizi mahususi wa wachambuzi kufafanua, kupima, kuchanganua na kuripoti kuhusiana na dhana hizo. Kubadili hadi seti ya vipimo muhimu vya kuunda taarifa zote za nadharia ya bidhaa/vipengele zinazoweza kufanyiwa majaribio kunaweza kuleta: urahisi zaidi na uharaka wa kubuni, kusambaza na kuchanganua majaribio ili kujaribu nadharia hizo urahisi wa kuwasilisha matokeo na mafunzo kutoka kwa majaribio kwa watoa maamuzi (wasimamizi wa bidhaa) na hadhira nyingine (k.m. uongozi mkuu, wengine katika shirika, jumuiya) Tunafikiri kwamba seti ya vipimo muhimu vinavyoeleweka na kutumiwa kwa wingi - na kufahamishwa/kuathiriwa na vipimo vya viwango vya sekta - pia vinaweza kuboresha ujuzi wa data wa shirika na kukuza utamaduni wa kukagua, kufanya majaribio na kujifunza. Tunaangazia vipimo muhimu ambavyo (1) vinahitajika kwa kipimo bora na tathmini ya mafanikio/athari ya bidhaa/vipengele vinavyohusiana na Uzoefu wa miradi mi 2 ya Wiki KRs - WE3.1 na WE1.2 - na (2) huakisi au kuainisha sekta- vipimo vya kawaida vinavyotumika katika uchanganuzi wa wavuti.	Mikhail Popov
SDS2.3 Majadiliano	Deploy a unique agent tracking mechanism to our CDN which enables the A/B testing of product features with anonymous readers.	Without such a tracking mechanism, it is not reasonable to implement A/B testing of product features with anonymous readers. This is basically a milestone-based result to create a new technical capability that others can build measurable things on top of. The key priority use-case will be A/B testing of features with anonymous readers, but this work also enables other important future things, which may create follow-on hypotheses later in WE4.x (for request risk ratings and mitigating large-scale attacks) and for metrics/research about unique device counts as their resourcing and priorities allow.	Brandon Black

Rasimu ya Matokeo Muhimu ya Hadhira ya Baadaye (FA). [ Malengo-rasimu ]
Jina fupi la Matokeo Muhimu	Maandishi ya Matokeo Muhimu	Muktadha wa Matokeo Muhimu	Mmiliki
FA1.1 Majadiliano	Kama matokeo ya maarifa na mapendekezo ya majaribio ya Hadhira ya Baadaye, kufikia mwisho wa robo-mwaka ya 3 angalau lengo moja au tokeo moja kuu linalomilikiwa na timu ya Hadhira isiyo ya Baadaye litakuwepo kwenye rasimu ya mpango wa mwaka unaofuata.	Tangu 2020, Shirika la Wikimedia Foudation 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. Watazamaji wa Baadaye, timu ndogo ya R&D, ita: Fanya 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, tutatoa mapendekezo kuhusu 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 Wakati Ujao na yanaendeshwa na pendekezo la Hadhira ya Wakati Ujao yanaonekana katika rasimu ya mpango wa kila mwaka wa mwaka wa fedha unaofuata.	Maryana Pinchuk

Usaidizi wa Bidhaa na Uhandisi (PES) Rasimu ya Matokeo Muhimu [ Malengo-rasimu ]
Jina fupi la Matokeo Muhimu	Maandishi ya Matokeo Muhimu	Muktadha wa Matokeo Muhimu	Mmiliki
PES1.1 Majadiliano	Utamaduni wa Kukagua: Kuboresha alama kwa maoni ya wafanyakazi wa P+T kuhusiana na utoaji wetu, mpangilio, mwelekeo na afya ya timu katika utafiti wa kila robo mwaka.	Utamaduni wa kukagua ni utamaduni wa ukuzaji wa bidhaa kulingana na mizunguko mifupi ya kurudia, kujifunza na kuzoea. Hii ina maana kwamba shirika letu linaweza kuweka malengo ya kila mwaka, lakini kile tunachofanya ili kufikia malengo haya kitabadilika na kubadilika katika kipindi cha mwaka tunapojifunza. Kuna vipengele viwili vya kujenga utamaduni wa mapitio: taratibu na tabia. KR hii inazingatia mwisho. Mabadiliko ya tabia yanaweza kukua na kuimarisha utamaduni wetu wa kukagua. Hii inahusisha mabadiliko katika tabia na taratibu za mtu binafsi tunapoelekea kwenye ukuzaji wa bidhaa unaorudiwa mara kwa mara. KR hii itategemea mabadiliko ya kibinafsi katika tabia ya mtu binafsi, na kupima mabadiliko yanayotokana, ikiwa yapo, katika hisia za wafanyikazi.	Amy Tsay
PES1.2 Majadiliano	Kufikia mwisho wa robo-mwaka ya 2 (Q2), Orodha mpya ya Matamanio inaunganisha vyema mawazo ya harakati na maombi kwa shughuli za Shirika P+T: vitu kutoka kwenye orodha ya matamanio vinashughulikiwa kupitia 2024-5 KR, Shirika limekamilisha Matakwa 10 madogo, na Shirika limeshirikiana na watu waliojitolea kutambua maeneo 3+ ya fursa kwa Mwaka wa Fedha wa 2025-26.	Orodha ya Matamanio ya Jumuiya inawakilisha kipande finyu cha harakati; takriban watu 1k hushiriki, wengi wao wakiwa wachangiaji au wasimamizi. Watu mara nyingi hukwepa Orodha ya Matamanio kwa kuandika maombi ya vipengele na ripoti za hitilafu kupitia Phabricator, ambapo ni vigumu kutambua maombi kutoka kwa WMF au jumuiya. Kwa washiriki, Orodha ya Matamanio ni uwekezaji wa wakati wa gharama na malipo kidogo. Bado wanajihusisha na Orodha ya Matamanio kwa sababu wanahisi kuwa ndiyo chombo pekee cha kuangazia hitilafu zinazoathiri na uboreshaji wa vipengele, au kuashiria hitaji la fursa pana zaidi za kimkakati. Matakwa mara nyingi huandikwa kama suluhisho, dhidi ya shida. Suluhu zinaweza kuonekana kuwa za busara kwenye karatasi, lakini si dhahiri kuwa kuzingatia pia utata wa kiufundi au athari za mkakati wa harakati. Upeo na upana wa matakwa wakati mwingine huzidi upeo na uwezo wa Community Tech au timu moja, na kuendeleza kuchanganyikiwa, na kusababisha RFCs na wito wa kuvunja Orodha ya matamanio. Ingawa wanajamii wanapendelea kutumia Orodha ya Matamanio kwa mawazo ya mradi, timu katika Shirika huangalia Orodha ya Matamanio na michakato mingine ya upokeaji vipaumbele, kwa sehemu kwa sababu matakwa hayajawekwa wakati wa Upangaji wa Mwaka na ni vigumu kujumuisha katika ramani za barabara/OKRs. Orodha ya Matamanio ya Baadaye inapaswa kuwa daraja kati ya jamii na Shirika, ambapo jumuiya hutoa mchango kwa njia iliyopangwa, ili tuweze kuchukua hatua na kuwafanya wanaojitolea kuwa na furaha. Tunaunda mchakato mpya wa upokeaji kwa mtu yeyote aliyejitolea kuwasilisha matakwa, siku 365 kwa mwaka. Matamanio yanaweza kuripoti au kuangazia hitilafu, kuomba kuboreshwa, au kutoa wazo kuhusu kipengele kipya. Mtu yeyote anaweza kutoa maoni kuhusu, warsha, au kuunga mkono tamanio kushawishi uwekaji kipaumbele. Shirika halitainisha matakwa kuwa "kubwa sana" au "dogo sana." Tamanio ambalo kimaudhui linaonekana kuwa linafaa kuwa katika eneo kubwa la tatizo linaweza kuathiri upangaji wa kila mwaka na uainishaji wa njia za utendaji za timu, huku likitoa mwelekeo wa kimkakati na fursa. Matakwa yataonekana kwenye Harakati katika dashibodi inayoainisha matakwa kulingana na mradi, eneo la bidhaa/tatizo na aina ya matakwa. Shirika lishughulikia matakwa kwa wakati ufaao, na kwa kushirikiana na Jumuiya kuainisha na kuyapa kipaumbele matakwa. Tutashirikiana na Wanawikimedia kutambua na kuweka kipaumbele maeneo matatu ya uboreshaji, yaliyojumuishwa katika Mpango wa Mwaka wa 2025-26 wa Shirika, ambao unapaswa kuboresha kiwango cha kupitishwa na kutimiza matakwa yenye matokeo. Tutaalamisha matakwa yaliyokamilishwa vyema kwa jumuiya ya wasanidi programu wa kujitolea na timu za Shirika, na hivyo kusababisha ushirikiano zaidi wa timu na wasanidi programu na kutimiza matakwa zaidi, na hivyo kusababisha kuridhika kwa jumuiya. Kushughulikia matakwa zaidi huboresha furaha ya mchangiaji, utendakazi, na uhifadhi, ambayo inapaswa kuzalisha mabadiliko bora zaidi, maudhui ya ubora wa juu na wasomaji zaidi.	Jack Wheeler
PES1.3 Majadiliano	Kuendesha na kukamilisha majaribio mawili kutoka kwenye bidhaa/vipengele vya uchunguzi vilivyopo ambavyo hutupatia data/maarifa kuhusu jinsi tunavyokuza Wikipedia kama mahali pa maarifa kwa hadhira yetu ya sasa ya watumiaji na watu waliojitolea katika robo-mwaka ya 1 (Q1) na robo-mwaka ya 2 (Q2). Kukamilisha na ushiriki mafunzo na mapendekezo ya uwezekano wa kupitishwa kwa kazi ya siku zijazo ya OKR katika kapu la Matukio ya Wiki kufikia mwisho wa robo-mwaka ya 3 (Q3).	Kazi hii inalingana na lengo la Hadhira ya Wakati Ujao, lakini inalenga katika kufunua fursa za kuongeza na kuongeza kiundani zaidi ushirikishwaji wa hadhira yetu iliyopo (ya watumiaji na wachangiaji wa Wikipedia) kupitia kujaribu kwa uangalifu zaidi mawazo ya bidhaa kwenye jukwaa. Kazi hii inaishi katika PES1 kwa kuwa ni ya kuchangamsha na kujizidisha - ikielekeza wakati ambao watu binafsi na timu "tayari" wamejitolea kwa udukuzi/kufanyia majaribio miradi ya kando ili kuleta vipengele vya kuahidi zaidi kuzingatiwa. Badala ya miradi hii ya kando kudorora (sio matumizi mazuri ya rasilimali zetu chache), KR hii inatoa njia kwa baadhi ya mawazo haya kuweza kuifanya iwe mipangilio mikubwa ya APP kupitia majaribio yaliyothibitishwa, hivyo kutumia kwa ufanisi zaidi muda wa wafanyakazi na kuhamasisha ubunifu wao na tija. Kwa kuchunga zaidi miradi hii midogo, mifupi itumike, pia tunabadilisha uenezaji wetu wa ‘dau’ kwa mafunzo zaidi na majaribio ya mawazo ambayo yanaweza kubadilisha Wikipedia kulingana na mahitaji na matarajio yanayobadilika ya hadhira yetu ya sasa. Hii itafanya kazi yetu kuwa na athari zaidi na kwa haraka zaidi kwani inasaidia msingi kujipanga kwenye lengo sahihi kwa muda mfupi.	Rita Ho
PES1.4 Majadiliano	Kujifunza jinsi ya: kuweka, kufuatilia, na kufanya maamuzi kwenye SLO. Kuchagua angalau jambo moja jipya la kufafanua SLO tunapoichapisha. Kushirikiana na timu husika (kawaida: bidhaa, timu za maendeleo, SRE) ili kufafanua SLO hiyo. Kutafakari na kuweka hati miongozo ya matoleo yapi yanapaswa kuwa na SLO katika siku zijazo na jinsi ya kuyaweka.	FUTURE KR: Kuweka mchakato na zana za kimsingi za kuweka na kufuatilia SLO kwa matoleo mapya. Ripoti kila robo mwaka, na uitumie kufanya maamuzi kuhusu wakati wa (na sio) kutanguliza kazi ili kurekebisha jambo. Shiriki ripoti na jumuiya. KWANINI: Hatujui ni lini tunahitaji kuwekea kipaumbele kazi ya kurekebisha kitu fulani. Na tuna mengi ya kusanidi. Kadiri kazi hii inavyoendelea kukua, kuna hali zaidi ambapo tunaweza kuhitaji kuamua kati ya kushughulikia masuala au kuzjikita katika uvumbuzi, na kutokuwa na uhakika zaidi wakati tunapaswa. Pia, si wazi kwa wafanyakazi na jumuiya ni kiwango gani cha usaidizi/kujitolea kwetu kuhusu kutegemewa na utendakazi ni kwa vipengele na utendakazi tofauti wanaoshirikiana nao. Ikiwa tutafafanua kiwango cha huduma kinachotarajiwa, tunaweza kujua ni lini tunapaswa kutenga rasilimali kwaajili yake au la.	Mark Bergsma
PES1.5 Majadiliano	Define ownership and commitments (including SLOs) on services and learn how to track, report and make decisions as a standard and scalable practice by trialing it in 3 teams across senior leaders in the department.	After collaboratively defining an SLO for the EditCheck feature as part of PES1.5, we will now trial and learn from using the SLO in practice to help prioritisation of reliability work. We will also document roles and responsibilities for ownership of code/services, allowing us to make clear shared commitments on the level of ongoing support. We will try to use these as practices in 3 teams across the department.	Mark Bergsma

Hypotheses

The hypotheses below are the specific things we are doing each quarter to address the associated key results above.

Each hypothesis is an experiment or stage in an experiment we believe will help achieve the key result. Teams make a hypothesis, test it, then iterate on their findings or develop an entirely different new hypothesis. You can think of the hypotheses as bets of the teams’ time–teams make a small bet of a few weeks or a big bet of several months, but the risk-adjusted reward should be commensurate with the time the team puts in. Our hypotheses are meant to be agile and adapt quickly. We may retire, adjust, or start a hypothesis at any point in the quarter.

To see the most up-to-date status of a hypothesis and/or to discuss a hypothesis with the team please click the link to its project page below.

Q1

The first quarter (Q1) of the WMF annual plan covers July-September.

Wiki Experiences (WE) Hypotheses [ WE Key Results ] Majadiliano
Hypothesis shortname	Q1 text	Details & Discussion
WE1.1.1	If we expand the Event List to become a Community List that includes WikiProjects, then we will be able to gather some early learnings in how to engage with WikiProjects for product development.
WE1.1.2	If we identify at least 15 WikiProjects in 3 separate Wikipedias to be featured in the Community List, then we will be able to advise Campaigns Product in the key characteristics needed to build an MVP of the Community List that includes WikiProjects.
WE1.1.3	If we consult 20 event organizers and 20 WikiProject organizers on the best use of topics available via LiftWing, then we can prioritize revisions to the topic model that will improve topical connections between events and WikiProjects.
WE1.2.1	If we build a first version of the Edit Check API, and use it to introduce a new Check, we can evaluate the speed and ease with other teams and volunteers could use the API to create new Checks and Suggested Edits.
WE1.2.2	If we build a library of UI components and visual artefacts, Edit Check’s user experience can extend to accommodate Structured Tasks patterns.
WE1.2.3	If we conduct user tests on two or more design prototypes introducing structured tasks to newcomers within/proximate to the Visual Editor, then we can quickly learn which designs will work best for new editors, while also enabling engineers to assess technical feasibility and estimate effort for each approach.	mw:Growth/Constructive activation experimentation
WE1.2.4	If we train an LLM on detecting "peacock" behavior, then we can learn if it can detect this policy violation with at least >70% precision and >50% recall and ultimately, decide if said LLM is effective enough to power a new Edit Check and/or Suggested Edit.
WE1.2.5	If we conduct an A/B/C test with the alt-text suggested edits prototype in the production version of the iOS app we can learn if adding alt-text to images is a task newcomers are successful with and ultimately, decide if it's impactful enough to implement as a suggested edit on the Web and/or in the Apps.	mw:Wikimedia Apps/iOS Suggested edits project/Alt Text Experiment
WE1.3.1	If we enable additional customisation of Automoderator's behaviour and make changes based on pilot project feedback in Q1, more moderators will be satisfied with its feature set and reliability, and will opt to use it on their Wikimedia project, thereby increasing adoption of the product.	mw:Automoderator
WE1.3.2	If we are able interpret subsets of wishes as moderator-related focus areas and share these focus areas for community input in Q1-Q2, then we will have a high degree of confidence that our selected focus area will improve moderator satisfaction, when it is released in Q3.
WE2.1.1	If we build a country-level inference model for Wikipedia articles, we will be able to filter lists of articles to those about a specific region with >70% precision and >50% recall.	m:Research:Language-Agnostic Topic Classification/Countries
WE2.1.2	If we build a proof-of-concept providing translation suggestions that are based on user-selected topic areas, we will be set up to successfully test whether translators will find more opportunities to translate in their areas of interest and contribute more compared to the generic suggestions currently available.	mw: Translation suggestions: Topic-based & Community-defined lists
WE2.1.3	If we offer list-making as a service, we’ll enable at least 5 communities to make more targeted contributions in their topic areas as measured by (1) change in standard quality coverage of relevant topics on the relevant wiki and (2) a brief survey of organizer satisfaction with topic area coverage on-wiki.
WE2.1.4	If we developed a proof of concept that adds translation tasks sourced from WikiProjects and other list-building initiatives, and present them as suggestions within the CX mobile workflow, then more editors would discover and translate articles focused on topical gaps. By introducing an option that allows editors to select translation suggestions based on topical lists, we would test whether this approach increases the content coverage in our projects.	mw: Translation suggestions: Topic-based & Community-defined lists
WE2.2.1	If we expand Wikimedia's State of Languages data by securing data sharing agreements with UNESCO and Ethnologue, at least one partner will decide to represent Wikimedia’s language inclusion progress in their own data products and communications. On top of being useful to our partner institutions, our expanded dataset will provide important contextual information for decision-making and provide communities with information needed to identify areas for intervention.
WE2.2.2	If we map the language documentation activities that Wikimedians have conducted in the last 2 years, we will develop a data-informed baseline for community experiences in onboarding new languages.
WE2.2.3	If we provide production wiki access to 5 new languages, with or without Incubator, we will learn whether access to a full-fledged wiki with modern features such as those available on English Wikipedia (including ContentTranslation and Wikidata support, advanced editing and search results) aids in faster editing. Ultimately, this will inform us if this approach can be a viable direction for language onboarding for new or existing languages, justifying further investigation.	mw:Future of Language Incubation
WE2.3.1	If we make two further improvements to media upload flow on Commons and share them with community, the feedback will be positive and it will help uploaders make less bad uploads (with the focus on copyright) as measured by the ratio of deletion requests within 30 days of upload. This will include defining designs for further UX improvements to the release rights step in the Upload Wizard on Commons and rolling out an MVP of logo detection in the upload flow.	phab:T347298 phab:T349641
WE2.4.1	If we build a prototype of Wikifunctions calls embedded within MediaWiki content, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2.	phab:T261472
WE2.4.2	If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2 (see hypothesis 1).	phab:T363391
WE2.4.3	If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful.	phab:T282926
WE3.1.1	Designing and qualitatively evaluating three proofs of concept focused on building curated, personalized, and community-driven browsing and learning experiences will allow us to estimate the potential for increased reader retention (experiment 1: providing recommended content in search and article contexts, experiment 2: summarizing and simplifying article content, experiment 3: making multitasking easier on wikis.
WE3.1.3	If we develop models for remixing content such as a content simplification or summarization that can be hosted and served via our infrastructure (e.g. LiftWing), we will establish the technical direction for work focused on increasing reader retention through new content discovery features.
WE3.1.4	If we analyze the projected performance impact of hypothesis WE3.1.1 and WE3.1.2 on the Search API, we can scope and address performance and scalability issues before they negatively affect our users.
WE3.1.5	If we enhance the search field in the Android app to recommend personalized content based on a user's interest and display better results, we will learn if this improves user engagement by observing whether it increases the impression and click-through rate (CTR) of search results by 5% in the experimental group compared to the control group over a 30-day A/B test. This improvement could potentially lead to a 1% increase in the retention of logged out users.	phab:T370117
WE3.2.1	If we create a clickable design prototype that demonstrates the concept of a badge representing donors championing article(s) of interest, we can learn if there would be community acceptance for a production version of this method for fundraising in the Apps.	Fundraising Experiment in the iOS App
WE3.2.2	Increasing the prominence of entry points to donations on the logged-out experiences of the web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% Year over Year	phab:T368765
WE3.2.3	If we make the “Donate” button in the iOS App more prominent by making it one click or less away from the main navigation screen, we will learn if discoverability was a barrier to non banner donations.
WE3.3.1	If we select a data visualization library and get an initial version of a new server-rendered graph service available by the end of July, we can learn from volunteers at Wikimania whether we’re working towards a solution that they would use to replace legacy graphs.
WE4.1.1	If we implement a way in which users can report potential instances of harassment and harmful content present in discussions through an incident reporting system, we will be able to gather data around the number and type of incidents being reported and therefore have a better understanding of the landscape and the actions we need to take.
WE4.2.1	If we explore and define Wikimedia-specific methods for a unique device identification model, we will be able to define the collection and storage mechanisms that we can later implement in our anti-abuse workflows to enable more targeted blocking of bad actors.	phab:T368388
WE4.2.9	If we provide contextual information about reputation associated with an IP that is about to be blocked, we will see fewer collateral damage IP and IP range blocks, because administrators will have more insight into potential collateral damage effects of a block. We can measure this by instrumenting Special:Block and observing how behavior changes when additional information is present, vs when it is not.	WE4.2.9 Talk page
WE4.2.2	If we define an algorithm for calculating a user account reputation score for use in anti-abuse workflows, we will prepare the groundwork for engineering efforts that use this score as an additional signal for administrators targeting bad actors on our platform. We will know the hypothesis is successful if the algorithm for calculating a score maps with X% precision to categories of existing accounts, e.g. a "low" score should apply to X% of permanently blocked accounts	WE4.2.2 Talk page
WE4.2.3	If we build an evaluation framework using publicly available technologies similar to the ones used in previous attacks we will learn more about the efficacy of our current CAPTCHA at blocking attacks and could recommend a CAPTCHA replacement that brings a measurable improvement in terms of the attack rate achievable for a given time and financial cost.
WE4.3.1	If we apply some machine learning and data analysis tools to webrequest logs during known attacks, we'll be able to identify abusive IP addresses with at least >80% precision sending largely malicious traffic that we can then ratelimit at the edge, improving reliability for our users.	phab:T368389
WE4.3.2	If we limit the load that known IP addresses of persistent attackers can place on our infrastructure, we'll reduce the number of impactful cachebusting attacks by 20%, improving reliability for our users.
WE4.3.3	If we deploy a proof of concept of the 'Liberica' load balancer, we will measure a 33% improvement in our capacity to handle TCP SYN floods.
WE4.3.4	If we make usability improvements and also perform some training exercises on our 'requestctl' tool, then SREs will report higher confidence in using the tool.	phab:T369480
WE4.4.1	If we run at least 2 deployment cycles of Temp Accounts we will be able to verify this works successfully.
WE5.1.1	If we successfully roll out Parsoid Read Views to all Wikivoyages by Q1, this will boost our confidence in extending Parsoid Read Views to all Wikipedias. We will measure the success of this rollout through detailed evaluations using the Confidence Framework reports, with a particular focus on Visual Diff reports and the metrics related to performance and usability. Additionally, we will assess the reduction in the list of potential blockers, ensuring that critical issues are addressed prior to wider deployment.
WE5.1.2	If we disable unused Graphite metrics, target migrating metrics using the db-prefixed data factory and increase our outreach efforts to other teams and the community in Q1, then we would be on track to achieve our goal of making Graphite read-only by Q3 FY24/25, by observing an increase of 30% in migration progress.
WE5.1.3	If we implement a canonical url structure with versioning for our REST API then we can enable service migration and testing for Parsoid endpoints and similar services by Q1.	phab:T344944
WE5.1.4	If we complete the remaining work to mitigate the impact of browsers' anti-tracking measures on CentralAuth autologin and move to a more resilient authentication infrastructure (SUL3), we will be ready to roll out to production wikis in Q2.
WE5.1.5	If we increase the coverage of Sonar Cloud to include key MediaWiki Core repos, we will be able to improve the maintainability of the MediaWiki codebase. This hypothesis will be measured by spliting the selected repos into test and control groups. These groups will then be compared over the course of a quarter to measure impact of commit level feedback to developers.
WE5.2.1	If we make a classification of the types of hooks and extension registry properties used to influence the behavior of MediaWiki core, we will be able to focus further research and interventions on the most impactful.	[1]
WE5.2.2	If we explore a new architecture for notifications in MW core and Echo, we will discover new ways to provide modularity and new ways for extensions to interact with core.	[2]
WE5.3.1	If we instrument parser and cache code to collect template structure and fine-grained timing data, we can quantify the expected performance improvement which could be realized by future evolution of the wikitext parsing platform.	T371713
WE5.3.2	On template edits, if we can implement an algorithm in Parsoid to reuse HTML of a page that depends on the edited template without processing the page from scratch and demonstrate 1.5x or higher processing speedup, we will have a potential incremental parsing solution for efficient page updates on template edits.	T363421
WE5.4.1	If the MediaWiki engineering group is successful with release process accountability and enhances its communication process by the end of Q2 in alignment with the product strategy, we will eliminate the current process that relies on unplanned or volunteer work and improve community satisfaction with the release process. Measured by community feedback on the 1.43 LTS release coupled with a significant reduction in unplanned staff and volunteer hours needed for release processes.
WE5.4.2	If we research and build a process to more regularly upgrade PHP in conjunction with our MediaWiki release process we will increase speed and security while reducing the complexity and runtime of our CI systems, by observing the success of PHP 8.1 upgrade before 1.43 release.
WE6.1.1	If we design and complete the initial implementation of an authorization framework, we’ll establish a system to effectively manage the approval of all LDAP access requests.
WE6.1.2	If we research available documentation metrics, we can establish metrics that measure the health of Wikimedia technical documentation, using MediaWiki Core documentation as a test case.	mw:Wikimedia Technical Documentation Team/Doc metrics
WE6.1.3	If we collect insights on how different teams are making technical decisions we are able to gather good practices and insights that can enable and scale similar practices across the organization.
WE6.2.1	If we publish a versioned build of MediaWiki, extensions, skins, and Wikimedia configuration at least once per day we will uncover new constraints and establish a baseline of wallclock time needed to perform a build.	mw:Wikimedia Release Engineering Team/Group -1
WE6.2.2	If we replace the backend infrastructure of our existing shared MediaWiki development and testing environments (from apache virtual servers to kubernetes), it will enable us to extend its uses by enabling MediaWiki services in addition to the existing ability to develop MediaWiki core, extensions, and skins in an isolated environment. We will develop one environment that includes MediaWiki, one or more Extensions, and one or more Services.	wikitech:Catalyst
WE6.2.3	If we create a new deployment UI that provides more information to the deployer and reduce the amount of privilege needed to do deployment, it will make deployment easier and open deployments to more users as measured by the number of unique deployers and number of patches backported as a percentage of our overall deployments.	Wikimedia Release Engineering Team/SpiderPig
WE6.2.4	If we migrate votewiki, wikitech and commons to MediaWiki on Kubernetes we reap the benefits of consistency and no longer need to maintain 2 different infrastructure platforms in parallel, allowing to reduce the amount of custom written tooling, making deployments easier and less toilous for deployers. This will be measured by a decrease in total deployment times and a reduction in deployment blockers.	kazi T292707
WE6.2.5	If we move MultiVersion routing out of MediaWiki, we 'll be able to ship single version MediaWiki containers, largely cutting down the size of containers allowing for faster deployments, as measured by the deployment tool.	SingleVersion MW: Routing options
WE6.3.1	By consulting toolforge maintainers about the least sustainable aspects of the platform, we will be able to gather a list of potential categories to measure.
WE6.3.2	By creating a "standard" tool to measure the number of steps for a deployment we will be able to assess the maximal improvement in the deployment process.
WE6.3.3	If we conduct usability tests, user interviews, and competitive analysis to explore the existing workflows and use cases of Toolforge, we can identify key areas for improvement. This research will enable us to prioritize enhancements that have the most significant impact on user satisfaction and efficiency, laying the groundwork for a future design of the user interface.

Signals & Data Services (SDS) Hypotheses [ SDS Key Results ] Majadiliano
Hypothesis shortname	Q1 text	Details & Discussion
SDS 1.1.1	If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics.
SDS1.2.2	If we study the recruitment, retention, and attrition patterns among long-tenure community members in official moderation and administration roles, and understand the factors affecting these phenomena (the ‘why’ behind the trends), we will better understand the extent, nature, and variability of the phenomenon across projects. This will in turn enable us to identify opportunities for better interventions and support aimed at producing a robust multi-generational framework for editors.	phab:T368791
SDS1.2.1	If we gather use cases from product and feature engineering managers around the use of AI in Wikimedia services for readers and contributors, we can determine if we should test and evaluate existing AI models for integration into product features, and if yes, generate a list of candidate models to test.	phab:T369281 Meta Page
SDS1.3.1	If we define the process to transfer all data sets and pipeline configurations from the Data Platform to DataHub we can build tooling to get lineage documentation automatically.
SDS 1.3.2	If we implement a well documented and understood process to produce an intermediary table representing MediaWiki Wikitext History, populated using the event platform, and monitor the reliability and quality of the data we will learn what additional parts of the process are needed to make this table production ready and widely supported by the Data Platform Engineering team.
SDS2.1.2	If we investigate the data products current sdlc, we will be able to determine inflection points where QTE knowledge can be applied in order to have a positive impact on Product Delivery.
SDS2.1.3	If the Growth team learns about the Metrics Platform by instrumenting a Homepage Module on the Metrics Platform, then we will be prepared to outline a measurement plan in Q1 and complete an A/B test on the new Metrics platform by the end of Q2.
SDS2.1.4	If we conduct usability testing on our prototype among pilot users of our experimentation process, we can identify and prioritize the primary pain points faced by product managers and other stakeholders in setting up and analyzing experiments independently. This understanding will lead to the refinement of our tools, enhancing their efficiency and impact.
SDS2.1.5	If we design a documentation system that guides the experience of users building instrumentation using the Metrics Platform, we will enable those users to independently create instrumentation without direct support from Data Products teams, except in edge cases.	phab:T329506
SDS2.2.1	If we define a metric for logged-out mobile app reader retention, which is applicable for analyzing experiments (A/B test), we can provide guidance for planning instrumentation to measure retention rate of logged out readers in the mobile apps and enable the engineering team to develop an experiment strategy targeting logged out readers.
SDS2.2.2	If we define a standard approach for measuring and analyzing conversion rates, it will help us establish a collection of well-defined metrics to be used for experimentation and baselines, and start enabling comparisons between experiments/projects to increase learning from these.
SDS2.2.3	If we define a standard way of measuring and analyzing clickthrough rate (CTR) in our products/features, it will help us design experiments that target CTR for improvement, standardize click-tracking instrumentation, and enable us to make CTR available as a target metric to users of the experimentation platform.
SDS2.3.1	If we conduct a legal review of proposed unique cookies for logged out users, we can determine whether there are any privacy policy or other legal issues which inform the community consultation and/or affect the technical implementation itself.

Future Audiences (FA) Hypotheses [ FA Key Results ] Majadiliano
Hypothesis shortname	Q1 text	Details & Discussion
FA1.1.1	If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform.	m:Future Audiences/Experiment:Add a Fact

Product and Engineering Support (PES) Hypotheses [ PES Key Results ] Majadiliano
Hypothesis shortname	Q1 text	Details & Discussion
PES1.1.1	If the P&T leadership team syncs regularly on how they’re guiding their teams towards a more iterative software development culture, and we collect baseline measurements of current development practices and staff sentiment on how we work together to ship products, we will discover opportunity areas for change management. The themes that emerge will enable us to build targeted guidance or programs for our teams in coming quarters.
PES1.2.2	If the Moderator Tools team researches the Community Wishlist and develops 2+ focus areas in Q1, then we can solicit feedback from the Community and identify a problem that the Community and WMF are excited about tackling.
PES1.2.3	If we bundle 3-5 wishes that relate to selecting and inserting templates, and ship an improved feature in Q1, then CommTech can take the learnings to develop a Case Study for the foundation to incorporate more "focus areas" in the 2025-26 annual plan.
PES1.3.1	If we provide insights to audiences about their community and their use of Wikipedia over a year, it will stimulate greater connection with Wikipedia – encouraging greater engagement in the form of social sharing, time spent interacting on Wikipedia, or donation. Success will be measured by completing an experimental project that provides at least one recommendation about “Wikipedia insights” as an opportunity to increase onwiki engagement.	mw: New Engagement Experiments#PES1.3.1_Wikipedia_user_insights
PES1.3.2	If we create a Wikipedia-based game for daily use that highlights the connections across vast areas of knowledge, it will encourage consumers to visit Wikipedia regularly and facilitate active learning, leading to longer increased interaction with content on Wikipedia. Success will be measured by completing an experimental project that provides at least one recommendation about gamification of learning as an opportunity to increase onwiki engagement.	mw: New Engagement Experiments#PES_1.3.2:_Wikipedia_games
PES1.3.3	If we develop a new process/track at a Wikimedia hack event to incubate future experiments, it will increase the impact and value of such events in becoming a pipeline for future annual plan projects, whilst fostering greater connection between volunteers and engineering/design staff to become more involved with strategic initiatives. Success will be measured by at least one PES1.3 project being initiated and/or advanced to an OKR from a foundation-supported event.	mw: New Engagement Experiments#PES_1.3.3:_Incubator_space
PES1.4.1	If we draft an SLO with the Editing team releasing Edit Check functionality, we will begin to learn and understand how to define and track user-facing SLOs together, and iterate on the process in the future.
PES1.4.2	If we define and publish SLAs for putting OOUI into “maintenance mode”, growth of new code using OOUI across Wikimedia projects will stay within X% in Q1.
PES1.4.3	If we map ownership using the proposed service catalog for known owned services in Q1, we will be able to identify significant gaps in service catalog as it helps in solving the SLO culture by the end of the year.

Q2

The second quarter (Q2) of the WMF annual plan covers October-December.

Wiki Experiences (WE) Hypotheses [ WE Key Results ] Majadiliano
Hypothesis shortname	Q2 text	Details & Discussion
WE1.1.1	If we expand the Event list to become a Community List that includes WikiProjects, then we will be able to gather some early learnings in how to engage with WikiProjects for product development.	Campaigns/Foundation Product Team/Event list
WE1.1.2	If we launch at least 1 consultation focused on on-wiki collaborations, and if we collect feedback from at least 20 people involved in such collaborations, then we will be able to advise Campaigns Product on the key characteristics needed to develop a new or improved way of connecting.	Campaigns/WikiProjects
WE1.1.3	If we consult 20 event organizers and 20 WikiProject organizers on the best use of topics available via LiftWing, then we can prioritize revisions to the topic model that will improve topical connections between events and WikiProjects.
WE1.1.4	If we integrate CampaignEvents into Community Configuration in Q2, then we will set the stage for at least 5 more wikis opting to enable extension features in Q3, thereby increasing tool usage.
WE1.2.2	If we build a library of UI components and visual artifacts, Edit Check’s user experience can extend to accommodate Structured Tasks patterns.
WE1.2.5	If we conduct an A/B/C test with the alt-text suggested edits prototype in the production version of the iOS app we can learn if adding alt-text to images is a task newcomers are successful with and ultimately, decide if it's impactful enough to implement as a suggested edit on the Web and/or in the Apps.
WE1.2.6	If we introduce new account holders to the “Add a Link” Structured Task in Wikipedia articles, we expect to increase the percentage of new account holders who constructively activate on mobile by 10% compared to the baseline.
WE1.3.1	If we enable additional customisation of Automoderator's behaviour and make changes based on pilot project feedback in Q1, more moderators will be satisfied with its feature set and reliability, and will opt to use it on their Wikimedia project, thereby increasing adoption of the product.	mw:Moderator_Tools/Automoderator
WE1.3.3	If we improve the user experience and features of the Nuke extension during Q2, we will increase administrator satisfaction of the product by 5pp by the end of the quarter.	mw:Extension:Nuke/2024_Moderator_Tools_project
WE2.1.3	If we offer list-making as a service, we’ll enable at least 5 communities to make more targeted contributions in their topic areas as measured by (1) change in standard quality coverage of relevant topics on the relevant wiki and (2) a brief survey of organizer satisfaction with topic area coverage on-wiki.
WE2.1.4	If we developed a proof of concept that adds translation tasks sourced from WikiProjects and other list-building initiatives, and present them as suggestions within the CX mobile workflow, then more editors would discover and translate articles focused on topical gaps. By introducing an option that allows editors to select translation suggestions based on topical lists, we would test whether this approach increases the content coverage in our projects.
WE2.1.5	If we expose topic-based translation suggestions more broadly and analyze its initial impact, we will learn which aspects of the translation funnel to act on in order to obtain more quality translations.
WE2.2.4	If we provide production wiki access to 5 new languages, with or without Incubator, we will learn whether access to a full-fledged wiki with modern features such as those available on English Wikipedia (including ContentTranslation and Wikidata support, advanced editing and search results) aids in faster editing. Ultimately, this will inform us if this approach can be a viable direction for language onboarding for new or existing languages, justifying further investigation.
WE2.2.5	If we move addwiki.php to core and customize it to Wikimedia, we will improve code quality in our wiki creation system making it testable and robust, and we will make it easy for creators of new wikis and thereby make significant steps towards simplifying wiki creation process.	phab:T352113
WE2.3.2	If we make two further improvements to media upload flow on Commons and share them with community, the feedback will be positive and it will help uploaders make less bad uploads (with the focus on copyright) as measured by the ratio of deletion requests within 30 days of upload. This will include release of further UX improvements to the release rights step in the Upload Wizard on Commons and automated detection of external sources.
WE2.3.3	If the BHL-Wikimedia Working Group creates Commons categories and descriptive guidelines for the South American and/or African species depicted in publications, they will make 3,000 images more accessible to biodiversity communities. (BHL = Biodiversity Heritage Library)
WE2.4.1	If we build a prototype of Wikifunctions calls embedded within MediaWiki content and test it locally for stability, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2.	phab:T261472
WE2.4.2	If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2, as stated in Hypothesis 1.	phab:T363391
WE2.4.3	If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful.	phab:T282926
WE3.1.3	If we develop models for remixing content such as a content simplification or summarization that can be hosted and served via our infrastructure (e.g. LiftWing), we will establish the technical direction for work focused on increasing reader retention through new content discovery features.	Research
WE3.1.6	If we introduce a personalized rabbit hole feature in the Android app and recommend condensed versions of articles based on the types of topics and sections a user is interested in, we will learn if the feature is sticky enough to result in multi-day usage by 10% of users exposed to the experiment over a 30-day period, and a higher pageview rate than users not exposed to the feature.	Rabbit Holes
WE3.1.7	If we run a qualitative experiment focused on presenting article summaries to web readers, we will determine whether or not article summaries have the potential to increase reader retention, as proxied by clickthrough rate and usage patterns
WE3.1.8	If we build one feature which provides additional article-level recommendations, we will see an increase in clickthrough rate of 10% over existing recommendation options and a significant increase in external referrals for users who actively interact with the new feature.
WE3.2.2	Increasing the prominence of entry points to donations on the logged-out experiences of the Vector web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY.	mw:Readers/2024_Reader_and_Donor_Experiences
WE3.2.3	If we make the “Donate” button in the iOS App more prominent by making it one click or less away from the main navigation screen, we will learn if discoverability was a barrier to non banner donations.	Navigation Refresh
WE3.2.4	If we update the contributions page for logged-in users in the app to include an active badge for someone that is an app donor and display an inactive state with a prompt to donate for someone that decided not to donate in app, we will learn if this recognition is of value to current donors and encourages behavior of donating for prospective donors, informing if it is worth expanding on the concept of donor badges or abandoning it.	Private Donor Recognition Experiment
WE3.2.5	If we create a Wikipedia in Review experiment in the Wikipedia app, to allow users to see and share personalized data about their reading, editing, and donation habits, we will see 2% of viewers donate on iOS as a result of this feature, 5% click share and, 65% of users rating the feature neutral or satisfactory.	Personalized Wikipedia Year in Review
WE3.2.7	Increasing the prominence of entry points to donations on the logged-out experiences of the Minerva web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY.
WE3.3.2	If we develop the Charts MVP and get it working end-to-end in production test wikis, at least two Wikipedias + Commons agree to pilot it before the code freeze in December.
WE3.4.1	If we were to explore the feasibility by doing an experiment of setting up smaller PoPs in cloud providers like Amazon, we can expand our data center map and reach more users around the world, at reduced cost and increased turn-around time.
WE4.1.2	If we deploy at least one iteration of the Incident Reporting System MVP on pilot wikis, we will be able to gather valuable data around the frequency and type of incidents being reported.	https://meta.wikimedia.org/wiki/Incident_Reporting_System#
WE4.2.1	If we explore and define Wikimedia-specific methods for a unique device identification model, we will be able to define the collection and storage mechanisms that we can later implement in our anti-abuse workflows to enable more targeted blocking of bad actors.
WE4.2.9	If we provide contextual information about reputation associated with an IP that is about to be blocked, we will see fewer collateral damage IP and IP range blocks, because administrators will have more insight into potential collateral damage effects of a block. We can measure this by instrumenting Special:Block and observing how behavior changes when additional information is present, vs when it is not.
WE4.2.2	If we define an algorithm for calculating a user account reputation score for use in anti-abuse workflows, we will prepare the groundwork for engineering efforts that use this score as an additional signal for administrators targeting bad actors on our platform. We will know the hypothesis is successful if the algorithm for calculating a score maps with X% precision to categories of existing accounts, e.g. a "low" score should apply to X% of permanently blocked accounts.
WE4.2.3	If we build an evaluation framework using publicly available technologies similar to the ones used in previous attacks we will learn more about the efficacy of our current CAPTCHA at blocking attacks and could recommend a CAPTCHA replacement that brings a measurable improvement in terms of the attack rate achievable for a given time and financial cost.
WE4.3.1	If we apply some machine learning and data analysis tools to webrequest logs during known attacks, we'll be able to identify abusive IP addresses with at least >80% precision sending largely malicious traffic that we can then ratelimit at the edge, improving reliability for our users.
WE4.3.3	If we deploy a proof of concept of the 'Liberica' load balancer, we will measure a 33% improvement in our capacity to handle TCP SYN floods.
WE4.3.5	By creating a system that spawns and controls thousands of virtual workers in a cloud environment, we will be able to simulate Distributed Denial of Service (DDoS) attacks and effectively measure the system's ability to withstand, mitigate, and respond to such attacks.
WE4.3.6	If we integrate the output of the models we built in WE 4.3.1 with the dynamic thresholds of per-ip concurrency limits we've built for our TLS terminators in WE 4.3.2, we should be able to increase our ability to neutralize automatically attacks with 20% more volume, as measured with the simulation framework we're building.
WE4.3.7	If we roll out a user-friendly web application that enables assisted editing and creation of requestctl rules, SREs will be able to mitigate cachebusting attacks in 50% less time than our established baseline.
WE4.4.2	If we deploy Temporary Accounts to a set of small-to-medium sized projects, we will be able to the functionality works as intended and will be able to gather data to inform necessary future work.	mw:/wiki/Trust_and_Safety_Product/Temporary_Accounts
WE5.1.1	If we successfully roll out Parsoid Read Views to all Wikivoyages by Q1, this will boost our confidence in extending Parsoid Read Views to all Wikipedias. We will measure the success of this rollout through detailed evaluations using the Confidence Framework reports, with a particular focus on Visual Diff reports and the metrics related to performance and usability. Additionally, we will assess the reduction in the list of potential blockers, ensuring that critical issues are addressed prior to wider deployment.
WE5.1.3	If we reroute the endpoints currently exposed under rest_v1/page/html and rest_v1/page/title paths to comparable MW content endpoints, then we can unblock RESTbase sunsetting without disrupting clients in Q1.
WE5.1.4	If we complete the remaining work to mitigate the impact of browsers' anti-tracking measures on CentralAuth autologin and move to a more resilient authentication infrastructure (SUL3), we will be ready to roll out to production wikis in Q2.
WE5.1.5	If we increase the number of relevant SonarCloud rules enabled for key MediaWiki Core repositories and refine the quality of feedback provided to developers, we will optimize the developer experience and enable them to improve the maintainability of the MediaWiki codebase in the future. This will be measured by tracking developer satisfaction levels and whether test group developers feel the tool is becoming more useful and effective in their workflow. Feedback will be gathered through surveys and direct input from developers to evaluate the perceived impact on their confidence in the tool and the overall development experience.
WE5.1.7	If we represent all content module endpoint responses (10 in total) in our MediaWiki REST API OpenAPI spec definitions, we will be able to implement programmatic validation to guarantee that our generated documentation matches the actual responses returned in code.
WE5.1.8	If we introduce support for endpoint description translation (ie: does not include actual object definitions or payloads) into our generated MediaWiki REST API OpenAPI specs, we can lay the foundation to support Wikimedia’s expected internationalization standards.
WE5.2.3	If we conduct an experiment to reimplement at least [1-3] existing Core and Extension features using a new Domain Event and Listener platform component pattern as an alternative to traditional hooks, we will be able to confirm our assumption of this intervention enabling simpler implementation with more consistent feature behavior.
WE5.3.3	If we instrument both parsers to collect availability of prior parses and timing of template expansions, and to classify updates and dependencies, we can prioritize work on selective updates (Hypothesis 5.3.2) informed by the quantification of the expected performance benefits.
WE5.3.4	If we can increase the capability of our prototype selective update implementation in Parsoid using the learnings from the 5.3.1 hypothesis, we can leverage more opportunities to increase the performance benefit from selective update.
WE5.4.1	If the MediaWiki engineering group is successful with release process accountability and enhances its communication process by the end of Q2 in alignment with the product strategy, we will eliminate the current process that relies on unplanned or volunteer work and improve community satisfaction with the release process. Measured by community feedback on the 1.43 LTS release coupled with a significant reduction in unplanned staff and volunteer hours needed for release processes.
WE5.4.2	If we research and build a process to more regularly upgrade PHP in conjunction with our MediaWiki release process we will increase speed and security while reducing the complexity and runtime of our CI systems, by observing the success of PHP 8.1 upgrade before 1.43 release.
WE6.1.3	If we collect insights on how different teams are making technical decisions we are able to gather good practices and insights that can enable and scale similar practices across the organization.
WE6.1.4	If we research solutions for indexing the code of all projects hosted in WMF’s code repositories, we will be able to pick a solution that allows our users to quickly discover where the code is located whenever dealing with incident response or troubleshooting.
WE6.1.5	If we test a subset of draft metrics on an experimental group of technical documentation collections, we will be able to make an informed decision about which metrics to implement for MediaWiki documentation.	Wikimedia_Technical_Documentation_Team/Doc_metrics
WE6.2.1	If we publish a versioned build of MediaWiki, extensions, skins, and Wikimedia configuration at least once per day we will uncover new constraints and establish a baseline of wallclock time needed to perform a build.	mw:Wikimedia Release Engineering Team/Group -1
WE6.2.2	If we replace the backend infrastructure of our existing shared MediaWiki development and testing environments (from apache virtual servers to kubernetes), it will enable us to extend its uses by enabling MediaWiki services in addition to the existing ability to develop MediaWiki core, extensions, and skins in an isolated environment. We will develop one environment that includes MediaWiki, one or more Extensions, and one or more Services.	wikitech:Catalyst
WE6.2.3	If we create a new deployment UI that provides more information to the deployer and reduce the amount of privilege needed to do deployment, it will make deployment easier and open deployments to more users as measured by the number of unique deployers and number of patches backported as a percentage of our overall deployments.	mw:SpiderPig
WE6.2.5	If we move MultiVersion routing out of MediaWiki, we 'll be able to ship single version MediaWiki containers, largely cutting down the size of containers allowing for faster deployments, as measured by the deployment tool.	https://docs.google.com/document/d/1_AChNfiRFL3VdNzf6QFSCL9pM2gZbgLoMyAys9KKmKc/edit
WE6.2.6	If we gather feedback from QTE, SRE, and individuals with domain specific knowledge and use their feedback to write a design document for deploying and using the wmf/next OCI container, then we will reduce friction when we start deploying that container.	T379683
WE6.3.4	If we enable the automatic deployment of a minimal tool, we will be able to evaluate the end to end flow and set the groundwork to adding support for more complex tools and deployment flows.	phab:T375199
WE6.3.5	By assessing the relative importance of each sustainability category and its associated metrics, we can create a normalized scoring system. This system, when implemented and recorded, will provide a baseline for measuring and comparing Toolforge’s sustainability progress over time.	phab:T376896
WE6.3.6	If we conduct discovery, such as target user interviews and competitive analysis, to identify existing Toolforge pain points and improvement opportunities, we will be able to recommend a prioritized list of features for the future Toolforge UI.	Phab:T375914

Signals & Data Services (SDS) Hypotheses [ SDS Key Results ] Majadiliano
Hypothesis shortname	Q2 text	Details & Discussion
SDS 1.1.1	If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics.
SDS1.2.1.B	If we test the accuracy and infrastructure constraints of 4 existing AI language models for 2 or more high-priority product use-cases, we will be able to write a report recommending at least one AI model that we can use for further tuning towards strategic product investments.	Phab:T377159 Learn more.
SDS1.2.2	If we study the recruitment, retention, and attrition patterns among long-tenure community members in official moderation and administration roles, and understand the factors affecting these phenomena (the ‘why’ behind the trends), we will better understand the extent, nature, and variability of the phenomenon across projects. This will in turn enable us to identify opportunities for better interventions and support aimed at producing a robust multi-generational framework for editors.	Learn more.
SDS1.2.3	If we combine existing knowledge about moderators with quantitative methods for detecting moderation activity, we can systematically define and identify Wikipedia moderators.	T376684
SDS1.3.1.B	If we integrate the Spark / DataHub connector for all production Spark jobs, we will get column-level lineage for all Spark-based data platform jobs in DataHub.
SDS1.3.2.B	If we implement a frequently run Spark-based MariaDB MW history data querying job, reconciliate missing events and enrich them, we will provide a daily updated MW history wikitext content data lake table.
SDS2.1.1	If we create an integration test environment for the proposed 3rd party experimentation solution, we can collaborate practically with Data SRE, SRE, QTE, and Product Analytics to evaluate the solution’s viability within WMF infrastructure in order to make a confident build/install/buy recommendation.	mw:Data_Platform_Engineering/Data_Products/work_focus
SDS2.1.3	If the Growth team learns about the Metrics Platform by instrumenting a Homepage Module on the Metrics Platform, then we will be prepared to outline a measurement plan in Q1 and complete an A/B test on the new Metrics platform by the end of Q2.
SDS2.1.4	If we conduct usability testing on our prototype among pilot users of our experimentation process, we can identify and prioritize the primary pain points faced by product managers and other stakeholders in setting up and analyzing experiments independently. This understanding will lead to the refinement of our tools, enhancing their efficiency and impact.
SDS2.1.5	If we design a documentation system that guides the experience of users building instrumentation using the Metrics Platform, we will enable those users to independently create instrumentation without direct support from Data Products teams, except in edge cases.	kazi T329506
SDS2.1.7	If we provide a function for user enrollment and a mechanism to capture and store CTR events to a monotable in a pre-declared event stream we can ship MPIC Alpha in order to launch an basic split A/B test on logged in users.
SDS2.2.2	If we define a standard approach for measuring and analyzing conversion rates, it will help us establish a collection of well-defined metrics to be used for experimentation and baselines, and start enabling comparisons between experiments/projects to increase learning from these.
SDS2.3.1	If we conduct a legal review of proposed unique cookies for logged out users, we can determine whether there are any privacy policy or other legal issues which inform the community consultation and/or affect the technical implementation itself.

Future Audiences (FA) Hypotheses [ FA Key Results ] Majadiliano
Hypothesis shortname	Q2 text	Details & Discussion
FA1.1.1	If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform.	Experiment:Add a Fact

Product and Engineering Support (PES) Hypotheses [ PES Key Results ] Majadiliano
Hypothesis shortname	Q2 text	Details & Discussion
PES1.2.4	If we research the Task Prioritization focus area in the Community Wishlist in early Q2, we will be able to identify and prioritize work that will improve moderator satisfaction, which we can begin implementing in Q3.
PES1.2.5	If we are able to publish and receive community feedback on 6+ focus areas in Q2, then we will have confidence in presenting at least 3+ focus areas for incorporation in the 2025-26 annual plan.
PES1.2.6	By introducing favouriting templates, we will improve the number of templates added via the template dialog by 10%.
PES1.3.4	If we create an experience that provides insights to Wikipedia Audiences about their community over the year, it will stimulate greater connection with Wikipedia – encouraging engagement in the form of social sharing, time spent interacting on Wikipedia, or donation.
PES1.4.1	If we draft an SLO with the Editing team releasing Edit Check functionality, we will begin to learn and understand how to define and track user-facing SLOs together, and iterate on the process in the future.
PES1.4.2	If we define and publish SLAs for putting OOUI into “maintenance mode”, growth of new code using OOUI across Wikimedia projects will stay within X% in Q1.
PES1.4.3	If we map ownership using the proposed service catalog for known owned services in Q1, we will be able to identify significant gaps in service catalog as it helps in solving the SLO culture by the end of the year.
PES1.5.1	If we finalize and publish the Edit Check SLO draft, practice incorporating it in regular workflows and decisions, and draft a Citoid SLO, we’ll continue learning how to define and track user-facing and cross-team SLOs together.
PES1.5.2	If we clarify and define in writing a document with set of roles and responsibilities of stakeholders throughout the service lifecycle, this will enable teams to make informed commitments in the Service Catalog, including SLOs

Ufafanuzi wa ndoo

Uzoefu wa Wiki

Diversity (40786) – The Noun Project

Madhumuni ya kapu hili ni kuwasilisha, kuboresha na kuvumbua kwa ufanisi uzoefu wa wiki unaowezesha usambazaji wa maarifa bila malipo duniani kote. Kapu hili linalingana na mapendekezo ya mkakati wa harakati #2 (Kuboresha Uzoefu wa Mtumiaji) na #3 (Kuwezesha Usalama na Ujumuisho). Watazamaji wetu ni pamoja na washirika wote kwenye tovuti zetu, pamoja na wasomaji na watumiaji wengine wa maarifa bila malipo. Tunatumia tovuti 10 bora duniani, na rasilimali nyingine nyingi muhimu za utamaduni bila malipo. Mifumo hii ina mahitaji ya utendaji na muda wa kufanya kazi sambamba na makampuni makubwa zaidi ya teknolojia duniani. Tunatoa violesura vya watumiaji kwa wiki, tafsiri, API za wasanidi (na zaidi!) na kusaidia programu na miundomsingi ambayo yote huunda jukwaa thabiti kwa wanaojitolea kushirikiana ili kutoa maarifa bila malipo duniani kote. Malengo yetu ya Kapu hili yanapaswa kutuwezesha kuboresha teknolojia na uwezo wetu mkuu, kuhakikisha tunaboresha daima uzoefu wa wahariri na wasimamizi wa kujitolea wa miradi yetu, kuboresha uzoefu wa wachangiaji wote wa kiufundi wanaofanya kazi ili kuboresha au kuboresha uzoefu wa wiki, na kuhakikisha kuwa uzoefu mzuri kwa wasomaji na watumiaji wa maarifa ya bure ulimwenguni kote. Tutafanya hivi kupitia kazi ya bidhaa na teknolojia, na pia kupitia utafiti na uuzaji. Tunatarajia kuwa na angalau malengo matano kwa ndoo hili.

Maarifa hujengwa na watu! Na matokeo yake mpango wetu wa kila mwaka utazingatia yaliyomo pamoja na watu wanaochangia yaliyomo na wale wanaopata na kuisoma.

Lengo letu ni kutoa mpango wa uendeshaji kulingana na mkakati uliopo, hasa nadharia zetu kuhusu mchangiaji, mtumiaji na maudhui "gurudumu endeshi". Mabadiliko ya msingi ninayouliza ni msisitizo wa sehemu ya maudhui ya gurudumu endeshi, na uchunguzi wa kile ambacho wasimamizi na watendaji wetu wanaweza kuhitaji kutoka kwetu sasa, kwa lengo la kutambua vipimo vya afya ya jamii katika siku zijazo.

Mawimbi na Huduma za Data

Arrythmia noun 246518

Ili kukidhi Mapendekezo ya Mkakati wa Harakati kwa Kuhakikisha Usawa katika Kufanya Maamuzi (Pendekezo #4), Kuboresha Uzoefu wa Mtumiaji (Pendekezo #2), na Kutathmini, Kurekebisha na Kurekebisha (Pendekezo #10), watoa maamuzi kutoka kote kwenye harakati za Wikimedia lazima wawe na uwezo wa kufikia data, miundo, maarifa na zana zinazotegemeka, zinazofaa na zinazofaa kwa wakati unaofaa zinazoweza kuwasaidia kutathmini athari (zinazopatikana na zinazowezekana) za kazi zao. na kazi za jumuiya zao, kuwawezesha kufanya maamuzi bora ya kimkakati.

Katika kapu la Huduma za Mawimbi na Data, tumetambua hadhira nne za msingi: Wafanyakazi wa Wikimedia Foundation, washirika wa Wikimedia na vikundi vya watumiaji, wasanidi programu wanaotumia tena maudhui yetu, na watafiti wa Wikimedia, na tunatanguliza na kushughulikia mahitaji ya data na maarifa ya hadhira hii. Kazi yetu itahusisha shughuli mbalimbali: kufafanua mapengo, kuunda vipimo, kujenga njia wezeshi za vipimo vya kompyuta, na kuendeleza uzoefu wa utafutaji wa data na mawimbi na njia zinazosaidia watoa maamuzi kuingiliana kwa ufanisi na furaha zaidi na data na maarifa.

Hadhira za Baadaye

Madhumuni ya kapu hili ni kuchunguza mikakati ya kupanua zaidi ya hadhira yetu iliyopo ya watumiaji na wachangiaji, katika juhudi za kufikia kila mtu ulimwenguni kama miundombinu muhimu ya mfumo ikolojia wa maarifa bila malipo. Kapu hili linalingana na Pendekezo la Mkakati wa Mwendo #9 (Ubunifu kwa Maarifa Bila Malipo). Zaidi na zaidi, watu wanatumia maelezo katika hali ya utumiaji na miundo ambayo inatofautiana na utoaji wetu wa kawaida wa tovuti yenye makala - watu wanatumia visaidizi vya sauti, wanatumia muda na video, kujihusisha na AI, na zaidi. Katika Kapu hili, tutapendekeza na kujaribu dhahania kuhusu mustakabali unaowezekana wa muda mrefu wa mfumo ikolojia wa maarifa bila malipo na jinsi tutakavyokuwa miundombinu yake muhimu. Tutafanya hivi kupitia kazi ya bidhaa na teknolojia, na pia kupitia utafiti, ubia na uuzaji. Tunapotambua majimbo yajayo yenye matumaini, mafunzo kutoka kwa Kapu hili yataathiri na kupanuliwa kupitia Ndoo #1 na #2 katika mipango ya kila mwaka inayofuatana, na kugusa matoleo yetu ya bidhaa na teknolojia kuelekea pale yanapohitajika ili kuwahudumia wanaotafuta ujuzi wa siku zijazo. Malengo yetu ya Kapu hili yanapaswa kutusukuma kufanya majaribio na kuchunguza tunapoleta maono ya mustakabali wa maarifa ya bila malipo.

Ndoo ndogo

Noun project 3067

Pia tuna "ndoo ndogo" mengine mawili ambayo yanajumuisha maeneo ya kazi muhimu, ambayo lazima yawepo kwenye Shirika ili kusaidia shughuli zetu za kimsingi, na zingine ambazo tunafanana na shirika lolote la programu. "ndoo ndogo" haya hayatakuwa na malengo ya kiwango cha juu yenyewe, lakini yatakuwa na mchango na yatasaidia malengo ya ngazi ya juu ya vikundi vingine. Ambayo ni:

1. Misingi ya Miundombinu. Kapu hili linashughulikia timu zinazoleta uendelevu na kuendeleza vituo vyetu vya kuhifadhia data, mifumo yetu ya kukokotoa na kuhifadhi, huduma za kuziendesha, zana na michakato inayowezesha utendakazi wa tovuti na huduma zetu zinazokabili umma.
2. Usaidizi wa Bidhaa na Uhandisi. Kapu hili linajumuisha timu zinazofanya kazi "kwa kiwango" kutoa huduma kwa timu zingine ambazo huboresha tija na utendakazi wa timu zingine.