Atụmatụ Afọ nke Wikimedia Foundation/2024-2025/Ngwa ahịa na tecknụzụ OKRS
Akwụkwọ a na-anọchite anya akụkụ mbụ nke usoro atụmatụ afọ nke 2024-25 maka ngalaba Ngwaahịa & Teknụzụ nke Wikimedia Foundation. Ọ na-akọwa akwụkwọ ndepụta ngalaba banyere "ebumnobi na mpụtara" (OKRs). Nke a bụ nkwado nke usoro ọrụ dị iche iche (a kpọrọ "buckets") nke malitere n'afọ gara aga.
.jpg)
A gwaram m unu niile okwu na Nọvemba gara aga banyere ihe m kwenyere bụ ajụjụ kacha dị mkpa chere otu Wikimedia ihu: kedu ka anyị ga-esi hụ na Wikipedia na ọrụ Wikimedia niile metụtara ọtụtụ ọgbọ? Ọ ga-amasị m ikele onye ọ bụla wepụtara oge iji chebara ajụjụ ahụ echiche ma zahachim, ma ugbu a m nwere ohere ilebanya n'echiche na nzaghachi unu, m ga-ekwupụtakwa ihem mụtara. .
Nke mbụ, ọ dịghị otu ihe mere ndị ọrụ afọ ofufo ji enye aka. Iji zụlite ọtụtụ ọgbọ nke ndị ọrụ afọ ofufo, anyị kwesịrị ịghọta nke ọma ọtụtụ ihe mere ndị mmadụ ji etinye oge ha n'ọrụ anyị. Ọzọ, anyị kwesịrị ilekwasị anya n'ihe mere anyị adị iche: nkwudosike anyị ịnye ọdịnaya kwesịrị ntụkwasị obi ka mgbasa ozi na ozi na-ezighi ezi na-agbasa na ịntanetị yana ebe dịgasị na-amaaka nye nlebara anya nke ọgbọ ọhụrụ. Nke a gụnyere ịgba mbọ hụ na anyị nwetara ozi iji chịkọta ma nyefee nchikota nke ihe ọmụma mmadụ niile n'ụwa site n'ịgbasawanye ihe ọmụma anyị n'ekesasibeghi, nke nwere ike isite na ezighị ezi ihe, ịkpa ókè ma ọ bụ nke ihu abụọ. Ọdịnaya anyị kwesịrị ije ozi ma nọgide na-ịdị mkpa na ịntanetị na eme mgbanwe kwa mgbe nke ọgụgụ isi na ahụmịhe bara ụba na-akwalite. N'ikpeazụ, anyị kwesịrị ịchọta ụzọ anyị ga-esi na-akwado otu anyị site n'ịmepụta atụmatụ nkekọrịta maka ngwaahịa na ihe anyị na-enweta ka anyị nwee ike ịkwado ọrụ a ogologo oge.
A ga-egosipụta echiche ndị a na atụmatụ afọ 2024-2025 nke Wikimedia Foundation, akụkụ mbụ nke m na-ekesara unu taa n'ụdị ebumnuche edesitara maka ọrụ ngwaahịa na teknụzụ anyị. Dị ka afọ gara aga. , atụmatụ anyị niile kwa afọ ga-adabere na mkpa teknụzụ nke ndị na-ege anyị nti na nhiwe, anyị ga-achọkwa nzaghachi gị iji mara ma anyị na-elekwasị anya na nsogbu ndị ziri ezi. Ebumnobi ndị a ga-enyeaka chịkọta echiche anyị na-anụ n'aka ndị ngalaba otu n'ime ọnwa ole na ole gara aga site na Talking:2024, na ndepụta nzipu ozi na ibe okwu, yana na ọgbakọ otu nwere gbasara atụmatụ ngwaahịa na teknụzụ anyị maka afọ na-abịa. . Ị nwere ike ịhụ ndesịta ebumnobi n'uju n'okpuru.
"Ebumnobi" bụ ntụziaka dị elu nke ga-achịkọba ngwaahịa na ọrụ nkà na ụzụ anyị na-eme maka afọ mmefu ego na-esote. A kpachara anya mee ha asaa asa, na-anọchi anya ntụzịaka nke atụmatụ anyị yana, nke kacha mkpa, ihe ịma aka ndị anyị na-atụ aro ga-ebute ụzọ n'etiti ọtụtụ nrụaka a ga-elekwasị anya maka afọ na-abịa abịa. Anyị na-ekesarịta nke a ugbu a ka ndị otu ngalaba nwee ike inye aka n'ịchịkọba echiche mmalite anyị yana tupu etinye mgbakọ mmefu ego na ebumnuche ndị atụọrala maka afọ.
Nzaghachi
Otu mpaghara anyị ga-atụkaarị anya nzaghachi bụ ọrụ anyị nke achịkọtara n'okpuru aha akpọrọ "ahụmahụ Wiki." "ahụmahụ Wiki" bụ maka otu anyị si ewepụta nke ọma, imelite, na imeputa ka ndị mmadụ si eji wiki eme ihe kpomkwem, ma ọ bụladị dịka ndị ntinye aka, ndị ahịa, ma ọ bụ ndị nyere onyinye. Nke a gụnyere ọrụ iji kwado isi teknụzụ na mmataara anyị yana igba mbọ hụ na anyị nwere ike imeziwanye ahụmịhe nke ndị ndezi afọ ofufo - ọkachasị, ndị ndezi nwere ikike - site na njirimara na ngwa ọrụ ka mma, ọrụ ntụgharị asụsụ na nkwalite ikpo okwu.
Nke a bụ ụfọdụ ntụgharị uche sitere na mkparịta ụka atụmatụ anyị na nso nso a, yana ajụjụ ụfọdụ nye unu niile iji nyere anyị aka imepụta echiche anyị:
- Ịnyeaka afọ ofufu na oru Wikimedia kwesịrị inwe ihe na-agba ume. Anyị na-echekwa na ahụmahụ nke imekọ ihe n'ịntanetị kwesịrị ịbụ akụkụ bụ isi nke ihe na-eme ka ndị ọrụ afọ ofufo lọghachi. Kedu ihe ọ na-ewe ka ndị ọrụ afọ ofufo hụta ndezi dịka ihe bara uru, na ịrụkọ ọrụ nke ọma iji wuo ọdịnaya kwesịrị ntụkwasị obi?
- Ntụkwasị obi nke ọdịnaya anyị bụ akụkụ nke ntunye pụrụ iche nke Wikimedia nyere ụwa, yana ihe na-eme ka ndị mmadụ na-abịa n'elu ihe anyị na iji ọdịnaya anyị mee ihe. Kedu ihe anyị nwere ike wulite nke ga-enyere aka bawanye ọdịnaya kwesịrị ntụkwasị obi ngwa ngwa, mana nke ka nọ n'ọnọdụ nchekwa dị mma nke otu ngalaba setịpụrụ na ọrụ ọ bụla?
- iji nọgide na-adị mkpa mana amaaka na nnukwu nhiwe ịntanetị ndị ọzọ, Wikimedia chọrọ ọgbọ ọhụrụ nke ndị na-azụ ahịa ka ha nwee mmetụta nke njikọ na ọdịnaya anyị. Kedu ka anyị ga-esi mee ka ọdịnaya anyị dị mfe ịchọpụta na imekọrịta ihe maka ndị na-agụ na ndị na-enye onyinye?
- N'ime afọ ebe mmegbu ịntanetị na-arị elụ, anyị kwesịrị ịgba mbọ hụ na echekwabara otu anyị, ọgbakọ na sistemụ ozi. Anyị na-echekwa ọrụ nnabata na-agbanwe agbanwe, ebe ndị omebe iwu zuru ụwa ọnụ na-ele anya ịkpụzi nzochi, njirimara, na ịkekọrịta ozi n'ịntanetị. Kedu mmelite nke ikike ịlụ ọgụ mmegbu ga-enyere anyị aka imeri nsogbu ndị a?
- MediaWiki, ọgbakọ sọftụwia na oghere na-enye ohere ka Wikipedia rụọ ọrụ, chọrọ nkwado na-aga n'ihu n'ime afọ iri na-abịanụ iji nye ihe okike, nchịkọba, nchekwa, nchọpụta, na ojiji nke, ọtụtụ ọdịnaya efu nke ọtụtụ asụsụ. Kedu mkpebi na nkwalite ọgbakọ anyị nwere ike ime n'afọ a iji hụ na MediaWiki na-adigide?
Ebumnobi Edepụtara
Atụmatụ kachasị elu bụ nke ebipụtarala ugbu a - " Ebumnobi ".
Ogo na-esote - akwụkwọ edepụtara " isi mpụtara" (KR) maka ebumnuche ọ bụla edepụtacharala ka ewepụtara n'ala.
A ga-emelite " Echiche " nke KR ọ bụla na ibe ọrụ / otu wiki dị mkpa n'ime afọ niile ka emelite ya n'ime afọ niile ka a enweamụta ihe.
| Wiki Experiences (WE) ebumnuche edepụtara | ||||
|---|---|---|---|---|
| Ebumnobi | Mpaghara ebumnobi | Ebumnobi | Ọnọdụ ebumnuche | onye nwe ihe |
| WE1 | mmụtara onye ntunye | Ndị ntinye aka nwere m̀mụtara na ndị ntunye aka ọhụrụ na-agbakọta ọnụ n'ịntanetị iji wuo akwụkwọ nkà ihe ọmụma kwesịrị ntụkwasị obi, site na usoro dị mfe na mbelata mgbakasị ahụ. | iji mee ka Wikipedia wee nwee mmetụta n'ime afọ ndị na-abịa, anyị aghaghị ịrụ ọrụ na-akwalite ọtụtụ ọgbọ nke ndị ọrụ afọ ofufo ma mee inya aka ọrụ ka ọ bụrụ ihe ndị mmadụ chọrọ ime. Ọgbọ dị iche iche nke ndị ọrụ afọ ofufo chọrọ ime ntunye -- ndị nnyere aka nwere m̀mụtara chọrọ ka ahazigharịa ma mezie usoro ọrụ ha dị ike, ebe ndị ntinye aka ọhụrụ chọrọ ụzọ ọhụrụ iji dezie nke baara ha uru . Na n'ofe ọgbọ ndị a, ndị ntinye aka niile kwesịrị inwe ike ijikọ na imekọ ihe ọnụ iji rụọ ọrụ ha kacha enwe mmetụta. Site n'ebumnobi a, anyị ga-emeziwanye usoro ọrụ dị oke mkpa maka ndị nnyere aka nwere m̀mụtara, anyị ga-ebelata ihe mgbochi nye ntinye aka bara uru nke ndị bịara ọhụrụ, anyị ga-emekwa ntunye n'ụzọ ndị ọrụ afọ ofufo nwere ike ịchọta ma na-ekwurịta okwu n'etiti onwe ebe o metụtara g ọdịmma. | Marshall Miller |
| WE2 | Ọdịnaya nke nchịkọta ọtụtụ mmụta | A ga-akwado ngalaba otu iji nye ezi mmechi oghere ihe ọmụma site na akụrụngwa na usoro nkwado ndị dị mfe ịnweta, di mfe ojiji, na nkwalite, ma na-agbambọ hụ na-enwere mbawanye nke ọdịnaya ọtụtụ mmụta a pụrụ ịtụkwasị obi. | Enwere ike imelite na ịbawanye ọdịnaya nke ọtụtụ mmụta nke dị na Wikipedia site na ntinye aka na imepụta ihe ọhụrụ na-aga n'ihu. Enwere ike ime ka achọpụta Ngwa na akụrụngwa enwere ike ịtụkwasị obi (ma nke teknikal na nke na-abụghị nke teknikal) nke dị maka ndị ntinye aka iji mee ihe site n'ọchịchọ ha. Ngwa ndị a kwesịrị ka WMF kwado ya nke ọma, site na nkwalite atụmatụ enwere ike nweta na obere ngụkọ. Na nlere anya nke usoro dị ugbu a bụ ndị enwetara site na-enyemaka nnweta odinaya na AI na mgbanwe omume onye ọrụ, anyị ga-enyocha ntọala maka mgbanwe dị ukwuu (dịka Wikifunctions) nke nwere ike inye aka n'ịkwalite mmụba na imepụta na ijiji ọdịnaya ya. Usoro iji chọpụta oghere nke ọdịnaya kwesịrị ịdị mfe ịchọpụta, ma jiri ya hazie atụmatụ. Akụrụngwa na-akwado uto nke ọdịnaya nke ọtụtụ mmụta, nke gụnyere ọdịnaya dị na oru ngo nke umunne ọrụ, ọrụ dịka ọba akwụkwọ Wikipedia, na mkpọsa nwere ike ijikọ nke ọma na ntinye ọrụ ntinye aka. N'otu oge ahụ, ụzọ a na-eji eto eto kwesịrị inwe ihe nchebe megide ihe ịmaaka n'emetụta uto, nke nwere ike hụ na a na-enwe ntụkwasị obi na-aga n'ihu na usoro ahụ ka ọ na-anọgide na-agbaso ụkpụrụ nke ọdịnaya ọtụtụ mmụta dị ka a ghọtara n'ofe ọrụ Wikimedia.
Ndị na-ege ntị: Ndị ndezi, ndị ntụgharị |
Runa Bhattacharjee |
| WE3 | Ahụmahụ ndị ojieme ihe (Ọgụgụ & Mgbasa ozi) | Ọgbọ ọhụrụ nke ndị na-eji ọru eme ihe na-abịarute na Wikipedia iji chọpụta ebe kachasị amasị maka ịchọpụta, itinye aka na iwulite njikọ na-adịgide adịgide na ọdịnaya nke ọtụtụ mmụta. | Ebumnuche:
Jidesie ndị nọọralanụ na ọgbọ ọhụrụ nke ndị ahịa na ndị nyere onyinye. Mụbaa ịdị mkpa nye ndị nọọrọlanụ na ọgbọ ọhụrụ nke ndị na-eji ọrụ a eme ihe iji site n'ime ka ọdịnaya anyị dịkwuo mfe ịchọpụta na mekọrịta. Na-arụ ọrụ n'ofe ọgbakọ iji gbanwee ahumihe anyị na ọdịnaya dị bunụ, ka e wee nyochaa ma chịkọba ọdịnaya nke ọtụtụ mmụta site na na ọgbọ ọhụrụ nyekwa ọgbọ ọhụrụ nke ndị na-azụ ahịa na ndị na-enye onyinye. |
Olga Vasileva |
| WE4 | Ntụkwasị obi & Nchekwa | Meziwanye akụrụngwa, ngwa ọrụ, na usoro anyị ka anyị wee kwado nke ọma ichebe ngalaba otu, ọgbakọ, na sistemụ ozi anyị site na ụdị mkparị dị iche iche ewetara ka a na-edobe nnabata na gburugburu usoro nhazi mgbanwe. | Akụkụ ụfọdụ nke ikike ịlụ ọgụ mmegbu n'ụzọ ọjọọ anyị chọrọ nkwalite. Mbelata mmegbu nke dabeere na IP na-aghọ nke na-adịchaghị irè, ọtụtụ ngwaọrụ ndị nchịkwa chọrọ ndozi arụmọrụ, yana anyị kwesịrị iwekọta atụmatụ dị n'otu nke na-enyere anyị aka ịlụso mmetọ ahụ ọgụ site na iji akara dị iche iche na usoro mbelata (captchas, mkpọchi, wdg). na ngosi. N'ime afọ a, anyị ga-amalite inwe ọganihu na nsogbu kachasị ukwuu na ebe a. Ọzọkwa, itinye ego a na nchedo mmegbu ga-edozirịrị site na ime ntunye na nghọta na nkwalite ahụike otu, ọtụtụ akụkụ nke etinyere n'usoro nlebanya dị iche iche. | Suman Cherukuwada |
| WE5 | Ebe mmụta I ( Platform evolution) | Gbanwee ebe ọrụ MediaWiki na ihu ya iji gboo mkpa Wikipedia nke ọma. | Ewubere MediaWiki maka iji mepụta, chịkọba, chekwaa, chọpụta na iji mee ihe nke, ọdịnaya ọtụtụ asụsụ efu n'ogo. N'afọ nke abụọ nke ebe Ọmụma a, anyị ga-eleba anya na usoro a wee malite ịrụ ọrụ maka nkwalite ebe ọrụ a iji kwado nke ọma ọrụ Wikimedia bụ isi mkpa n'ime afọ iri na-abịanụ, malite na Wikipedia. Nke a na-agụnye ọrụ na-aga n'ihu iji kọwaa ebe ọrụ mmepụta ihe ọmụma anyị, na-ewusi nkwado nke ebe ọrụ ike, na-elekwasị anya na usoro mwesa / nko iji dokwuo anya na ịmepụta mmepe njirimara, na ịnọgide na-eme ntunye nye nkekọrịta mmụta na ime ka ndị mmadụ nwee ike inye aka na MediaWiki. | Birgit Müller |
| WE6 | Ebe mmụta II ( Developer Services) | Ndị ọrụ nka na ndị ọrụ mmepe afọ ofufo nwere ngwa ọrụ ha chọrọ iji kwado ọrụ Wikimedia nke ọma. | Anyị ga-aga n'ihu na-arụ ọrụ amalitere iji melite (na ọnụ ọgụgụ) mmepe, nwale na nkesa ọrụ na mmepụta Wikimedia ma gbasaa nkọwa iji tinye ọrụ nye ndị mmepe ngwá ọrụ. Anyị na-achọkwa imeziwanye ikike anyị ịza ajụjụ ndị a na-ajụkarị na ngalaba nke onye nrụpụta / injinia na-arụm ọrụ na ndị na-ege ntị ma mee ka data dị mkpa di mfe nweta iji nye ọkwa mkpebi zuru oke. Akụkụ nke ọrụ a bụ ile omume (ma ọ bụ enweghị ndị dị otú ahụ) nke na-eweta ihe ịma aka ugbu a nye gburugburu anyị. | Birgit Müller |
| Signals and Data Services (SDS) ebumnobi edepụtara | ||||
|---|---|---|---|---|
| Ebumnobi | Mpaghara ebumnobi | Ebumnobi | Ọnọdụ ebumnuche | onye nwe ihe |
| SDS1 | Shared insights | Mkpebi anyị gbasara otu esi akwado ozi na otu nke Wikimedia bụ nke a na-eme na ngụkọta dị elu na nghọta. | Anyị iwuo teknụzụ nke ọma, na-akwado ndị ọrụ afọ ofufo, na ịkwado maka atumatu na-echebe ma na-ewuli nnweta ihe ọmụma, anyị kwesịrị ịghọta gburugburu Wikimedia wee kwadoo ihe ịga nke ọma dị. Nke a pụtara na-esochi usoro ngụkọ a pụrụ ịdabere na ya, kwere nghọta, ma dị n'oge achọrọ. Ọ pụtakwara ime nyocha na nghọta na-enyere anyị aka ịghọta ihe kpatara na otu esi agbakọ ngụkọ anyị. | Kate Zimmerman |
| SDS2 | Ebe nwale | Ndị njikwa ngwaahịa nwere ike na ntụkwasị obi, ngwa ngwa na idi mfe nyochaa mmetụta nke njirimara ngwaahịa. | Iji mee ma mee ka mkpebi data gbagoro ngwa ngwa gbasara mmepe njirimara ngwaahịa, ndị njikwa ngwaahịa chọrọ ebe nnwale nke ha nwere ike ịkọwapụta atụmatụ, họrọ ọgwụgwọ nke ndị na-ege ntị nke ndị ọrụ, ma hụ ngụkọta nke mmetụta. Ịme ngwa ngwa site na mmalite ruo nyocha dị oke mkpa, n'ihi na ime ka usoro iheomume dị mkpụmkpụ maka mmụta ga-eme ka nyocha dịkwuo ngwa, na n'ikpeazụ,webata ihe ọhụrụ. Achọpụtala nha ọrụ ndị ejiri aka mee na usoro nke edebeere ufọdị ndị dị ka mgbochi nye ịdị ngwa. Ọnọdụ dị mma bụ na ndị njikwa ngwaahịa nwere ike nweta site na mbido nnwale ruo na nchọpụta site n'enweghi obere ojij aka ma ọ bụ enweghị inye aka sitere n'aka ndị injinia na ndị nyocha. | Tajh Taylor |
| Future Audiences (FA) ebumnobi edepụtara | ||||
|---|---|---|---|---|
| Ebumnobi | Mpaghara ebumnobi | Ebumnobi | Ọnọdụ ebumnuche | onye nwe ihe |
| FA1 | Nwalee echiche ule | Nye Wikimedia Foundation ndụmọdụ gbasara ezi ntunye enwere ike ịchụso - nke dabeere site na nghọta nke nnwale ndị na-achịkọba nghọta anyị nke metụtara otu esi ekesa na etu esi enweta mmụta n'ịntanetị - nke na-enyere Otu anyị aka ijere ndị na-ege ntị ọhụrụ ozi na ịntanetị na-agbanwe agbanwe. | N'ihi mgbanwe na-aga n'ihu na teknụzụ na omume onye ọrụ n'ịntanetị (dịka ọmụmaatụ, ịbawanye mmasị maka ịnweta ozi site na ngwa ọha, ew ọmụma obere vidiyo ntụrụndụ nkụzi, ịrị elu nke jenerativ AI), Otu Wikimedia na-enwe ihe ịma aka n'ihu nke ịdọta na ijidesi ike ndị na-agụ akwụkwọ na ndị ntinye aka. Mgbanwe ndị a na-ewetakwa ohere iji nyere ndị na-ege ntị aka site na ịmepụta na ịnye ozi n'ụzọ ọhụrụ. Otú ọ dị, anyị dị ka Otu enweghị nkọwa doro anya nke ọmụma data nke uru na ahịa nke atụmatụ dị iche iche anyị nwere ike ịchụso iji merie ihe ịma aka ma ọ bụ nweta ohere ọhụrụ. Dịka ọmụmaatụ, anyị kwesịrị...
Iji hụ na Wikimedia ghọrọ ọrụ ọtụtụ ọgbọ, anyị ga-anwale echiche iji ghọta nke ọma ma kwado atụmatụ ndị dị mma - maka Wikimedia Foundation na Wikimedia movement- ịme mgbalị na ndọta na nchedo ndị na-ege ntị n'ọdịnihu |
Maryana Pinchuk |
| Product and Engineering Support (PES) ebumnobi edepụtara | ||||
|---|---|---|---|---|
| Ebumnobi | Mpaghara ebumnobi | Ebumnobi | Ọnọdụ ebumnuche | onye nwe ihe |
| PES1 | Ịrụ ọrụ nke ọma | Mee ka Foundation dị ngwa ngwa, dị ọnụ ala, ma mmetụta karịa | Ndị ọrụ na-eme ọtụtụ ihe n'ọrụ ha kwa ụbọchị iji mee ka ọrụ anyị dị ngwa ngwa, dị ọnụ ala na mmetụta karịa. Ebumnobi a na-akọwapụta atụmatụ a kapịrị ọnụ nke ga-abụ a) nweta nnukwu uru tụmadi ịdị ngwa ngwa, ịdị ọnụ ala ma ọ bụ inwee mmetụta karịa; na b) na-agbakọ mbọ na mgbanwe nke omume na Foundation. N'ụzọ bụ isi, ndị KR gụnyere n'ebumnobi a bụ nkwalite kachasị Ndị ọrụ na-eme ọtụtụ ihe n'ọrụ ha na-eme kwa ụbọchị iji mee ka ọrụ anyị dị ngwa ngwa, dị ọnụ ala na mmetụta karịa. Ebumnobi a na-akọwapụta atụmatụ a kapịrị ọnụ nke ga-abụ a) nweta nnukwu uru maka ngwa ngwa, dị ọnụ ala ma ọ bụ nwee mmetụta karịa; na b) na-agbakọ mbọ na mgbanwe nke omume na nke nkịtị na Foundation. N'ụzọ bụ isi, ndị KR agụnyere n'ebumnobi a bụ nkwalite kachasị sie ike na kachasị mma anyị nwere ike ime n'afọ a iji rụọ ọrụ arụmọrụ nke na-emetụ ngwaahịa na teknụzụ anyị aka. | Amanda Bittaker |
Ndepụta Isi Mpụtaara
Ndepụta "' Isi mpụtaara " (KR) nke ebumnuche ọ bụla emechara dị ebe a. Ha nwere ndakọ nye ebumnobi ọ bụla,edepụtara n'elu.
A ga-emelite " Echiche " nke KR ọ bụla n'ibe ọrụ ma ọ wiki otu dị mkpa n'ime afọ niile ka a na- enweta ihe mmụta.
| Ahụmahụ Wiki (WE) Ndepụta Isi mpụtaara | |||
|---|---|---|---|
| Isi mpụtaara njirimara mkpirisi | Isi mpụtaara Ederede | Isi mpụtaara ọnọdụ odide | onye nwe ihe |
| WE1.1 | Mebaa ma ọ bụ melite otu usoro ọrụ na-enyere ndị nyere aka nwere mmasị aka ijikọta aka ọnụ mee ntunye. | Anyị chere na oghere oge nnọkọ ngalaba otu na mmekọrịta dị na wiki na-eme ka ndị mmadụ nwee obi ụtọ ma na-arụpụta ihe dịka ndị ntinye aka. Na mgbakwunye, oghere oge nnọkọ ngalaba otu na-enyere aka inabata na iduzi ndị bịara ọhụrụ, na-egosipụta omume kacha mma nke ime ntunye, ma na-enyere aka idozi ohere ihe ọmụma. Otú ọ dị, ihe onwunwe, ngwáọrụ, na oghere ndị na-akwado njikọ mmadụ na wiki bụ nke dị ala ma bụrụ nke na-anọchichaghị ịma aka na mkpa nke ọtụtụ ndị ndezi taa. Ka ọ dị ugbu a, ọrụ nke otu Mgbasa Ozi egosila na ọtụtụ ndị nhazi na-achọsi ike iji na ịnwale ngwaọrụ ọhụrụ na usoro ọrụ ahaziri ahazi nke na-enyere ha aka n'ọrụ obodo ha. N'ihi ihe ndị a, anyị chọrọ ilekwasị anya n'ịgba ume na ịkwalite mmetụta nke ịbụ onye nsonye n'etiti ndị ntinye aka na wiki. | Ilana Fried |
| WE1.2 | Nkwalite ịrụ ọrụ: #% YoY na-abawanye na pasentị nke ndị bịara ọhụrụ na-ebipụta ≥1 ezi ndezi n'aha isi aha na ngwaọrụ mkpanaka. |
Ahụmịhe idezi ibe zuru ezu ugbu a chọrọ nnukwu ọnọdụ odide, ndidi, na nnwale na njehie nye ọtụtụ ndị bịara ọhụrụ ka ha mee ndezi n'ụzọ ziri ezi. Iji kwado ọgbọ ọhụrụ nke ndị ọrụ afọ ofufo, anyị ga-amụba ọnụ ọgụgụ na nnweta nke obere ọrụ, nke ahaziri, yana ọrụ ndị ọzọ metụtara ndezi kpọmkwem (dịka Nlele ndezi na Arụmọrụ Ahaziri).
Cheta na: A ga-ehiwe ntọala naanị na njedebe nke Q4 FY dị ugbu a, emesịa pasentị metrik ebumnuche KR anyị ka a ga-eguzobe. |
Peter Pelberg |
| WE1.3 | mụbawanye afọ ojuju onye ọrụ na ngwaahịa ngbanwe anọ site na X%. | Ndị ndezi nweerela ikike na-eji ọtụtụ atụmatụ dị adị, ngwa mgbatị, ngwa ọrụ na script rụọ ọrụ nruzigharị na ọrụ Wikimedia. N'afọ a, anyị chọrọ ilekwasị anya na imeziwanye ngwá ọrụ a, kama ịrụ ọrụ iji wuo ọrụ ọhụrụ na oghere a. Anyị na-achọ imetụ ọtụtụ ngwaahịa aka n'ime afọ, ma chọọ ime mgbanwe dị mma na nke ọ bụla. N'ime nke a, anyị nwere olile anya imelite ahụmịhe nke ịhazi ọdịnaya n'ozuzu ya. Anyị ga-akọwapụta X% n'ịtụle ntọala maka ụfọdụ ngwaọrụ ndị na-eme nhazi nke anyị nwere ike tinye anya na usoro ọrụ a. Ndepụta nke ọchụchọ ogbe ga-abụ nnukwu ihe ga-enye aka ime mkpebi ihe ndị kacha mkpa maka KR a. 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 | Ka ọ na-erule njedebe nke Q2, ndị nhazi nkwado, ndị ntinye aka, na ụlọ ọrụ nwere ngwá ọrụ ahọputara, nwere ntunye uche, na nhazi usoro na-eme ka enwe mmụbawanye nke ọdịnaya dị mma na mpaghara isi isiokwu [TBD] site na X%. | KR a bụ maka imeziwanye mkpuchi isiokwu iji belata oghere ihe ọmụma dị ugbu a. Anyị eguzobela ohere ka ngalaba otu na-erite uru site na ngwa ọrụ dị irè jikọtara ya na mkpọsa ezubere maka ịbawanye ogo ọdịnaya na ọrụ anyị. N'afọ a anyị chọrọ ilekwasị anya n'ịkwalite ngwá ọrụ ndị dị ugbu a na ịnwale ụzọ ọhụrụ nke ibute ụzọ isi isiokwu na-eleba anya na ọdịiche ọmụma. A ga-ekpebi mmụba X% anyị lekwasịrị anya na mkpuchi site na ilele ntọala dị adị nke imepụta ọdịnaya dị mma. Ọzọkwa, a ga-ekpebi mpaghara isiokwu anyị ga-elekwasị anya na ngalaba otu na ụlọ ọrụ site na nkeji ọzọ. Our target 138 articles will be determined by looking at existing baselines of quality content creation. |
Purity Waigi & Fiona Romeo |
| WE2.2 | Ka ọ na-erule na ngwụcha Q2, mejuputa ma nwalee ndụmọdụ abụọ, ma nke ọha na nke teknụzụ, iji kwado asụsụ n'ime obodo maka obere asụsụ, yana nnyocha iji nyochaa nzaghachi ngalaba otu. | Enwere mbipụta Wikipedia n'ihe dị ka asụsụ Narị atọ. N'agbanyeghị nke ahụ, e nwere ọtụtụ asụsụ ndị nde mmadụ na-asụ, nke na-enweghị Wikipedia na Wiki ma ọlị. Nke a bụ ihe mgbochi iji mezuo ebumnobi anyị: bụ na mmadụ ọ bụla nwere ike ịkesa n'efu nke nchikota ihe ọmụma niile. Wikimedia Incubator, bụ ebe enwere ike ịhazi, dee, nwale ma gosipụta na o kwesịrị idị ma Wikimedia Foundation kwadoro ya. EwepụtaraThe Incubator na 2006 site na nchịkọba uche na ndị ndezi ya ga-enwe ihe ọmụma na-ndezi wiki tupu ha amalite. Nsogbu a na-akawanye njọ site n'eziokwu na usoro a kwesịrị ka ọ bụrụ ndị kachasị ọhụrụ na ndị kasị nwee ahụmahụ na Otu anyị. Ime ndezi na Wiki Wikimedia emeela nke ọma kemgbe ahụ, Incubator enwetabeghị mmelite ndị a n'ihi adịghị ike nke teknikalụ. Ugbu a, ọ na-ewe ọtụtụ izu ka wiki gafee na Incubator ma naanị ihe dị ka wiki iri na abụọ ka a na-emepụta kwa afọ, nke na-egosi nnukwu nsogbu.
Nnyocha na ihe ndị dị adị na-ekpughe ihe ịma aka nka na mpaghara ọ bụla nke nnwebata asụsụ : ịgbakwunye asụsụ ọhụrụ na Incubator, mgbagwoju anya na mmepe na nyochaa ọdịnaya, yana usoro dị nwayọ n'imepụta saịtị wiki mgbe asụsụ gafechara ịpụta na Incubator. Usoro nke ọ bụla dị nwayọọ, bụrụ nke eji aka eme, dị kwa mgbagwoju anya, na-egosi mkpa ọ dị imelite. Ileba anya na nsogbu a ga-enye ohere ịmepụta wiki n'asụsụ ọhụrụ ngwa ngwa, ma mee ka ọtụtụ mmadụ nwee ike ịkesa ihe ọmụma. ndị mmetụta, nnyocha na akụrụngwa dị iche iche dị adị egosila ihe ndị a tụrụ aro ma mmekọrịta mmadụ na nka. Isi mpụtaara na-atụ aro ịnwale ndụmọdụ abụọ ma mmekọrịta mmadụ na ibe ya na teknụzụ yana nnyocha nzaghachi ngalaba otu. |
Satdeep Gill & Mary Munyoki |
| WE2.3 | Ka ọ na-erule njedebe nke Q2, atụmatụ ọhụrụ abụọ ga-eduzi ndị na-enye aka ịgbakwunye ihe ndị na-emepụta ihe na-agbaso ụkpụrụ nduzi ọrụ, na ndị mmekọ ato ruo ise enyela aka na isi mmalite asụsụ nke na-ekwu maka oghere dị n'asụsụ na mpaghara. | ikwalite nnweta akụrụngwa isi mmalite dị mma nke achọrọ iji mechie oghere ọdịnaya dabara adaba, anyị ga-:
|
Fiona Romeo & Alexandra Ugolnikova |
| WE2.4 | Ka ọ na-erule ngwụsị nke Q2, mee nnabata Wikifunctions opekata mpe otu obere asụsụ Wikipedia iji nye ụzọ nwere ike inye aka tinye ọdịnaya ọhụrụ. | Iji belata oghere ihe ọmụma anyị nke ọma, anyị kwesịrị imeziwanye usoro ọrụ na-akwado uto na-abawanye na ọdịnaya dị mma, ọkachasị n'ime ngalaba obere asụsụ. | Amy Tsay |
| WE3.1 | Wepụta ihe nchọgharị abụọ echekwabara, dị mfe nnweta na nke ngalaba otu na-akwalite na ahụmịhe mmụta onye nnọchi anya wiki, na ebumnobi nke ịbawanye njigide ndị ọgụụ na-abanyeh nke ndị ọrụ nwere ahụmịhe site na percentị ise. | KR a na-elekwasị anya n'ịbawanye njigide nke ọgbọ ọhụrụ nke ndị na-agụ akwụkwọ na ebe nrụọrụ weebụ anyị, na-enye ohere ka ọgbọ ọhụrụ wuo njikọ na-adịgide adịgide na Wikipedia, site n'inwe ọtụtụ ohere maka ndị na-agụ akwụkwọ iji chọpụta ngwa ngwa ma mụta ihe site na ọdịnaya ha nwere mmasị na ya. Nke a ga agunye nnyocha na mmepe nke nchọgharị na mmụta ọhụrụ echekwabara, nye nhazi nke onwe ma nye ohere mmasị ngalaba otu (dịka ọmụmaatụ, ndepụta nke ọdịnaya dị mkpa, ntụnye ọdịnaya isiokwu na aro, ohere nyocha ọdịnaya nke ngalaba otu chịkọtara, wdg).
Anyị na-eme atụmatụ ịmalite afọ mmefu ego site na ịnwale usoro nnwale nke ahụmịhe nchọgharị iji chọpụta nke anyị ga-achọ itule maka ojiji mmepụta, yana nke ebe ndị dị ka (web, ngwa, ma ọ bụ ha abụọ). Anyị ga-elekwasị anya n'ịkwalite nnwale ndị a ma nwalee ịdị irè ha n'ịbawanye njigide na gburugburu mmepụta. Ebumnuche anyị na njedebe nke afọ bụ ịmalite ma ọ dịkarịa ala ahụmahụ abụọ na wiki nnọchite anya yana tụọ n'ụzọ ziri ezi mmụba 5% nke njigide ndị na-ọgụụ maka ndị na-agụ akwụkwọ na-etinye aka na ahụmahụ ndị a. Iji bụrụ nke kachasị dị irè n'inweta KR a, anyị ga-achọ ikike iji mee nwalee A/B nke ndị ọrụ n'abanyebeghi, yana ngwa nwere ike gụọ njidegide ọgụụ. Anyị nwekwara ike ịchọ API ọhụrụ ma ọ bụ ọrụ dị mkpa iji weta ntụnye na usoro ndowe ndị ọzọ. |
Olga Vasileva |
| WE3.2 | mbawanye 50% na ọnụ ọgụgụ nke onyinye site na mmetụ aka na-abụghị ọkọlọtọ kwa afọ na arịrịọ email kwa ikpo okwu. | Ebumnuche anyị bụ inye ohere nnweta ego dị iche iche ka anyị na-amata ndị nyere anyị onyinye. Dabere na nzaghachi na data, anyị na-elekwasị anya n'ịbawanye ọnụ ọgụgụ nke onyinye karịrị usoro Foundation dabeere na n'oge gara aga, karịsịa ibe arịrịo onyinye kwa afọ. Anyị chọrọ igosi na site n'itinye ego na ahụmahụ ndị na-enye onyinye jikọtara ọnụ, anyị nwere ike ịkwado ọrụ anyị ma gbasaa mmetụta anyị site n'inye ohere ọzọ nye ndị na-enye onyinye na ndị nwere ike inye onyinye na-adịghị anabata arịrịọ edebụtara na ọkọlọtọ. 50% bụ atụmatụ izizi dabere na mbelata ọhụhụ nke ebe mpịaka inye onyinye na Weebụ n'ihi Vector 2022, yana mmụba nke ọnụ ọgụgụ onyinye sitere na FY 2023-2024 pilot project na ngwa Wikipedia iji kwalite ahụmịhe ndị nyere onyinye (50.1% mmụba nke onyinye). Ịtụle metric a site n'ikpo okwu ga-enyere anyị aka ịghọta usoro na nhiwe ma ọ bụrụ na a ga-etinye usoro dị iche iche n'ọdịnihu dabere na ọdịiche dị na omume nke ndị na-ege ntị. | Jazmin Tanner |
| WE3.3 | By the end of Q2 2024-25, volunteers will start converting legacy graphs to the new graph extension on production Wikipedia articles. | The Graph extension has been disabled for security reasons since April 2023, leaving readers unable to view many graphs that community members have invested time and energy into over the last 10 years. Data visualization plays a role in creating engaging encyclopedic content, so in FY 2024-25, we will build a new secure service to replace the Graph extension that will handle the majority of simple data visualization use cases on Wikipedia article pages. This new service will be built in an extensible way to support more sophisticated use cases if WMF or community developers choose to do so in the future. We will know we’ve achieved success when community members are successfully converting legacy graphs and publishing new graphs using the new service. We will determine which underlying data visualization library to use and which graph types to support during the initial phase of the project. |
Christopher Ciufo |
| WE3.4 | Develop the capability model to improve website performance through smaller scale cache site deployments that take one month to implement while maintaining technical capabilities, security and privacy. |
The Traffic team is responsible for maintaining the Content Delivery Network (CDN). This layer caches frequently accessed content, pages, etc, in memory and on disk. This reduces the time it takes to process requests for users. The second bit is storing content closer to the user in a physical sense. That reduces the time it takes for data to reach the user (latency). Last year, we enabled one site in Brazil meant to reduce latency in the Southern American region. Setting up new data centers would be great but it is expensive, time consuming, and requires a lot of work to get done – for example, last year’s work spanned the full year. We would love to have centers in Africa and Southeast Asia, and we would love to have them all around the world. Our hypothesis is to spin up smaller sites in other places around the world where traffic is lower. These would require fewer servers, of not more than four or five servers. This reduces our cost. It would still help us reduce latency for users in these regions, while being more lightweight in terms of time and effort to maintain them. |
Kwaku Ofori |
| WE4.1 | Nye ntụzịaka nke usoro mgbochi atọ maka iyi egwu na ọdịnaya na-adịghị mma nke data kọwara yana ndaba nke gburugburu usoro nhazi na-agbanwe site na Q3. | Ịhụ na nchekwa na ọdịmma onye ọrụ bụ ọrụ dị mkpa nke nhiwe ịntanetị. Ọtụtụ ikike nwere iwu na ụkpụrụ na-enye n'ịntanetị ohere iji mee ihe megide iyi egwu, mmegide nke intanent na ọdịnaya ndị ọzọ na-adịghị mma. Ịghara ilebara ihe ndị a anya nwere ike ịkpata ikpo okwu iji ụgwọ iwu na inwe mmachi iwu.
Ugbu a, anyị enweghị ezi mmụta banyere etu nsogbu ndị a si buo ibu ma ọ bụ ihe kpatara ya. Anyị na-adabere kpamkpam na ihe akaebe akụkọ ihe mere eme na usoro ntuziaka nke nwere ike iduga anyị n'ihe ize ndụ iwu yana nsonaazụ ndị ọzọ dị oke egwu: nleli nsogbu ahụ anya, mmụba nke ihe ize ndụ, mmebi aha na mmebi nke ntụkwasị obi onye ọrụ. Anyị kwesịrị iwulite omenaala siri ike nke ịtụle ihe mkpagbu na ọdịnaya ndị na-adịghị mma ma jiri nlezianya mejuputa usoro mgbochi. |
Madalina Ana |
| WE4.2 | Kwalite opekata mpe akara abụọ maka ijiji na-ịrụ ọrụ mgbochi mmegbu iji kwalite izi ezi nke omume na ndị na-eme ihe ọjọọ site na Q3. | Wiki na-adabere kpamkpam na igbochi IP dị ka usoro maka igbochi mmebi, spam na mmegbu. Mana adreesị IP anaghị abawanye uru dị ka ihe nchọpụta kwụsiri ike nke onye ojiji, nakwa igbochi adreesị IP nwere mmetụta ọjọọ na-atụghị anya ya n'ebe ndị ọrụ ezi ebumnobi na-ekọrịta otu adreesị IP ha na ndị na-eme ihe ọjọọ. Nchikota nke nkwụsi ike nke adreesị IP na-ebelata na ntụkwasị obi siri ike anyị na igbochi IP na-eme ka ọ dị ntakịrị na ịdị irè n'ịchụso ndị na-eme ihe ọjọọ, yana ọnụ ọgụgụ na-arịwanye elu nke mmebi nkwekọrịta nke ndị ọrụ ezi ebumnobi. Anyị chọrọ ịhụ ọnọdụ dị iche: mbelata ọkwa nke mmebi nkwekọrịta yana mmụba nkenke na mbelata nke ezubere iche maka ndị na-eme ihe ọjọọ.
Iji kwado ọrụ mgbochi mmegbu nke ndị na-arụ ọrụ yana inye ebe mgbakwasa ụkwụ maka njikwa na ngwaọrụ ọhụrụ dị ugbu a (dịka CheckUser, Special: Block) , na KR a, anyị na-atụ aro ka anyị nyochaa ụzọ isi jikọta mmadụ na omume ha (mbelata sockpuppetting. ), ma jikọta akara ndị dị ugbu a (dịka adreesị IP, akụkọ ndekọ aha, njirimara arịrịọ) iji nye ohere maka ebumnuche ziri ezi nke omume na ndị na-eme ihe ọjọọ. |
Kosta Harlan |
| WE4.3 | Belata ịdị irè nke nnukwu mwakpo ekesara site na pacentị iri ise dị ka atụpụtara site na oge ọ na-ewe anyị iji gbanwee usoro anyị na ogo trafik anyị nwere ike ịkwado na ntabi anya. | Mgbanwe nke ebe ịntanetị, gụnyere ịrị elu nke botnets buru ibu na mwakpo ugboro ugboro emeela ka usoro ọdịnala anyị nke ịmachi oke mmekpa ahụ gharazie isi ike. Mwakpo dị otú ahụ nwere ike ime ka saịtị anyị ghara ịdị site na mmụba arịrịọ nye akụrụngwa anyị, ma ọ bụ mebie ikike nke ngalaba otu anyị ịlụso nnukwu mmebi ọgụ. Nke a na-etinyekwa nsogbu na-enweghị ezi uche nye ndị ndezi anyị nwere nnukwu ihe ùgwù yana ndị ngalaba nka anyị.
Anyị kwesịrị imelite ikike anyị ịchọpụta ozugbo, iguzogide, na ibelata ma ọ bụ kwụsị ụdị mwakpo ahụ. Iji tụlie mmelite anyị, anyị enweghị ike ịdabere naanị na ugboro ole/mkpagbu nke mwakpo n'ezie, n'ihi na anyị ga-adabere na omume mpụga ma ọ ga-esi ike ịnweta nkọwa ọganihu anyị n'ụzọ doro anya. Site n'ihiwe ọtụtụ myiri ihe mkpagbu nke ọdịdị, mgbagwoju anya na ogologo dị iche iche ka a nwalee ya megide akụrụngwa anyị, ma na-anwalee ha kwa nkeji iri na ise, anyị ga-enwe ike ịnwale usoro mgbochi ọhụrụ anyị ma ọ bụrụ na a naghị ebuso anyị agha, na ịnye mpụtaara nke ọma gnasara nkwalite anyị. |
Giuseppe Lavagetto |
| WE4.4 | Launch temp accounts to 100% of all wikis. | Temporary accounts are a solution for complying with various regulatory requirements around the exposure of IPs on our platform on various surfaces. This work involves updating many products, data pipelines, functionary tools, and various volunteer workflows to cope with the existence of an additional type of account. | Madalina Ana |
| WE5.1 | Site na Q3, mezue ma ọ dịkarịa ala ntinye aka ise nke ezubere iji mee ka nkwado nke ikpo okwu dịkwuo elu. | Nkwado n'elu ikpo okwu MediaWiki bụ mbọ ga na-aga n'ihu dị mkpa maka ike ime ntule, ịbawanye ma ọ bụ zere nleda anya nke afọ ojuju onye nrụpụta, wee kwalite ngalaba nka. Nke a siri ike ịgụkọba ma dabere na teknụzụ na mmekọrịta mmadụ na ibe ya. N'Agbanyeghị, anyị n'eji ihe ọmụma ekwupụtaghị gbasara mpaghara ndozi akọwapụtara nke ọma maka nkwado. Ihe omume a na-eme atụmatụ nwere ike inye aka nye nkwado na mmeziwanye nke ikpo okwu ma ọ bụ zere mmebi ya. Anyị na-eme atụmatụ ịtụle mmetụta nke ọrụ a na Q4 na ndụmọdụ maka ebumnuche nkwado na-aga n'ihu. Ọmụmatụ nke nlebanya nkwado bụ: mee ka ngalaba koodu dị mgbagwoju anya dị mfe na MediaWiki mana naanị mmadụ ole na ole maara ka o si arụ ọrụ; mụbaa ojiji nke koodu nnyocha ngwá ọrụ iji mee ka ọdịdị nke codebase anyị dị mma; hazie usoro dị ka nkwakọ ngwaahịa na mwepụta. | Mateus Santos |
| WE5.2 | Chọpụta site na Q2 wee mezue site na Q4 otu ma ọ bụ karịa ntinye aka iji wepụta ihu mmemme nke gburugburu ebe ọdịdị nke MediaWiki iji mee ka enwe mmepe ojiji mara mma, nke dị mfe na nke ga-adigide. | Ebumnuche ya bụ isi nke KR 5.2 bụ imeziwanye na idokwu anya mmekọrịta dị n'etiti ikpo okwu MediaWiki na mgbatiwanye ya, skịnị ya na akụkụ ndị ọzọ. Ebumnobi anyị bụ ịnye nkwalite n'arụ ọrụ na ihe owuwu MediaWiki nke na-eme ka njịkọ na mmeziwanye dị irè, nke ọ dị mfe iji wulite mgbatiwanye, na inye ikike ndị a chọrọ site n'ebumnobi ngwaahịa MediaWiki sara asa. Ọrụ a na-akọwakwa ihe kwesịrị ịdị (ma ọ bụ na ọ bụghị) n'ime isi, mgbatị, ma ọ bụ ihu dị n'etiti ha. A ga-ekewa afọ ahụ ụzọ abụọ: nnyocha nke ọnwa ise na usoro nnwale nke ga-egosipụta nke abụọ ebe a ga-etinye aka na ya. | Jonathan Tweed |
| WE5.3 | Ka ọ na-erule njedebe nke Q2, mezue otu atụmatụ nchịkọta data yana otu nnwale nkwalite arụmọrụ iji mee ka ngwaahịa nsonye na ntinye aka n'elu ikpo okwu nwee ike kwalite ikike nke MediaWiki ịmepe ibe nke ibe dị ka ngwakọta nke iberibe ahaziri ahazi. | Ebumnuche bụ isi ebe a bụ inye ndị mmepe na ndị njikwa ngwaahịa ikike iji ikike ikpo okwu MediaWiki dị ọhụrụ iji gboo mkpa nke ọdịnaya encyclopedic dị ugbu a na n'ọdịnihu site n'ịmepụta onyinye ngwaahịa ọhụrụ nke siri ike imejuputa ugbu a yana melite arụmọrụ na nkwụdosike nke ikpo okwu.
Kpọmkwem, n'ọkwa ikpo okwu MediaWiki, anyị chọrọ ịgbanwe ụdị nhazi nke MediaWiki site n'imeso ibe dị ka otu akụkụ monolithic gaa na-imeso ibe dị ka ngwakọta nke nkeji ọdịnaya ahaziri ahazi. ọgụgụ olile nke ntụgharị akara dabeere, njikọ Wikidata, na ntinye n'ọrụ nke Wikifunction na wiki bụ omume doro anya maka nke ahụ. Dị ka akụkụ nke KR a, anyị chọrọ ịkpachara anya na-anwale ma kpokọta data iji gwaa ntinye aka n'ọdịnihu dabere na ikike ọhụrụ ndị a iji hụ na anyị nwere ike nweta akụrụngwa echere na mmetụta ngwaahịa. |
Subramanya Sastry |
| WE5.4 | By the end of Q2, execute the 1.43 LTS release with a new MW release process that synchronizes with PHP upgrades. | The MediaWiki software platform relies on regular updates to the next PHP version to remain secure and sustainable, which is a pain point in our process and important for the modernization of our infrastructure. At the same time, we regularly release new versions of the MediaWiki software, which e.g. translatewiki.net depends on, the platform used to translate software messages for the Wikimedia projects and many other open source projects. There’s an opportunity to improve the MediaWiki release process, including technical documentation and synchronization with PHP upgrades in alignment with the MediaWiki product strategy before the next release, which will be a long term support version (LTS). This work is part of our strategic investment in the sustainability of the MediaWiki platform (see also: 5.1) and aims to improve developer experience and infrastructure management. |
Mateus Santos |
| WE6.1 | Kpebie ajụjụ ise iji mee ka arụmọrụ dị mma na mkpebi amara ọkwa ya na ebe onye nrụpụta na ọrụ injinia na ọrụ ma mee ka nnweta data dị mkpa dị mfe na njedebe nke Q4. | "Ọ gbagwojuru anya" bụ nzaghachi ugboro ugboro nye ajụjụ ndị dị ka "kedu ihe nnọchanya a na-ebuga ebe nchekwa na mmepụta Wikimedia". Na nke a KR anyị ga-enyocha ụfọdụ n'ime "ihe ndị anaghị awụ awụ" na ngalaba nke engineering arụpụtaghị ihe na ahụmahụ - ajụjụ ugboro ugboro dị ka ha di mfe ịza ma ha siri ike ịza, ajụjụ ndị anyị nwere ike ịza, ma data adịghị mfe nnweta ma na-achọ query emmerala site n'aka ndị ọkachamara n'isiokwu, ma ọ bụ ajụjụ ndị siri ike iji nweta nzaghachi maka oghere usoro ma ọ bụ ihe ndị ọzọ. Anyị ga-akọwapụta ihe “dozie” pụtara maka ajụjụ ọ bụla: Maka ụfọdụ nke a nwere ike ịpụta ime ka data ziri ezi dị mfe nnweta. Ajụjụ ndị ọzọ ga-achọkwu nyocha na oge injinịa iji lebara ha anya.Ebumnobi dị ukwuu nke ọrụ a bụ iji belata oge, ihe mgbagwoju anya na mgbalị ọ na-ewe iji nweta nghọta na akụkụ ndị dị mkpa nke ahụmahụ onye mmepụta ma mee ka anyị nwee ike imeziwanye ọrụ injinia na mmepụta na ọganihu ọrụ. | [TBD] |
| WE6.2 | Site na Q4, kwalite oru ngo dị ugbu a ma mee opekata mpe nnwale abụọ iji nye ebe a na-edobe anya, nke ezubere iche na-akpọga anyị gaa n'ihu metụtar nchekwa, ọkara na-aga n'ihu. | Ndị mmepe na ndị ọrụ dabeere na Wikimedia Beta Cluster (beta) iji nweta bọg tupu ha emetụta ndị ọrụ na mmepụta. Ka oge na-aga, ojiji nke beta etoola wee banye n'esemokwu-ojiji ndị a dị iche iche na-adaba n'otu ebe. Anyị ga akwalite otu ebe ọzọ dị adị ma mee nnwale ndị ezubere iji dochie otu nnwale dị oke mkpa dị elu nke emezuru ugbu a site na nkwalite gburugburu beta enwere ike idobe nke na-egbo mkpa ọ bụla dị. | Tyler Cipriani |
| WE6.3 | Develop a Toolforge sustainability scoring framework by Q3. Apply it to improve at least one critical platform aspect by Q4 and inform longer-term strategy. | Toolforge, bụ isi ebe ewuru ngwa ọrụ afọ ofufo Wikimedia, ọ na-arụ ọrụ dị oke mkpa site na ndezi ruo namgbochi mmebi ihe. Ebumnobi anyị bụ ịkwalite ojiji Toolforge, belata ihe mgbochi inye ntinye aka, melite ihe omume ngalaba otu, na ịkwalite nrube isi nye atumatu guzosiri ike. Iji mee nke a, anyị ga-ewebata usoro akara site na Q2 iji nyochaa ndigide nke Toolforge, na-elekwasị anya na teknụzụ na mmekọrịta ọha na eze. Iji usoro a dị ka ntuziaka, anyị bu n'obi imeziwanye otu n'ime isi ihe teknụzụ site na pacaenti iri ise. | Slavina Stefanova |
| Signals & Data Services (SDS) Isi mpụtaara edepụtara | |||
|---|---|---|---|
| Isi mpụtaara njirimara mkpirisi | Isi mpụtaara Ederede | Isi mpụtaara ọnọdụ odide | onye nwe ihe |
| SDS1.1 | Ndị isi mmemme abụọ ma ọ bụ atụmatụ KR kpaliri ewepụtala akwụkwọ ekesaala nke ukwuu na-akọwa njikọ ezi uche dị n'etiti ọrụ otu ha na mmetụta na otu ma ọ bụ karịa isi metrik Foundation. | Metirik Ogbakọ anyị bụ isi ihe nlekwasị anya maka ịtụle ọganihu Foundation metụtara ebumnuche ya. Ka anyị na-ekenye akụrụngwa nye mmemme na nkepụta isi mpụtaara (KR) nke arụm arụ , metrik ndị a kwesịrị iduzi otu anyị si ejikọta itinye ego ndị a na ebumnuche zuru oke nke Foundation dịka akọwara na atụmatụ kwa afọ. Ọrụ dị na isi mpụtaara nabatara na Foundation n'ozuzu ya nọ n'oge mmalite n'ikike ya iji jikọta mmetụta nke mmemme niile akwadoro na ogo dị elu, ma ọ bụ isi metrik. N'ịchụso ebumnuche ahụ dapụtara, KR a bu lekwasara anya iwulite usoro nke anyị si ekesa njikọ ezi uche na echiche dị n'etiti atụmatụ anyị na metrik anyị dị elu. Na ngosipụta, nke a pụtara iso ndị nwe atụmatụ na-akpakọrịta Foundation iji ghọta ka esi ejikọta mmepụta nke ọrụ ha na ọkwa ọrụ yana na-emetụta isi metrik anyị na ogo Foundation. A ga-eji usoro eserese mmetụta na ihe omume dị ka 'Theory of Change mapping' nakwa a ga ewebata causal graph construction iji hụ na ọ bụ ihe n'aga n'ihu na nke eji mkpachapụ anya na-ndekọ mmetụta nke ọrụ. Iji mezuo mpụtaara ndị a dị mkpa, ọ ga-adị anyị mkpa ịmepụta ihe nkwado nke na-enyere ndị nwe echiche a aka ịghọta Metrik ọgbakọ ma ghọta otu esi achịkọba theories of change metụtara ọrụ ha. |
Omari Sefu |
| SDS1.2 | Zaa ajụjụ ezi atụmatụ nnyocha abụọ site na Disemba 2024 iji nye ndụmọdụ ma ọ bụ gwa FY26 atụmatụ kwa afọ. | Enwere ọtụtụ ajụjụ nyocha emepere emepe na gburugburu Wikimedia, ma ịza ụfọdụ ajụjụ ndị ahụ bụ ezi atụmatụ nye WMF ma ọ bụ ndị mmekọ. Azịza nye ajụjụ ndị a nwere ike ịkọwapụta ngwaahịa ma ọ bụ teknụzụ n'ọdịnihu ma ọ bụ nwee ike ịkwado ime mkpebi / ịkwado na oghere amụma. Ọ bụ ezie na enwere ike ịza ụfọdụ n'ime ajụjụ ndị a site na iji naanị nnyocha ma ọ bụ ọkachamara injinia nyochaa, n'ihi ọdịdị mmekọrịta ọha na eze nke ọrụ WM na-abịarute nghọta kwesịrị ntụkwasị obi na-achọkarị imekọ ihe ọnụ maka nchịkọta data, iwu ederede, mmekọrịta onye ọrụ, nlezianya nchepụta nke nnwale, na ihe ndị ọzọ. Site na KR a, anyị bu n'obi ibute ụzọ ụfọdụ ihe onwunwe anyị maka ịza otu ajụjụ ma ọ bụ karịa.
Ọrụ dị na KR a gụnyere ịnye aha ndepụta nke ajụjụ ezi atụmatụ, yana ịrụ ọrụ nnwale iji chọta azịza maka nọmba X (nke a na-eme atụmatụ abụọ ugbu a) n'ime ha. Ụdị ajụjụ kachasị mma anyị na-atụle na KR a bụ ajụjụ ndị ọzịza ya nwere ike inwe mmetụta mmeghe site n'inyere ọtụtụ otu ma ọ bụ otu ndị ọzọ aka(ịdị mma?ịmaara) ngwaahịa, teknụzụ, ma ọ bụ ọrụ amụma. Anyị bu n'obi na-ịrụ ọrụ na KR a ka ọ bụrụ nkwado na KR ndị a:
|
Leila Zia |
| SDS1.3 | Mezuo opekata mpe pacentị iri ise na nkezi oge achọrọ maka ndị na-ahụ maka data ka ha ghọta ma chọpụta usoro data na-aga maka isi atọ na metrik dị mkpa. | Nke Achọrọ maka ụkpụrụ nchịkwa data.
Ịchọghachi mgbanwe na isi iyi nke datasets siri ike ma na-achọ ihe ọmụma nke nchekwa na sistemụ dị iche iche. Anyị kwesịrị ime ka ọ dị mfe ịghọta ka data si aga gburugburu sistemụ anyị ka ndị na-ahụ maka data wee nwee ike ịrụ ọrụ n'ụzọ ọrụ onwe. Ọrụ a ga-akwado usoro ọrụ ebe a na-agbanwe data ma jiri ya mee ihe maka nyocha, njirimara, API na ọrụ njirimara data. A ga-enwe nleba anya KR gburugburu ndetu metrik. |
Luke Bowmaker |
| SDS2.1 | Site na njedebe nke Q2, anyị nwere ike ịkwado ndị otu ngwaahịa 1 iji nyochaa njirimara ma ọ bụ ngwaahịa site na nyocha A/B nke na-ebelata oge ha na data mmekọrịta onye ọrụ site na pasentị iri ise. | Anyị na-eche na iji ngwaọrụ na-ekekọrịta ihe ga-abawanye ntụkwasị obi nke otu ngwaahịa n'ime mkpebi data na-ebute, melite arụmọrụ na nrụpụta, yana ịkwalite atụmatụ ngwaahịa na nchepụta ihe ọhụrụ. Anyị ga-eleba anya n'inweta oge nke onye otu maka usoro data mmekọrịta nke onye ọrụ wee kwalite ya site na pasentị iri ise. Anyị ga-enyochakwa otu anyị nwere ike isi kọwaa uru ndị a n'ụzọ zuru ezu nke otu ngwaahịa niile. Anyị na-atụ anya ịmụta ka anyị nwere ike isi melite ahụmịhe ahụ wee chọpụta na ebute nkwalite ikike ụzọ dabere na nzaghachi sitere na ndị otu nakweere na mpụtaara SDS2.2. |
Virginia Poundstone |
| SDS2.2 | N'ọgwụgwụ nke Q2, anyị ga-enwe metrik abụọ dị mkpa maka nyocha nnwale (Nnwale A/B) iji kwado nleba anya ngwaahịa / njirimara metụtara FY24-25 KRs. | Mgbe onye njikwa ngwaahịa (ma ọ bụ onye nkepụta) nwere echiche na ngwaahịa / njirimara ga-edozi nsogbu ma ọ bụ mkpa nye ndị ọrụ ma ọ bụ nzukọ, nnwale bụ ka ha si anwale echiche ahụ ma mụta banyere mmetụta nwere ike ịmetụta orụ ha na metrik. Mpụtaara nke nnwale ahụ na-agwa onye njikwa ngwaahịa ma nyere ha aka ime mkpebi gbasara ihe ha ga-eme ọzọ (hapụ echiche a ma nwalee echiche dị iche, nọgide nna ọrụ mmepe ma ọ bụrụ na emere nnwale ahụ n'isi mmalite nke mmepe, ma ọ bụ nyefee ngwaahịa/fịchọ nye ndị ọrụ ọzọ). Ndị njikwa ngwaahịa ga-enwerịrị ike iji ntụkwasị obi mee mkpebi dị otú ahụ, site na-akwado akaebe ha tụkwasịrị obi ma ghọta.
Isi ihe na-egbochi nke a bụ na ndị otu ngwaahịa na-emepụta echiche ha ugbu a na metrik akọwapụtara nke ọma nke chọrọ nkwado nkọwa iji kọwaa, tụọ, nyochaa na inye nzahachị banyere ha. Ịtụgharị gaa na usoro metrik dị mkpa maka ịmepụta nwale ngwaahịa/fịchọ niile ga-eme ka ọ bụrụ:
Anyị na-eche na otu metrik dị mkpa nke a na-aghọta nke ọma ma na-eji ya eme ihe mgbe niile - yana kọwapụtara / na-emetụta ya site na metric ụlọ ọrụ - ga-akwalitekwa ọmụma data ma kwalite ụzọ nnyocha, nyocha na mmụta. Anyị na-elekwasị anya na metrik dị mkpa nke (1) nke dị mkpa maka ntule kacha mma na mmata nke ịga nke ọma / mmetụta nke ngwaahịa /atụmatụ ndị metụtara nke abụọ nke Wiki Experiences KRs - WE3.1 na WE1.2 - na (2) na-atụgharị ma ọ bụ map depụta nye metrik amaara maka ụlọ ọrụ- a na-eji na nyocha webụ. |
Mikhail Popov |
| SDS2.3 | Deploy a unique agent tracking mechanism to our CDN which enables the A/B testing of product features with anonymous readers. | Without such a tracking mechanism, it is not reasonable to implement A/B testing of product features with anonymous readers.
This is basically a milestone-based result to create a new technical capability that others can build measurable things on top of. The key priority use-case will be A/B testing of features with anonymous readers, but this work also enables other important future things, which may create follow-on hypotheses later in WE4.x (for request risk ratings and mitigating large-scale attacks) and for metrics/research about unique device counts as their resourcing and priorities allow. |
Brandon Black |
| Future Audiences (FA) Depụta isi mpụtaara | |||
|---|---|---|---|
| Isi mpụtaara njirimara mkpirisi | Isi mpụtaara Ederede | Isi mpụtaara ọnọdụ odide | onye nwe ihe |
| FA1.1 | N'ihi nlebanya na ntụnye ndị na-ege ntị n'ọdịnihu, ka ọ na-erule njedebe nke Q3 opekata mpe otu ebumnuche ma ọ bụ isi mpụtaara nke na-abụghị nke otu ndị na-ege ntị na Ọdịnihu nwere dị na ndepụta nke atụmatụ afọ nke afọ na-abịa. | Kemgbe 2020, Wikimedia Foundation abụrụla tracking external trend nke nwere ike imetụta ikike anyị ijere ọgbọ nke ndị ojiji iheeme ihe na ndị na-enye ihe ọmụma ozi n'ọdịnihu ma nọgide na-enwe mmegharị ihe ọmụma n'efu ruo ọgbọ na-abịa. Ndị na-ege ntị n'ọdịnihu, otu obere R&D, ga-:
|
Maryana Pinchuk |
| Product and Engineering Support (PES) Depụta isi mpụtara | |||
|---|---|---|---|
| Isi mpụtaara njirimara mkpirisi | Isi mpụtaara Ederede | Isi mpụtaara ọnọdụ odide | onye nwe ihe |
| PES1.1 | Omenala Nnyocha: Na-abawanye ọkwa mmetụta ndị ọrụ P+T metụtara nnyefe anyị, nhazi, ntụzịaka na ahụike otu n'ime nnyocha nke otu ụzọ nnyocha ugboro anọ. | Omenala nnyocha bụ omenala mmepe ngwaahịa dabere na obere ntugharị nke nkọwapụta, mmụta na ndabere. Nke a pụtara na nzukọ anyị nwere ike isetịpụ ihe nlekwasị anya kwa afọ, mana ihe anyị na-eme iji nweta ebumnuche ndị a ga-agbanwe ma gbanwee n'ime afọ ka anyị na-amụta. Enwere akụkụ abụọ iji wuo omenala nnyocha: usoro na omume. KR a lekwasịrị anya na nke ikpeazụ. Mgbanwe omume nwere ike itolite ma wusie omenala nyocha anyị ike. Nke a na-agụnye mgbanwe n'omume na ihe omume onye ọ bụla ka anyị na-aga n'ihu na mmepe ngwaahịa ọzọ. KR a ga-adabere na mgbanwe nke akọpụtara onwe ya na omume onye ọ bụla, yana tụọ mgbanwe ndị ga-esi na ya pụta, ma ọ bụrụ na ọ bụla, na mmetụta ndị ọrụ. | Amy Tsay |
| PES1.2 | Ka ọ na-erule njedebe nke Q2, Ọchịchọ ọhụrụ ahụ na-ejikọta echiche njem a na arịrịọ maka ọrụ P + T nke foundation: ihe sitere na ndekọ azụ nke Wishlist ka a na-ekwu site na 2024-5 KR, Foundation emechaala obere ọchịchọ iri, ma Foundation na ndị ọrụ afọ ofufo ejikọtala aka iji chọpụta mpaghara 3+ maka 2025-26 FY. | Ndepụta ọchịchọ ngalaba otu na-anọchi anya ibe dị warara nke njem a; ihe dị ka mmadụotu puku na-esonye, ọtụtụ n'ime ha bụ ndị ntinye aka ma ọ bụ ndị admin. Ndị mmadụ na-agafekarị ndepụta ọchịchọ site n'ịde arịrịọ atụmatụ na mkpesa bọg site na Phabricator, ebe ọ na-esi ike ịghọta arịrịọ sitere n'aka WMF ma ọ bụ ngalaba otu. Maka ndị nsonye, ndepụta ọchịchọ bụ itinye ego oge dị ọnụ ahịa nke obere ịkwụ ụgwọ. Ha ka na-etinye aka na Ndepụta Ọchịchọ n'ihi na ha chere na ọ bụ naanị ụzọ iji dọta uche gaa ebe Bọg nwere mmetụta yana ndozi ngwa, ma ọ bụ gosi ọdị inweta ezi ohere. A na-edekarị ọchịchọ dị ka ihe ogbugbo, vs nsogbu. atụmatụ ogbugbo ndị ahụ nwere ike ịdị ka ihe ezi uche na akwụkwọ, mana echela echiche mgbagwoju anya teknụzụ ma ọ bụ atụmatụ njem.
Ogologo na obosara nke ọchịchọ mgbe ụfọdụ na-akarị oke na ikike Community Tech ma ọ bụ otu otu, na-eme ka obi nkoropụ ahụ na-aga n'ihu, na-eduga na RFC na oku nke nhichapụ ihe ndị achọrọ. Ebe ndị ngalaba otu na-ahọrọ iji Ndepụta Ọchịchọ maka echiche oru ngo, ndị otu nọ na Foundation na-eleba anya na listi ọchịchọ na mbute ụzọ usoro nnabata ndị ọzọ , n'otu akụkụ n'ihi na ọchịchọ abịaghị oge atụmatụ Kwa Afọ na ọ siri ike itinye n'ime ndepụta / OKRs. Ndepụta Ọchịchọ Ọdịnihu kwesịrị ịbụ ihe mgbochi dị n'etiti ngalaba otu na Foundation, ebe ndị obodo na-enye ntinye aka n'ụzọ ahaziri ahazi, ka anyị wee nwee ike ime ihe na na nke ọzọ mee ndị ọrụ afọ ofufo obi ụtọ. Anyị na-eke usoro nzibata ọhụrụ maka onye ọrụ afọ ofufo bụla n'abanyela iji nyefee ọchịchọ, ụbọchị narị atọ na iri isii na ise kwa afọ. ihe ọchịchọ nwere ike ịkọ ma ọ bụ gosipụta bọg, rịọ maka mmelite, ma ọ bụ chepụta echiche maka ngwa ọhụrụ. Onye ọ bụla nwere ike ịza ajụjụ gbasara, ogbako, ma ọ bụ kwado ọchịchọ imetụta ibu ụzọ. Ntọala ahụ agaghị ekewa ọchịchọ dị ka "oke ibu" ma ọ bụ "obere." Ọchịchọ na-egosi na isiokwu na mpaghara nsogbu ka ukwuu nwere ike imetụta atụmatụ kwa afọ na ụzọ nduzi Otu, na-enye ntụziaka na ohere. Ọchịchọ ga-apụta ìhè na njem na dashọd nke na-ekewa ngalaba ọchịchọ site na ọrụ, ngwaahịa / mpaghara nsogbu, na ụdị ọchịchọ. Foundation ga-azaghachi ọchịchọ n'oge, ma soro ndị ngalaba otu arụkọ ọrụ iji kenye na ụdakọ ma were ọchịchọ dị kaihe mbụ. Anyị na ndị otu Wikimedia ga-ejikọ aka iji họpụta mpaghara atọ nke mmelite, nke e debanyere na atụmatụ kwa afọ nke Foundation 2025-26, nke kwesịrị imeziwanye ogo nnabata na mmezu nke ọchịchọ nwere mmetụta. Anyị ga-egosipụta ọchịchọ dị mma nke ndị ọrụ afọ ofufo na ndị otu foundation, na-eduga n'inwekwu ndị otu na ndị mmepe na ọchịchọ ndị ọzọ mezuru, nke ga-ebute afọ ojuju ngalaba otu. Idozi ọchịchọ ndị a na-eme ka obi ụtọ, ịdị irè, na njigide nke ndị na-enye aka dịkwuo mma, nke kwesịrị ịkwalite ndezi dị mma, ọdịnaya dị elu, na nweta ọtụtụ ndị ọgụgụ. |
Jack Wheeler |
| PES1.3 | mee ma mechie nnwale abụọ sitere na ngwaahịa/atụmatụ nyocha dị ugbu a nke na-enye anyị data na mbunye uche ka anyị si ewulite Wikipedia dị ka ebe ihe ọmụma maka ndị ji ngwa anyị eme ihe ugbu a na ndị afọ ofufo bụ ndị na-ege ntị na Q1 na Q2. Mezue ma kesaa mmụta na ndụmọdụ maka nkuchi enwere ike maka ọrụ OKR n'ọdịnihu na bọket Ahụmịhe Wiki na njedebe nke Q3. | Ọrụ a bụ ihe mmekọ na ebumnuche ndị na-ege ntị n'ọdịnihu, kama na-elekwasị anya na ikpughe ohere iji bawanye ma mebawanye nsonye nke ndị na-ege anyị ntị ugbu a (nke ndị ji Wikipedia eme ihe na ndị ntinye aka) site n'inyocha nke ọma nke echiche ngwaahịa.
O bi na PES1 ka ọ bụ ihe na-enye ume na ihe n'ebute ụbara - na-ewepụta oge ndị mmadụ n'otu n'otu na ndị otu na-etinye aka na hacking ma nnwale nke ọrụ dị n'akụkụ iji weta nlekwasị anya atụmatụ ndị ọzọ dị itụnaya. Kama ọrụ ndị a dị n'akụkụ ga a n'alaniyi (ọ bụghị ezigbo njikwa nye obere nweta ego anyị), KR a na-enye ukpụrụ nye ụfọdụ n'ime echiche ndị a nwere ike ime ka ọ bụrụ ntọala APP buru ibu site na nnwale ndị a enwetarala, ma na-eji oge ndị ọrụ na-arụ ọrụ nke ọma na-akpali nchepụta na mmepụta ha. Site n'ịkwalite ọtụtụ n'ime obere ọrụ ndị a, ndị dị mkpirikpi, anyị na-agbasawanye mgbasa nke 'bets' anyị maka mmụta na nnwale nke echiche nke nwere ike ịgbanwe Wikipedia n'ụzọ dabara na mkpa na atụmanya na-agbanwe agbanwe nke ndị na-ege anyị ntị ugbu a. Nke a ga-eme ka ọrụ anyị nwee mmetụta na ma dị ngwa ngwa ka ọ ga-enyere foundation aka ịhazi ebumnuche ziri ezi n'oge dị mkpirikpi. |
Rita Ho |
| PES1.4 | Mụta ka esi eme: ahazi, elebara anya, ma mee mkpebi na SLO. Họrọ ma ọ dịkarịa ala otu ihe ọhụrụ iji kọwaa SLO maka ka anyị na-ahapụ ya. Soro otu dị iche iche rụkọọ ọrụ (nke dị ka nke a: ngwaahịa, otu mmepe, SRE) iji kọwapụta SLO ahụ. Tugharia ma detuo ntuziaka maka ntọhapụ kwesịrị inwe SLO n'ọdịniihu yana otu esi edobe ha. | Future KR:
Hazie usoro na ngwa dị mfe maka ihazi na nlebara anya SLO maka mwepụta ọhụrụ. mee mKpesa akụkọ n'otu ụzọ , ma jiri ya mee mkpebi maka mgbe (ma ọ bụghị)ibute ụzọ ọrụ iji dozie ihe. Kekọrịta akụkọ gị na ngalaba otu dị iche ịche. N'ihi gịnị: Anyị amaghị mgbe ọ dị anyị mkpa ibute ọrụ ụzọ iji dozie ihe. Anyị nwekwara ọtụtụ koodu. Ka akara a na-aga n'ihu na-eto, enwere ọnọdụ ndị ọzọ ebe anyị nwere ike ikpebi n'etiti ịza ajụjụ ma ọ bụ ilekwasị anya na ihe ọhụrụ, na ejighị n'aka mgbe anyị kwesịrị. Ọzọkwa, ọ bụghị ihe doro anya nye ndị ọrụ na obodo ihe nkwado / nkwenye anyị na ntụkwasị obi na arụmọrụ bụ maka atụmatụ na ọrụ dị iche iche ha na-emekọrịta ihe. Ọ bụrụ na anyị akọwa ọkwa ọrụ a tụrụ anya ya, anyị nwere ike ịmara mgbe anyị kwesịrị ịnye ya ihe onwunwe ma ọ bụ na ọ bụghị. |
Mark Bergsma |
| PES1.5 | Define ownership and commitments (including SLOs) on services and learn how to track, report and make decisions as a standard and scalable practice by trialing it in 3 teams across senior leaders in the department. | After collaboratively defining an SLO for the EditCheck feature as part of PES1.5, we will now trial and learn from using the SLO in practice to help prioritisation of reliability work. We will also document roles and responsibilities for ownership of code/services, allowing us to make clear shared commitments on the level of ongoing support. We will try to use these as practices in 3 teams across the department. | Mark Bergsma |
Hypotheses
The hypotheses below are the specific things we are doing each quarter to address the associated key results above.
Each hypothesis is an experiment or stage in an experiment we believe will help achieve the key result. Teams make a hypothesis, test it, then iterate on their findings or develop an entirely different new hypothesis. You can think of the hypotheses as bets of the teams’ time–teams make a small bet of a few weeks or a big bet of several months, but the risk-adjusted reward should be commensurate with the time the team puts in. Our hypotheses are meant to be agile and adapt quickly. We may retire, adjust, or start a hypothesis at any point in the quarter.
To see the most up-to-date status of a hypothesis and/or to discuss a hypothesis with the team please click the link to its project page below.
Q1
The first quarter (Q1) of the WMF annual plan covers July-September.
| Wiki Experiences (WE) Hypotheses
[ WE Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| WE1.1.1 | If we expand the Event List to become a Community List that includes WikiProjects, then we will be able to gather some early learnings in how to engage with WikiProjects for product development. | |
| WE1.1.2 | If we identify at least 15 WikiProjects in 3 separate Wikipedias to be featured in the Community List, then we will be able to advise Campaigns Product in the key characteristics needed to build an MVP of the Community List that includes WikiProjects. | |
| WE1.1.3 | If we consult 20 event organizers and 20 WikiProject organizers on the best use of topics available via LiftWing, then we can prioritize revisions to the topic model that will improve topical connections between events and WikiProjects. | |
| WE1.2.1 | If we build a first version of the Edit Check API, and use it to introduce a new Check, we can evaluate the speed and ease with other teams and volunteers could use the API to create new Checks and Suggested Edits. | |
| WE1.2.2 | If we build a library of UI components and visual artefacts, Edit Check’s user experience can extend to accommodate Structured Tasks patterns. | |
| WE1.2.3 | If we conduct user tests on two or more design prototypes introducing structured tasks to newcomers within/proximate to the Visual Editor, then we can quickly learn which designs will work best for new editors, while also enabling engineers to assess technical feasibility and estimate effort for each approach. | mw:Growth/Constructive activation experimentation |
| WE1.2.4 | If we train an LLM on detecting "peacock" behavior, then we can learn if it can detect this policy violation with at least >70% precision and >50% recall and ultimately, decide if said LLM is effective enough to power a new Edit Check and/or Suggested Edit. | |
| WE1.2.5 | If we conduct an A/B/C test with the alt-text suggested edits prototype in the production version of the iOS app we can learn if adding alt-text to images is a task newcomers are successful with and ultimately, decide if it's impactful enough to implement as a suggested edit on the Web and/or in the Apps. | mw:Wikimedia Apps/iOS Suggested edits project/Alt Text Experiment |
| WE1.3.1 | If we enable additional customisation of Automoderator's behaviour and make changes based on pilot project feedback in Q1, more moderators will be satisfied with its feature set and reliability, and will opt to use it on their Wikimedia project, thereby increasing adoption of the product. | mw:Automoderator |
| WE1.3.2 | If we are able interpret subsets of wishes as moderator-related focus areas and share these focus areas for community input in Q1-Q2, then we will have a high degree of confidence that our selected focus area will improve moderator satisfaction, when it is released in Q3. | |
| WE2.1.1 | If we build a country-level inference model for Wikipedia articles, we will be able to filter lists of articles to those about a specific region with >70% precision and >50% recall. | m:Research:Language-Agnostic Topic Classification/Countries |
| WE2.1.2 | If we build a proof-of-concept providing translation suggestions that are based on user-selected topic areas, we will be set up to successfully test whether translators will find more opportunities to translate in their areas of interest and contribute more compared to the generic suggestions currently available. | mw: Translation suggestions: Topic-based & Community-defined lists |
| WE2.1.3 | If we offer list-making as a service, we’ll enable at least 5 communities to make more targeted contributions in their topic areas as measured by (1) change in standard quality coverage of relevant topics on the relevant wiki and (2) a brief survey of organizer satisfaction with topic area coverage on-wiki. | |
| WE2.1.4 | If we developed a proof of concept that adds translation tasks sourced from WikiProjects and other list-building initiatives, and present them as suggestions within the CX mobile workflow, then more editors would discover and translate articles focused on topical gaps. By introducing an option that allows editors to select translation suggestions based on topical lists, we would test whether this approach increases the content coverage in our projects. | mw: Translation suggestions: Topic-based & Community-defined lists |
| WE2.2.1 | If we expand Wikimedia's State of Languages data by securing data sharing agreements with UNESCO and Ethnologue, at least one partner will decide to represent Wikimedia’s language inclusion progress in their own data products and communications. On top of being useful to our partner institutions, our expanded dataset will provide important contextual information for decision-making and provide communities with information needed to identify areas for intervention. | |
| WE2.2.2 | If we map the language documentation activities that Wikimedians have conducted in the last 2 years, we will develop a data-informed baseline for community experiences in onboarding new languages. | |
| WE2.2.3 | If we provide production wiki access to 5 new languages, with or without Incubator, we will learn whether access to a full-fledged wiki with modern features such as those available on English Wikipedia (including ContentTranslation and Wikidata support, advanced editing and search results) aids in faster editing. Ultimately, this will inform us if this approach can be a viable direction for language onboarding for new or existing languages, justifying further investigation. | mw:Future of Language Incubation |
| WE2.3.1 | If we make two further improvements to media upload flow on Commons and share them with community, the feedback will be positive and it will help uploaders make less bad uploads (with the focus on copyright) as measured by the ratio of deletion requests within 30 days of upload. This will include defining designs for further UX improvements to the release rights step in the Upload Wizard on Commons and rolling out an MVP of logo detection in the upload flow. | |
| WE2.4.1 | If we build a prototype of Wikifunctions calls embedded within MediaWiki content, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2. | phab:T261472 |
| WE2.4.2 | If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2 (see hypothesis 1). | phab:T363391 |
| WE2.4.3 | If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful. | phab:T282926 |
| WE3.1.1 | Designing and qualitatively evaluating three proofs of concept focused on building curated, personalized, and community-driven browsing and learning experiences will allow us to estimate the potential for increased reader retention (experiment 1: providing recommended content in search and article contexts, experiment 2: summarizing and simplifying article content, experiment 3: making multitasking easier on wikis. | |
| WE3.1.3 | If we develop models for remixing content such as a content simplification or summarization that can be hosted and served via our infrastructure (e.g. LiftWing), we will establish the technical direction for work focused on increasing reader retention through new content discovery features. | |
| WE3.1.4 | If we analyze the projected performance impact of hypothesis WE3.1.1 and WE3.1.2 on the Search API, we can scope and address performance and scalability issues before they negatively affect our users. | |
| WE3.1.5 | If we enhance the search field in the Android app to recommend personalized content based on a user's interest and display better results, we will learn if this improves user engagement by observing whether it increases the impression and click-through rate (CTR) of search results by 5% in the experimental group compared to the control group over a 30-day A/B test. This improvement could potentially lead to a 1% increase in the retention of logged out users. | |
| 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. | ọrụ T292707 |
| WE6.2.5 | If we move MultiVersion routing out of MediaWiki, we 'll be able to ship single version MediaWiki containers, largely cutting down the size of containers allowing for faster deployments, as measured by the deployment tool. | SingleVersion MW: Routing options |
| WE6.3.1 | By consulting toolforge maintainers about the least sustainable aspects of the platform, we will be able to gather a list of potential categories to measure. | |
| WE6.3.2 | By creating a "standard" tool to measure the number of steps for a deployment we will be able to assess the maximal improvement in the deployment process. | |
| WE6.3.3 | If we conduct usability tests, user interviews, and competitive analysis to explore the existing workflows and use cases of Toolforge, we can identify key areas for improvement. This research will enable us to prioritize enhancements that have the most significant impact on user satisfaction and efficiency, laying the groundwork for a future design of the user interface. | |
| Signals & Data Services (SDS) Hypotheses
[ SDS Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| SDS 1.1.1 | If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics. | |
| SDS1.2.2 | If we study the recruitment, retention, and attrition patterns among long-tenure community members in official moderation and administration roles, and understand the factors affecting these phenomena (the ‘why’ behind the trends), we will better understand the extent, nature, and variability of the phenomenon across projects. This will in turn enable us to identify opportunities for better interventions and support aimed at producing a robust multi-generational framework for editors. | phab:T368791 |
| SDS1.2.1 | If we gather use cases from product and feature engineering managers around the use of AI in Wikimedia services for readers and contributors, we can determine if we should test and evaluate existing AI models for integration into product features, and if yes, generate a list of candidate models to test. | phab:T369281 |
| SDS1.3.1 | If we define the process to transfer all data sets and pipeline configurations from the Data Platform to DataHub we can build tooling to get lineage documentation automatically. | |
| SDS 1.3.2 | If we implement a well documented and understood process to produce an intermediary table representing MediaWiki Wikitext History, populated using the event platform, and monitor the reliability and quality of the data we will learn what additional parts of the process are needed to make this table production ready and widely supported by the Data Platform Engineering team. | |
| SDS2.1.2 | If we investigate the data products current sdlc, we will be able to determine inflection points where QTE knowledge can be applied in order to have a positive impact on Product Delivery. | |
| SDS2.1.3 | If the Growth team learns about the Metrics Platform by instrumenting a Homepage Module on the Metrics Platform, then we will be prepared to outline a measurement plan in Q1 and complete an A/B test on the new Metrics platform by the end of Q2. | |
| SDS2.1.4 | If we conduct usability testing on our prototype among pilot users of our experimentation process, we can identify and prioritize the primary pain points faced by product managers and other stakeholders in setting up and analyzing experiments independently. This understanding will lead to the refinement of our tools, enhancing their efficiency and impact. | |
| SDS2.1.5 | If we design a documentation system that guides the experience of users building instrumentation using the Metrics Platform, we will enable those users to independently create instrumentation without direct support from Data Products teams, except in edge cases. | phab:T329506 |
| SDS2.2.1 | If we define a metric for logged-out mobile app reader retention, which is applicable for analyzing experiments (A/B test), we can provide guidance for planning instrumentation to measure retention rate of logged out readers in the mobile apps and enable the engineering team to develop an experiment strategy targeting logged out readers. | |
| SDS2.2.2 | If we define a standard approach for measuring and analyzing conversion rates, it will help us establish a collection of well-defined metrics to be used for experimentation and baselines, and start enabling comparisons between experiments/projects to increase learning from these. | |
| SDS2.2.3 | If we define a standard way of measuring and analyzing clickthrough rate (CTR) in our products/features, it will help us design experiments that target CTR for improvement, standardize click-tracking instrumentation, and enable us to make CTR available as a target metric to users of the experimentation platform. | |
| SDS2.3.1 | If we conduct a legal review of proposed unique cookies for logged out users, we can determine whether there are any privacy policy or other legal issues which inform the community consultation and/or affect the technical implementation itself. | |
| Future Audiences (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| FA1.1.1 | If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform. | m:Future Audiences/Experiment:Add a Fact |
| Product and Engineering Support (PES) Hypotheses
[ PES Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| PES1.1.1 | If the P&T leadership team syncs regularly on how they’re guiding their teams towards a more iterative software development culture, and we collect baseline measurements of current development practices and staff sentiment on how we work together to ship products, we will discover opportunity areas for change management. The themes that emerge will enable us to build targeted guidance or programs for our teams in coming quarters. | |
| PES1.2.2 | If the Moderator Tools team researches the Community Wishlist and develops 2+ focus areas in Q1, then we can solicit feedback from the Community and identify a problem that the Community and WMF are excited about tackling. | |
| PES1.2.3 | If we bundle 3-5 wishes that relate to selecting and inserting templates, and ship an improved feature in Q1, then CommTech can take the learnings to develop a Case Study for the foundation to incorporate more "focus areas" in the 2025-26 annual plan. | |
| PES1.3.1 | If we provide insights to audiences about their community and their use of Wikipedia over a year, it will stimulate greater connection with Wikipedia – encouraging greater engagement in the form of social sharing, time spent interacting on Wikipedia, or donation. Success will be measured by completing an experimental project that provides at least one recommendation about “Wikipedia insights” as an opportunity to increase onwiki engagement. | mw: New Engagement Experiments#PES1.3.1_Wikipedia_user_insights |
| PES1.3.2 | If we create a Wikipedia-based game for daily use that highlights the connections across vast areas of knowledge, it will encourage consumers to visit Wikipedia regularly and facilitate active learning, leading to longer increased interaction with content on Wikipedia. Success will be measured by completing an experimental project that provides at least one recommendation about gamification of learning as an opportunity to increase onwiki engagement. | mw: New Engagement Experiments#PES_1.3.2:_Wikipedia_games |
| PES1.3.3 | If we develop a new process/track at a Wikimedia hack event to incubate future experiments, it will increase the impact and value of such events in becoming a pipeline for future annual plan projects, whilst fostering greater connection between volunteers and engineering/design staff to become more involved with strategic initiatives. Success will be measured by at least one PES1.3 project being initiated and/or advanced to an OKR from a foundation-supported event. | mw: New Engagement Experiments#PES_1.3.3:_Incubator_space |
| PES1.4.1 | If we draft an SLO with the Editing team releasing Edit Check functionality, we will begin to learn and understand how to define and track user-facing SLOs together, and iterate on the process in the future. | |
| PES1.4.2 | If we define and publish SLAs for putting OOUI into “maintenance mode”, growth of new code using OOUI across Wikimedia projects will stay within X% in Q1. | |
| PES1.4.3 | If we map ownership using the proposed service catalog for known owned services in Q1, we will be able to identify significant gaps in service catalog as it helps in solving the SLO culture by the end of the year. | |
Q2
The second quarter (Q2) of the WMF annual plan covers October-December.
| Wiki Experiences (WE) Hypotheses
[ WE Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| WE1.1.1 | If we expand the Event list to become a Community List that includes WikiProjects, then we will be able to gather some early learnings in how to engage with WikiProjects for product development. | Campaigns/Foundation Product Team/Event list |
| WE1.1.2 | If we launch at least 1 consultation focused on on-wiki collaborations, and if we collect feedback from at least 20 people involved in such collaborations, then we will be able to advise Campaigns Product on the key characteristics needed to develop a new or improved way of connecting. | Campaigns/WikiProjects |
| WE1.1.3 | If we consult 20 event organizers and 20 WikiProject organizers on the best use of topics available via LiftWing, then we can prioritize revisions to the topic model that will improve topical connections between events and WikiProjects. | |
| WE1.1.4 | If we integrate CampaignEvents into Community Configuration in Q2, then we will set the stage for at least 5 more wikis opting to enable extension features in Q3, thereby increasing tool usage. | |
| WE1.2.2 | If we build a library of UI components and visual artifacts, Edit Check’s user experience can extend to accommodate Structured Tasks patterns. | |
| WE1.2.5 | If we conduct an A/B/C test with the alt-text suggested edits prototype in the production version of the iOS app we can learn if adding alt-text to images is a task newcomers are successful with and ultimately, decide if it's impactful enough to implement as a suggested edit on the Web and/or in the Apps. | |
| WE1.2.6 | If we introduce new account holders to the “Add a Link” Structured Task in Wikipedia articles, we expect to increase the percentage of new account holders who constructively activate on mobile by 10% compared to the baseline. | |
| WE1.3.1 | If we enable additional customisation of Automoderator's behaviour and make changes based on pilot project feedback in Q1, more moderators will be satisfied with its feature set and reliability, and will opt to use it on their Wikimedia project, thereby increasing adoption of the product. | mw:Moderator_Tools/Automoderator |
| WE1.3.3 | If we improve the user experience and features of the Nuke extension during Q2, we will increase administrator satisfaction of the product by 5pp by the end of the quarter. | mw:Extension:Nuke/2024_Moderator_Tools_project |
| WE2.1.3 | If we offer list-making as a service, we’ll enable at least 5 communities to make more targeted contributions in their topic areas as measured by (1) change in standard quality coverage of relevant topics on the relevant wiki and (2) a brief survey of organizer satisfaction with topic area coverage on-wiki. | |
| WE2.1.4 | If we developed a proof of concept that adds translation tasks sourced from WikiProjects and other list-building initiatives, and present them as suggestions within the CX mobile workflow, then more editors would discover and translate articles focused on topical gaps. By introducing an option that allows editors to select translation suggestions based on topical lists, we would test whether this approach increases the content coverage in our projects. |
|
| WE2.1.5 | If we expose topic-based translation suggestions more broadly and analyze its initial impact, we will learn which aspects of the translation funnel to act on in order to obtain more quality translations. | |
| WE2.2.4 | If we provide production wiki access to 5 new languages, with or without Incubator, we will learn whether access to a full-fledged wiki with modern features such as those available on English Wikipedia (including ContentTranslation and Wikidata support, advanced editing and search results) aids in faster editing. Ultimately, this will inform us if this approach can be a viable direction for language onboarding for new or existing languages, justifying further investigation. | |
| WE2.2.5 | If we move addwiki.php to core and customize it to Wikimedia, we will improve code quality in our wiki creation system making it testable and robust, and we will make it easy for creators of new wikis and thereby make significant steps towards simplifying wiki creation process. | phab:T352113 |
| WE2.3.2 | If we make two further improvements to media upload flow on Commons and share them with community, the feedback will be positive and it will help uploaders make less bad uploads (with the focus on copyright) as measured by the ratio of deletion requests within 30 days of upload. This will include release of further UX improvements to the release rights step in the Upload Wizard on Commons and automated detection of external sources. | |
| WE2.3.3 | If the BHL-Wikimedia Working Group creates Commons categories and descriptive guidelines for the South American and/or African species depicted in publications, they will make 3,000 images more accessible to biodiversity communities. (BHL = Biodiversity Heritage Library) |
|
| WE2.4.1 | If we build a prototype of Wikifunctions calls embedded within MediaWiki content and test it locally for stability, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2. | phab:T261472 |
| WE2.4.2 | If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2, as stated in Hypothesis 1. | phab:T363391 |
| WE2.4.3 | If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful. | phab:T282926 |
| WE3.1.3 | If we develop models for remixing content such as a content simplification or summarization that can be hosted and served via our infrastructure (e.g. LiftWing), we will establish the technical direction for work focused on increasing reader retention through new content discovery features. | Research |
| WE3.1.6 | If we introduce a personalized rabbit hole feature in the Android app and recommend condensed versions of articles based on the types of topics and sections a user is interested in, we will learn if the feature is sticky enough to result in multi-day usage by 10% of users exposed to the experiment over a 30-day period, and a higher pageview rate than users not exposed to the feature. | |
| WE3.1.7 | If we run a qualitative experiment focused on presenting article summaries to web readers, we will determine whether or not article summaries have the potential to increase reader retention, as proxied by clickthrough rate and usage patterns | |
| WE3.1.8 | If we build one feature which provides additional article-level recommendations, we will see an increase in clickthrough rate of 10% over existing recommendation options and a significant increase in external referrals for users who actively interact with the new feature. | |
| WE3.2.2 | Increasing the prominence of entry points to donations on the logged-out experiences of the Vector web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY. | mw:Readers/2024_Reader_and_Donor_Experiences |
| WE3.2.3 | If we make the “Donate” button in the iOS App more prominent by making it one click or less away from the main navigation screen, we will learn if discoverability was a barrier to non banner donations. | Navigation Refresh |
| WE3.2.4 | If we update the contributions page for logged-in users in the app to include an active badge for someone that is an app donor and display an inactive state with a prompt to donate for someone that decided not to donate in app, we will learn if this recognition is of value to current donors and encourages behavior of donating for prospective donors, informing if it is worth expanding on the concept of donor badges or abandoning it. | Private Donor Recognition Experiment |
| WE3.2.5 | If we create a Wikipedia in Review experiment in the Wikipedia app, to allow users to see and share personalized data about their reading, editing, and donation habits, we will see 2% of viewers donate on iOS as a result of this feature, 5% click share and, 65% of users rating the feature neutral or satisfactory. | Personalized Wikipedia Year in Review |
| WE3.2.7 | Increasing the prominence of entry points to donations on the logged-out experiences of the Minerva web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY. | |
| WE3.3.2 | If we develop the Charts MVP and get it working end-to-end in production test wikis, at least two Wikipedias + Commons agree to pilot it before the code freeze in December. | |
| WE3.4.1 | If we were to explore the feasibility by doing an experiment of setting up smaller PoPs in cloud providers like Amazon, we can expand our data center map and reach more users around the world, at reduced cost and increased turn-around time. | |
| WE4.1.2 | If we deploy at least one iteration of the Incident Reporting System MVP on pilot wikis, we will be able to gather valuable data around the frequency and type of incidents being reported. | https://meta.wikimedia.org/wiki/Incident_Reporting_System# |
| WE4.2.1 | If we explore and define Wikimedia-specific methods for a unique device identification model, we will be able to define the collection and storage mechanisms that we can later implement in our anti-abuse workflows to enable more targeted blocking of bad actors. | |
| WE4.2.9 | If we provide contextual information about reputation associated with an IP that is about to be blocked, we will see fewer collateral damage IP and IP range blocks, because administrators will have more insight into potential collateral damage effects of a block. We can measure this by instrumenting Special:Block and observing how behavior changes when additional information is present, vs when it is not. | |
| WE4.2.2 | If we define an algorithm for calculating a user account reputation score for use in anti-abuse workflows, we will prepare the groundwork for engineering efforts that use this score as an additional signal for administrators targeting bad actors on our platform. We will know the hypothesis is successful if the algorithm for calculating a score maps with X% precision to categories of existing accounts, e.g. a "low" score should apply to X% of permanently blocked accounts. | |
| WE4.2.3 | If we build an evaluation framework using publicly available technologies similar to the ones used in previous attacks we will learn more about the efficacy of our current CAPTCHA at blocking attacks and could recommend a CAPTCHA replacement that brings a measurable improvement in terms of the attack rate achievable for a given time and financial cost. | |
| WE4.3.1 | If we apply some machine learning and data analysis tools to webrequest logs during known attacks, we'll be able to identify abusive IP addresses with at least >80% precision sending largely malicious traffic that we can then ratelimit at the edge, improving reliability for our users. | |
| WE4.3.3 | If we deploy a proof of concept of the 'Liberica' load balancer, we will measure a 33% improvement in our capacity to handle TCP SYN floods. | |
| WE4.3.5 | By creating a system that spawns and controls thousands of virtual workers in a cloud environment, we will be able to simulate Distributed Denial of Service (DDoS) attacks and effectively measure the system's ability to withstand, mitigate, and respond to such attacks. | |
| WE4.3.6 | If we integrate the output of the models we built in WE 4.3.1 with the dynamic thresholds of per-ip concurrency limits we've built for our TLS terminators in WE 4.3.2, we should be able to increase our ability to neutralize automatically attacks with 20% more volume, as measured with the simulation framework we're building. | |
| WE4.3.7 | If we roll out a user-friendly web application that enables assisted editing and creation of requestctl rules, SREs will be able to mitigate cachebusting attacks in 50% less time than our established baseline. | |
| WE4.4.2 | If we deploy Temporary Accounts to a set of small-to-medium sized projects, we will be able to the functionality works as intended and will be able to gather data to inform necessary future work. | mw:/wiki/Trust_and_Safety_Product/Temporary_Accounts |
| WE5.1.1 | If we successfully roll out Parsoid Read Views to all Wikivoyages by Q1, this will boost our confidence in extending Parsoid Read Views to all Wikipedias. We will measure the success of this rollout through detailed evaluations using the Confidence Framework reports, with a particular focus on Visual Diff reports and the metrics related to performance and usability. Additionally, we will assess the reduction in the list of potential blockers, ensuring that critical issues are addressed prior to wider deployment. | |
| WE5.1.3 | If we reroute the endpoints currently exposed under rest_v1/page/html and rest_v1/page/title paths to comparable MW content endpoints, then we can unblock RESTbase sunsetting without disrupting clients in Q1. | |
| WE5.1.4 | If we complete the remaining work to mitigate the impact of browsers' anti-tracking measures on CentralAuth autologin and move to a more resilient authentication infrastructure (SUL3), we will be ready to roll out to production wikis in Q2. | |
| WE5.1.5 | If we increase the number of relevant SonarCloud rules enabled for key MediaWiki Core repositories and refine the quality of feedback provided to developers, we will optimize the developer experience and enable them to improve the maintainability of the MediaWiki codebase in the future. This will be measured by tracking developer satisfaction levels and whether test group developers feel the tool is becoming more useful and effective in their workflow. Feedback will be gathered through surveys and direct input from developers to evaluate the perceived impact on their confidence in the tool and the overall development experience. | |
| WE5.1.7 | If we represent all content module endpoint responses (10 in total) in our MediaWiki REST API OpenAPI spec definitions, we will be able to implement programmatic validation to guarantee that our generated documentation matches the actual responses returned in code. | |
| WE5.1.8 | If we introduce support for endpoint description translation (ie: does not include actual object definitions or payloads) into our generated MediaWiki REST API OpenAPI specs, we can lay the foundation to support Wikimedia’s expected internationalization standards. | |
| WE5.2.3 | If we conduct an experiment to reimplement at least [1-3] existing Core and Extension features using a new Domain Event and Listener platform component pattern as an alternative to traditional hooks, we will be able to confirm our assumption of this intervention enabling simpler implementation with more consistent feature behavior. | |
| WE5.3.3 | If we instrument both parsers to collect availability of prior parses and timing of template expansions, and to classify updates and dependencies, we can prioritize work on selective updates (Hypothesis 5.3.2) informed by the quantification of the expected performance benefits. | |
| WE5.3.4 | If we can increase the capability of our prototype selective update implementation in Parsoid using the learnings from the 5.3.1 hypothesis, we can leverage more opportunities to increase the performance benefit from selective update. | |
| WE5.4.1 | If the MediaWiki engineering group is successful with release process accountability and enhances its communication process by the end of Q2 in alignment with the product strategy, we will eliminate the current process that relies on unplanned or volunteer work and improve community satisfaction with the release process. Measured by community feedback on the 1.43 LTS release coupled with a significant reduction in unplanned staff and volunteer hours needed for release processes. | |
| WE5.4.2 | If we research and build a process to more regularly upgrade PHP in conjunction with our MediaWiki release process we will increase speed and security while reducing the complexity and runtime of our CI systems, by observing the success of PHP 8.1 upgrade before 1.43 release. | |
| WE6.1.3 | If we collect insights on how different teams are making technical decisions we are able to gather good practices and insights that can enable and scale similar practices across the organization. | |
| WE6.1.4 | If we research solutions for indexing the code of all projects hosted in WMF’s code repositories, we will be able to pick a solution that allows our users to quickly discover where the code is located whenever dealing with incident response or troubleshooting. | |
| WE6.1.5 | If we test a subset of draft metrics on an experimental group of technical documentation collections, we will be able to make an informed decision about which metrics to implement for MediaWiki documentation. | Wikimedia_Technical_Documentation_Team/Doc_metrics |
| WE6.2.1 | If we publish a versioned build of MediaWiki, extensions, skins, and Wikimedia configuration at least once per day we will uncover new constraints and establish a baseline of wallclock time needed to perform a build. | mw:Wikimedia Release Engineering Team/Group -1 |
| WE6.2.2 | If we replace the backend infrastructure of our existing shared MediaWiki development and testing environments (from apache virtual servers to kubernetes), it will enable us to extend its uses by enabling MediaWiki services in addition to the existing ability to develop MediaWiki core, extensions, and skins in an isolated environment. We will develop one environment that includes MediaWiki, one or more Extensions, and one or more Services. | wikitech:Catalyst |
| WE6.2.3 | If we create a new deployment UI that provides more information to the deployer and reduce the amount of privilege needed to do deployment, it will make deployment easier and open deployments to more users as measured by the number of unique deployers and number of patches backported as a percentage of our overall deployments. | mw:SpiderPig |
| WE6.2.5 | If we move MultiVersion routing out of MediaWiki, we 'll be able to ship single version MediaWiki containers, largely cutting down the size of containers allowing for faster deployments, as measured by the deployment tool. | https://docs.google.com/document/d/1_AChNfiRFL3VdNzf6QFSCL9pM2gZbgLoMyAys9KKmKc/edit |
| WE6.2.6 | If we gather feedback from QTE, SRE, and individuals with domain specific knowledge and use their feedback to write a design document for deploying and using the wmf/next OCI container, then we will reduce friction when we start deploying that container. | T379683 |
| WE6.3.4 | If we enable the automatic deployment of a minimal tool, we will be able to evaluate the end to end flow and set the groundwork to adding support for more complex tools and deployment flows. | phab:T375199 |
| WE6.3.5 | By assessing the relative importance of each sustainability category and its associated metrics, we can create a normalized scoring system. This system, when implemented and recorded, will provide a baseline for measuring and comparing Toolforge’s sustainability progress over time. | phab:T376896 |
| WE6.3.6 | If we conduct discovery, such as target user interviews and competitive analysis, to identify existing Toolforge pain points and improvement opportunities, we will be able to recommend a prioritized list of features for the future Toolforge UI. | Phab:T375914 |
| Signals & Data Services (SDS) Hypotheses
[ SDS Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| SDS 1.1.1 | If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics. | |
| SDS1.2.1.B | If we test the accuracy and infrastructure constraints of 4 existing AI language models for 2 or more high-priority product use-cases, we will be able to write a report recommending at least one AI model that we can use for further tuning towards strategic product investments. | Phab:T377159 |
| SDS1.2.2 | If we study the recruitment, retention, and attrition patterns among long-tenure community members in official moderation and administration roles, and understand the factors affecting these phenomena (the ‘why’ behind the trends), we will better understand the extent, nature, and variability of the phenomenon across projects. This will in turn enable us to identify opportunities for better interventions and support aimed at producing a robust multi-generational framework for editors. | Learn more. |
| SDS1.2.3 | If we combine existing knowledge about moderators with quantitative methods for detecting moderation activity, we can systematically define and identify Wikipedia moderators. | T376684 |
| SDS1.3.1.B | If we integrate the Spark / DataHub connector for all production Spark jobs, we will get column-level lineage for all Spark-based data platform jobs in DataHub. | |
| SDS1.3.2.B | If we implement a frequently run Spark-based MariaDB MW history data querying job, reconciliate missing events and enrich them, we will provide a daily updated MW history wikitext content data lake table. | |
| SDS2.1.1 | If we create an integration test environment for the proposed 3rd party experimentation solution, we can collaborate practically with Data SRE, SRE, QTE, and Product Analytics to evaluate the solution’s viability within WMF infrastructure in order to make a confident build/install/buy recommendation. | mw:Data_Platform_Engineering/Data_Products/work_focus |
| SDS2.1.3 | If the Growth team learns about the Metrics Platform by instrumenting a Homepage Module on the Metrics Platform, then we will be prepared to outline a measurement plan in Q1 and complete an A/B test on the new Metrics platform by the end of Q2. | |
| SDS2.1.4 | If we conduct usability testing on our prototype among pilot users of our experimentation process, we can identify and prioritize the primary pain points faced by product managers and other stakeholders in setting up and analyzing experiments independently. This understanding will lead to the refinement of our tools, enhancing their efficiency and impact. | |
| SDS2.1.5 | If we design a documentation system that guides the experience of users building instrumentation using the Metrics Platform, we will enable those users to independently create instrumentation without direct support from Data Products teams, except in edge cases. | ọrụ T329506 |
| SDS2.1.7 | If we provide a function for user enrollment and a mechanism to capture and store CTR events to a monotable in a pre-declared event stream we can ship MPIC Alpha in order to launch an basic split A/B test on logged in users. | |
| SDS2.2.2 | If we define a standard approach for measuring and analyzing conversion rates, it will help us establish a collection of well-defined metrics to be used for experimentation and baselines, and start enabling comparisons between experiments/projects to increase learning from these. | |
| SDS2.3.1 | If we conduct a legal review of proposed unique cookies for logged out users, we can determine whether there are any privacy policy or other legal issues which inform the community consultation and/or affect the technical implementation itself. | |
| Future Audiences (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| FA1.1.1 | If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform. | Experiment:Add a Fact |
| Product and Engineering Support (PES) Hypotheses
[ PES Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| PES1.2.4 | If we research the Task Prioritization focus area in the Community Wishlist in early Q2, we will be able to identify and prioritize work that will improve moderator satisfaction, which we can begin implementing in Q3. | |
| PES1.2.5 | If we are able to publish and receive community feedback on 6+ focus areas in Q2, then we will have confidence in presenting at least 3+ focus areas for incorporation in the 2025-26 annual plan. | |
| PES1.2.6 | By introducing favouriting templates, we will improve the number of templates added via the template dialog by 10%. | |
| PES1.3.4 | If we create an experience that provides insights to Wikipedia Audiences about their community over the year, it will stimulate greater connection with Wikipedia – encouraging engagement in the form of social sharing, time spent interacting on Wikipedia, or donation. | |
| PES1.4.1 | If we draft an SLO with the Editing team releasing Edit Check functionality, we will begin to learn and understand how to define and track user-facing SLOs together, and iterate on the process in the future. | |
| PES1.4.2 | If we define and publish SLAs for putting OOUI into “maintenance mode”, growth of new code using OOUI across Wikimedia projects will stay within X% in Q1. | |
| PES1.4.3 | If we map ownership using the proposed service catalog for known owned services in Q1, we will be able to identify significant gaps in service catalog as it helps in solving the SLO culture by the end of the year. | |
| PES1.5.1 | If we finalize and publish the Edit Check SLO draft, practice incorporating it in regular workflows and decisions, and draft a Citoid SLO, we’ll continue learning how to define and track user-facing and cross-team SLOs together. | |
| PES1.5.2 | If we clarify and define in writing a document with set of roles and responsibilities of stakeholders throughout the service lifecycle, this will enable teams to make informed commitments in the Service Catalog, including SLOs | |
Nkọwa gbasara bọket
Mmụtara Wiki
Ebumnuche nke bọket a bụ iji mee ezi mwepụta , imelite na imepụta ihe ọhụrụ na mmụta wiki nke na-enye aka ikesa ihe ọmụma efu n'ụwa niile. Bọket a dakọtara na atụmatụ Movement Strategy #2 (Improve User Experience) yana #3 (Provide for Safety and Inclusion ). Ndị na-ege anyị ntị gụnyere ndị niile na-eme ntunye na weebụsaịtị anyị, yana ndị ọgụụ na ndị ọzọ na-enweta ihe ọmụma n'efu. Anyị na-akwado webụsaịtị zuru ụwa nke ogo nke iri, yana ọtụtụ akụrụngwa ndị ọzọ dị mkpa n'efu. Sistemụ ndị a nwere arụmọrụ yana ihe achọrọ n'oge tinyere ụlọ ọrụ teknụzụ kachasị ukwuu n'ụwa. Anyị na-enye oghere ndị ọrụ na wikis, ntụgharị asụsụ, ndị nrụpụta API (na ndị ọzọ!) yana na-akwado ngwa na akụrụngwa nke jikọtara ndị mejupụtara otu a dị ka ebe siri ike nye ndị ọrụ afọ ofufo imekọ ihe ọnụ iji wepụta ihe ọmụma efu n'ụwa niile. Ebumnobi anyị maka bọket a kwesịrị inyere anyị aka imeziwanye teknụzụ na ikike anyị, hụ na anyị na-aga n'ihu na-emeziwanye ahụmịhe nke ndị ndezi afọ ofufo na ndị na-ahazi ọrụ anyị, kwalite mmụtara nke ndị na-enye aka na teknụzụ ndị na-arụ ọrụ iji melite ma ọ bụ welie mmụtara wiki, ma hụ na mmụtara dị ukwuu maka ndị ọgụụ na ndị na-azụ ihe ọmụma n'efu n'ụwa nile. Anyị ga-eme nke a site na ọrụ ngwaahịa na teknụzụ, yana site na nyocha na ịzụ ahịa. Anyị na-atụ anya inwe ebumnuche ise maka bọket a.
Ọ bụ ndị mmadụ na-ewu ihe ọmụma! N'ihi ya, atụmatụ anyị kwa afọ ga-elekwasị anya na ọdịnaya a yana ndị na-enye aka imepụta ọdịnaya a na ndị na-enweta tinyere ndị na-agụ ya.
Ebumnobi anyị bụ imepụta atụmatụ ịrụ ọrụ hiwere isi na atụmatụ dị ugbu a, ọkachasị n'echiche anyị gbasara onye ntinye aka, ndị ahịa na ọdịnaya "flywheel". Ngbanwe bụ isi m na-arịọ bụ imesi ike na akụkụ ọdịnaya nke flywheel, yana nyocha ihe ndị nhazi na ndị ọrụ anyị nwere ike ịchọ n'aka anyị ugbu a, n'ebumnobi ịchọpụta ngụkọta nkwudosike otu n'ọdịnihu.
Akara ngosi na Ọrụ Data
Iji mezuo Movement Strategy Recommendations maka Ịgba mbọ ịha nhata n'ime Mkpebi (Recommendation #4), Mmelite mmụtara Onye Ọrụ (Recommendation #2), na Inyocha, Ntuzi na isonye Ndozigharị (Recommendation #10), ndị na-eme mkpebi sitere na gburugburu Wikimedia Movement ga-enwerịrị ike ịnweta data, ụdị, nghọta, na ngwaọrụ ziri ezi ndị nwere ike inyere ha aka ịmata mmetụta (ma nke enwetara na ịdị mkpa) nke ọrụ ha na ọrụ nke otu ha, na-eme ka ha nwee ike ịme mkpebi dị mma.
N'ime bọket Signals & Data Services, anyị achọpụtala ndị na-ege ntị anọ bụ isi: ndị ọrụ Wikimedia Foundation, ndị mmekọ Wikimedia na otu ndị ọrụ, ndị otu mmepe na-ejigharị ọdịnaya anyị eme ihe, yana ndị nyocha Wikimedia, anyị na-etinye mkpa ndịa n'ihu ma lebara mwepụtara na nghọta mkpa nke ndị na-ege ntị. Ọrụ anyị ga-agụnye ọrụ dị iche iche: ịkọwapụta ohere, ịmepụta mgbakọ, ịmepụta pipeline maka ndebanye mgbakọ , na ịmepụta data na mgbaàmà ahụmahụ nchọpụta na ụzọ ndị na-enyere ndị na-eme mkpebi aka ịmekọrịta nke ọma na ọṅụ na data na nghọta.
Ndị na-ege ntị n'ọdịnihu
.svg)
Ebumnuche nke bọket a bụ inyocha atụmatụ metụtara ịgbasawnye karịa ndị na-ege anyị ntị nke ndị na-azụ ahịa na ndị ntunye, na-ịgba mbọ iji ruo onye ọ bụla nọ n'ụwa n'ezie dịka akụrụngwa dị mkpa nke ngalaba nke ihe ọmụma efu. bọketị a dakọtara na Movement Strategy Recommendation #9 (Mepụta ihe ọhụrụ nye mmụta n'efu). Na-ịga n'ihu, ndị mmadụ na-enweta ihe ọmụma na ahụmahụ na ụdị pụrụ iche na ụkpụrụ anyị nke webụsaịtị akụkọ - ndị mmadụ na-eji ndị enyemaka olu, na-etinye oge na vidiyo, na-etinye aka na AI, na ihe ndị ọzọ. N'ime bọket a, anyị ga-atụpụta ma nwalee echiche gbasara ọdịnihu ga-adị ogologo oge maka usoro ihe ọmụma gburugburu na otu anyị ga-esi bụrụ akụrụngwa ya dị mkpa. Anyị ga-eme nke a site na ọrụ ngwaahịa na teknụzụ, yana site na nyocha, mmekorita, na ịzụ ahịa. Ka anyị na-achọpụta ogo ndị ihe ịtụanya n'ọdịnihu, mmụta sitere na bọket a ga-emetụta ma gbasaa site na bọket #1 na #2 na atụmatụ afọ gara nke ọma, n'ịkpatụ ngwaahịa anyị na teknụzụ ka ha ruo n'ebe ha kwesịrị nke bụ ijere ndị na-achọ ihe ọmụma n'ọdịnihu ozi. Ebumnobi anyị na bọketị a kwesịrị ịkpali anyị ịnwale ma nyochaa ka anyị na-etinye nlegara anya ọdịnihu nke ihe ọmụma efu n' uche.
Sub-bọcket
Anyị nwekwara "sub-bọket " abụọ ọzọ nke mejupụtara akụkụ nke ọrụ dị oke mkpa, nke ga-adịrịrị na Foundation iji kwado isi ọrụ anyị , yana ụfọdụ n'ime ha nke anyị na-ejikọta na ụlọ ọrụ ngwanrọ ọ bụla. "Sub-bọket" ndị a agaghị enwe oru dị elu nke onwe ha, kama ha ga-enwe ntunye ma ha ga-akwadokwa ebumnobi dị elu nke otu ndị ọzọ. Ha bụ
- Ntọala akụrụngwa. bọketị a na-anọchịte otu ndị na-akwado ma na-agbanwe ndị datacenter anyị, nhazi anyị na nchekwa , enyemaka ọrụ iji rụọ ọrụ ha, tinyere ngwaọrụ na usoro na-enyere aka ọrụ nke saịtị na ọrụ ihu ọha anyị.
- Nkwado ngwaahịa na injinia . bọketị a gụnyere otu ndị na-arụ ọrụ "n'ọtụtụ" na-enye aka ọrụ nye otu ndị ọzọ na-eme ka nrụpụta na arụmọrụ nke otu ndị ọzọ dịkwuo mma.