Річний план Фонду Вікімедіа/2024-2025/ЦКР Продукту і технології
Цей документ представляє першу частину процесу планування на 2024-25 роки для відділів Продукту і Технології Фонду Вікімедіа. Він описує «цілі та ключові результати» (ЦКР) цих відділів. Це є продовженням структури робочих портфелів (названих «кошиками»), яка була започаткована минулого року.
.jpg)
У листопаді я говорила з вами про те, що, на мою думку, є найнагальнішим питанням, яке стоїть перед рухом Вікімедіа: як ми можемо зробити так, щоб Вікіпедія та всі проєкти Вікімедіа були доступними для багатьох поколінь? Я хотіла б подякувати всім, хто знайшов час, щоб по-справжньому поміркувати над цим питанням і відповісти мені безпосередньо, і тепер, коли я мала нагоду поміркувати над вашими відповідями, поділюся тим, про що я дізналася.
По-перше, не існує єдиної причини, чому волонтери роблять свій внесок. Для того, щоб виховати кілька поколінь волонтерів, ми повинні краще розуміти багато причин, чому люди присвячують свій час нашим проєктам. Далі, ми повинні зосередитися на тому, що відрізняє нас від інших: на нашій здатності надавати вартий довіри контент в умовах поширення дезінформації та мізінформації в інтернеті та на платформах, які змагаються за увагу нових поколінь. Це містить у собі забезпечення виконання нашої місії зібрати й донести до світу суму всіх людських знань, розширюючи наше охоплення відсутньої інформації, яка може бути спричинена нерівністю, дискримінацією або упередженістю. Наш контент також повинен служити й залишатися життєво важливим у мінливому інтернеті, керованому штучним інтелектом і багатим досвідом. Нарешті, нам потрібно знайти шляхи сталого фінансування нашого руху, розробивши спільну стратегію для наших продуктів і доходів, щоб ми могли фінансувати цю роботу в довгостроковій перспективі.
Ці ідеї будуть відображені у річному плані Фонду Вікімедіа на 2024–2025 роки, першою частиною якого я ділюся з вами сьогодні у вигляді проєкту цілей для нашої роботи над продуктом і технологією. Як і минулого року, весь наш річний план буде зосереджений на технологічних потребах наших аудиторій і платформ, і ми хотіли б отримати від вас зворотний зв'язок, щоб знати, чи ми зосереджуємося на правильних проблемах. Ці цілі ґрунтуються на ідеях, які ми отримували від членів спільноти протягом останніх кількох місяців через Розмови:2024, списки розсилки та сторінки обговорення, а також на заходах спільноти щодо нашої продуктової та технологічної стратегії на наступний рік. Ви можете переглянути повний список проєктів цілей нижче.
«Ціль» — це напрямок високого рівня, який визначатиме продуктові та технологічні проєкти на наступний фінансовий рік, за які ми візьмемося. Вони навмисно широкі, представляють напрямок нашої стратегії і, що важливо, показують, які виклики ми пропонуємо визначити пріоритетними серед багатьох можливих сфер діяльності на наступний рік. Ми ділимося цим зараз, щоб члени спільноти могли допомогти сформувати наше мислення на ранній стадії, ще до того, як будуть затверджені бюджети та вимірні цілі на рік.
Зворотний зв'язок
Однією зі сфер, в якій ми особливо хотіли б отримати зворотний зв'язок, є наша робота, що згрупована під назвою «Вікідосвід». «Вікідосвід» стосується того, як ми ефективно надаємо, покращуємо та інноваційно вдосконалюємо те, як люди безпосередньо користуються вікі, як дописувачі, так і користувачі (споживачі вмісту) чи донори. Це передбачає роботу над підтримкою наших основних технологій і можливостей, а також над покращенням досвіду редакторів-волонтерів — зокрема, редакторів з розширеними правами — за допомогою кращих функцій та інструментів, послуг перекладу та оновлення платформи.
Ось деякі думки з наших нещодавніх обговорень стосовно планування, а також кілька запитань до всіх вас, щоб допомогти нам покращити наші ідеї:
- Волонтерство у проєктах Вікімедіа має приносити задоволення. Ми також вважаємо, що досвід співпраці онлайн має бути основною частиною того, що змушує волонтерів повертатися. Що потрібно для того, щоб редагування приносило волонтерам задоволення і щоб вони краще працювали разом над створенням вартого довіри вмісту?
- Надійність нашого вмісту — це частина унікального внеску Вікімедіа у світ і те, що змушує людей приходити на нашу платформу і користуватися нашим вмістом. Що ми можемо створити, щоб допомогти зростанню вартого довіри вмісту швидше, але все ще в межах стандартів якості, встановлених спільнотами в кожному проєкті?
- Щоб залишатися актуальною і конкурувати з іншими великими онлайн-платформами, Вікімедіа потребує нового покоління користувачів, які б відчували зв'язок з нашим вмістом. Як ми можемо зробити так, щоб наш вміст було легше знаходити та взаємодіяти з ним читачам і донорам?
- В епоху, коли процвітає зловживання в інтернеті, ми повинні переконатися, що наші спільноти, платформа і система обслуговування захищені. Ми також стикаємося з такими, що еволюціонують, зобов'язаннями щодо дотримання відповідності законодавству, коли глобальні політики прагнуть формувати конфіденційність, ідентичність та обмін інформацією в Інтернеті. Які покращання наших можливостей боротьби зі зловживаннями допоможуть нам подолати ці проблеми?
- МедіаВікі, програмна платформа та інтерфейси, які дозволяють Вікіпедії функціонувати, потребує протягом наступного десятиліття постійної підтримки, щоб забезпечити створення, модерацію, зберігання, пошук і споживання відкритого багатомовного вмісту в широких масштабах. Які рішення та вдосконалення платформи ми можемо зробити цього року, щоб забезпечити стабільність МедіаВікі?
Цілі
На цей момент опубліковано найвищий рівень планування — «Цілі».
Наступний рівень — «Ключові результати» (КР) для кожної фіналізованої цілі подається нижче.
«Гіпотези» для кожного КР також опубліковані нижче і будуть оновлюватися на вікісторінках відповідного проєкту/команди впродовж року, щоб оновлюватися в міру засвоєння уроків.
| Цілі для Вікідосвіду (WE) | ||||
|---|---|---|---|---|
| Ціль | Область цілі | Ціль | Контекст цілі | Власник |
| WE1 | Досвід дописувачів | Як досвідчені, так і нові дописувачі об'єднуються онлайн, щоб створювати варту довіри енциклопедію, з більшою легкістю і меншим незадоволенням. | Для того, щоб Вікіпедія залишалася динамічною в наступні роки, ми повинні робити роботу, яка б живила кілька поколінь волонтерів і робила дописування чимось таким, що люди хотіли б робити. Різні покоління волонтерів потребують різних інвестицій — більш досвідчені дописувачі потребують, щоб їхні потужні робочі процеси буди оптимізованими і справними, тоді як нові дописувачі потребують нових способів редагування, які мають сенс для них. І для цих поколінь всі дописувачі повинні мати можливість зв'язуватися і співпрацювати один з одним, щоб робити свою роботу найбільш ефективно. З цією метою ми будемо робити покращення критичних робочих процесів для досвідчених дописувачів, знижувати бар'єри для конструктивних внесків новачками і інвестуватимемо в те, щоб волонтери могли знаходити один одного і спілкуватися за спільними інтересами. | Marshall Miller |
| WE2 | Енциклопедичний вміст | Спільноти отримують підтримку для ефективного заповнення прогалин у знаннях за допомогою інструментів і систем підтримки, які легше отримати, адаптувати та вдосконалювати, забезпечуючи збільшення достовірного енциклопедичного вмісту. | Енциклопедичний вміст, насамперед у Вікіпедії, може бути збільшений і покращений завдяки постійній участі та інноваціям. Інструменти та ресурси (як технічні, так і нетехнічні), які доступні для використання дописувачами для своїх потреб, можна зробити більш явними та надійними. Ці інструменти повинні краще підтримуватися ФВМ через поліпшення їхніх функцій, що може бути досягнуто за короткі цикли. Зважаючи на останні тенденції щодо створення вмісту за допомогою штучного інтелекту та зміни поведінки користувачів, ми також дослідимо підґрунтя для суттєвих змін (наприклад, Вікіфункції), які можуть сприяти масштабному зростанню створення та повторного використання вмісту. Механізми виявлення прогалин у вмісті мають бути простішими для виявлення та планування. Ресурси, які підтримують зростання енциклопедичного вмісту, включно з вмістом у сестринських проєктах, таких як Бібліотека Вікіпедії, та кампаніях, можуть бути краще інтегровані з робочими процесами дописування. Водночас методи, що використовуються для зростання, повинні проти зростаючих загроз мати запобіжники, які можуть забезпечити постійну довіру до процесу, залишаючись вірними основним принципам енциклопедичного вмісту, визнаним у всіх проєктах Вікімедіа.
Аудиторія: редактори, перекладачі |
Runa Bhattacharjee |
| WE3 | Досвід споживачів (читання та медіа) | До Вікіпедії приходить нове покоління споживачів, щоб знайти найкраще місце для відкриття, залученості та побудови тривалого зв'язку з енциклопедичним вмістом. | Цілі:
Утримати існуючі та нові покоління споживачів і донорів. Підвищити актуальність для існуючих і нових поколінь споживачів, зробивши наш вміст простішим для пошуку та взаємодії. Працювати на різних платформах для адаптації нашого досвіду та існуючого вмісту, щоб енциклопедичний вміст міг досліджуватися та куруватися новим поколінням споживачів та донорів. |
Olga Vasileva |
| WE4 | Довіра і безпека | Покращувати нашу інфраструктуру, інструменти та процеси, щоб ми були добре оснащені для захисту спільнот, платформи та наших сервісних систем від різних видів масштабних і цілеспрямованих зловживань, зберігаючи при цьому відповідність регуляторному середовищу, що постійно змінюється. | Деякі аспекти наших можливостей боротьби зі зловживаннями потребують вдосконалення. Протидія зловживанням на основі IP-адрес стає все менш ефективною, деякі інструменти адміністрування потребують підвищення ефективності, і нам потрібно розробити єдину стратегію, яка допоможе нам боротися з масштабними зловживаннями, використовуючи в узгодженому поєднанні різні сигнали та механізми протидії (капчі, блокування тощо). Цього року ми почнемо працювати над розв'язанням найбільших проблем у цій сфері. Крім того, ці інвестиції в захист від зловживань повинні бути збалансовані з інвестиціями в розуміння і поліпшення стану спільноти, деякі аспекти якого включені в різні регуляторні вимоги | Suman Cherukuwada |
| WE5 | Платформа знань I (Еволюція платформи) | Розвивати платформу МедіаВікі та її інтерфейси, щоб краще відповідати основним потребам Вікіпедії. | МедіаВікі побудована для створення, модерації, зберігання, знаходження та споживання відкритого багатомовного вмісту в широких масштабах. У цей другий рік роботи Платформи знань ми подивимося на систему як куратор і почнемо працювати над вдосконаленням платформи, щоб ефективно підтримувати основні потреби проєктів Вікімедіа протягом наступного десятиліття, починаючи з Вікіпедії. Це включає продовження роботи над визначенням нашої платформи виробництва знань, посилення стійкості платформи, фокус на системі розширень/куків, щоб прояснити і впорядкувати розробку функцій, а також продовження інвестування в обмін знаннями і надання людям можливості робити внесок у МедіаВікі. | Birgit Müller |
| WE6 | Платформа знань II (Сервіси для розробників) | Технічний персонал і розробники-волонтери мають інструменти, необхідні для ефективної підтримки проєктів Вікімедіа. | Ми продовжимо розпочату роботу над покращенням (і масштабуванням) робочих процесів розробки, тестування та розгортання у Вікімедіа продакшн і розширимо визначення, включивши до нього послуги для розробників інструментів. Ми також прагнемо покращити нашу здатність відповідати на поширені запитання щодо робочих процесів та аудиторій розробників/інженерів, а також зробити відповідні дані доступними для прийняття поінформованих рішень. Частиною цієї роботи є розгляд практик (або їх відсутності), які наразі становлять виклик для нашої екосистеми. | Birgit Müller |
| Цілі для Сервісів сигналів і даних (ССД) | ||||
|---|---|---|---|---|
| Ціль | Область цілі | Ціль | Контекст цілі | Власник |
| SDS1 | Спільні погляди | Наші рішення про те, як підтримувати місію та рух Вікімедіа, ґрунтуються на метриках високого рівня та нових ідеях. | Для того, щоб ми могли ефективно та результативно розвивати технології, підтримувати волонтерів та відстоювати політику, яка захищає та розширює доступ до знань, нам потрібно розуміти екосистему Вікімедіа та узгоджувати свої погляди на те, як виглядає успіх. Це означає своєчасне відстеження загального набору показників, які є надійними, зрозумілими та доступними. Це також означає появу досліджень та ідей, які допоможуть нам зрозуміти, чому і як ми вимірюємо. | Kate Zimmerman |
| SDS2 | Платформа для експериментів | Менеджери продуктів можуть швидко, легко і впевнено оцінювати вплив функцій продукту. | Щоб уможливити та прискорити прийняття рішень про розробку функцій продукту на основі даних, менеджерам продуктів потрібна платформа для експериментів, за допомогою якої вони можуть визначати функції, обирати цільові аудиторії користувачів та бачити результати вимірювань впливу. Прискорення часу між запуском і аналізом є критично важливим, оскільки скорочення часу для навчання прискорить експерименти і, врешті решт, інновації. Ручні завдання та індивідуальні підходи до вимірювання були визначені як бар'єри на шляху до швидкості. Ідеальний сценарій полягає в тому, що менеджери продуктів можуть пройти шлях від запуску експерименту до виявлення результату з мінімальним ручним втручанням інженерів та аналітиків або взагалі без нього. | Tajh Taylor |
| Залучення Майбутніх цільових груп (МЦГ) | ||||
|---|---|---|---|---|
| Ціль | Область цілі | Ціль | Контекст цілі | Власник |
| FA1 | Перевірка гіпотез | Надати рекомендації щодо стратегічних інвестицій для Фонду Вікімедіа — на основі результатів експериментів, які поглиблюють наше розуміння того, як знання поширюються і споживаються в онлайні, — які допоможуть нашому руху служити новим аудиторіям в умовах мінливого Інтернету. | Через постійні зміни в технологіях і поведінці користувачів в онлайні (наприклад, зростаюча перевага отримання інформації через соціальні додатки, популярність короткометражних відеороликів, розвиток генеративного штучного інтелекту) рух Вікімедіа стикається з проблемами залучення й утримання читачів і дописувачів. Ці зміни також приносять можливості служити новим аудиторіям, створюючи й доставляючи інформацію новими способами. Однак ми, як рух, не маємо чіткої, заснованої на даних картини переваг і компромісів різних потенційних стратегій, які ми могли б застосувати для подолання викликів або використання нових можливостей. Наприклад, чи варто нам ...
Щоб Вікімедіа стала проєктом для багатьох поколінь, ми перевіримо гіпотези, щоб краще зрозуміти і порекомендувати перспективні стратегії — для Фонду Вікімедіа та руху Вікімедіа, — яких слід дотримуватися, щоб залучати й утримувати майбутні аудиторії. |
Maryana Pinchuk |
| Ціль для Продуктової та інженерної підтримки (ПІП) | ||||
|---|---|---|---|---|
| Ціль | Область цілі | Ціль | Контекст цілі | Власник |
| PES1 | Ефективність операцій | Зробити роботу Фонду швидшою, дешевшою та більш впливовою. | Працівники Фонду у своїй повсякденній роботі роблять багато для того, щоб наша діяльність була швидшою, дешевшою та більш впливовою. Ця ціль висвітлює конкретні ініціативи, які: а) дозволять досягти значних успіхів у напрямку підвищення швидкості, дешевизни та результативності; б) приведуть до скоординованих зусиль та зміни формальних і неформальних практик у Фонді. По суті, КР, включені до цієї цілі, є найскладнішими та найкращими поліпшеннями, які ми можемо зробити цього року для підвищення операційної ефективності роботи, що стосується наших продуктів і технології. | Amanda Bittaker |
Ключові результати
Тут для кожної фіналізованої цілі приведені «Ключові результати» (КР). Вони відповідають кожній з цілей, наведених вище.
«Гіпотези», щодо уточнюють кожне з планованих досягнень, у міру накопичення досвіду, будуть публікуватись нижче на цій сторінці та оновлюватися на вікісторінках відповідного проєкту або команди.
| Ключових результати Вікідосвіду (ВД)
[ Цілі ] | |||
|---|---|---|---|
| Скорочення ключового результату | Текст ключового результату | Контекст ключового результату | Власник |
| WE1.1 | Розробити або вдосконалити один робочий процес, який допомагає дописувачам зі спільними інтересами зв'язуватися один з одним і робити спільні внески. | Ми вважаємо, що простори спільнот і взаємодія у вікі роблять людей задоволенішими і, як дописувачів, продуктивнішими. Крім того, простори спільнот допомагають залучати і наставляти новачків, моделюють найкращі практики дописувачів і допомагають заповнювати прогалини в знаннях. Однак існуючі ресурси, інструменти та простори, які підтримують людський зв'язок у вікі, є неякісними і сьогодні не відповідають викликам і потребам більшості редакторів. Тим часом робота команди Кампаній продемонструвала, що багато організаторів прагнуть впроваджувати та експериментувати з новими інструментами зі структурованими робочими процесами, які допомагають їм у роботі зі спільнотою. З цих причин ми хочемо зосередитися на заохоченні та просуванні почуття приналежності серед дописувачів вікі. | Ilana Fried |
| WE1.2 | Конструктивна активізація: Широке застосування дій, які в підсумку покажуть зростання відсотка новачків порівняно з попереднім роком, які опублікували ≥1 конструктивне редагування на 25% в основному просторі та на 10% на мобільних пристроях, згідно з показниками контрольних експериментів.
Примітка: цей КР буде вимірюватись по кожній з платформ. |
Поточний досвід повноекранного редагування для багатьох новачків, щоб робити конструктивний внесок, вимагає занадто багато контексту, терпіння та спроб і помилок. Щоб підтримати нове покоління волонтерів, ми збільшимо кількість і доступність менших, структурованих і більш орієнтованих на конкретні завдання робочих процесів редагування (наприклад, Перевірка редагування і Структуровані завдання).
Примітка: Базові показники будуть встановлені лише наприкінці 4 кварталу поточного фінансового року, після чого буде встановлено наш цільовий відсотковий показник КР. |
Peter Pelberg |
| WE1.3 | Підвищити задоволення користувачів від кожного з 4-х модераційних інструментів на 5 пунктів. | Редактори з розширеними правами використовують широкий спектр наявних функцій, розширень, інструментів та скриптів для виконання завдань модерації у проєктах Вікімедіа. Цього року ми хочемо зосередитися на вдосконаленні цього інструментарію, а не на проєктах зі створення нової функціональності у цій сфері. Ми плануємо протягом року взятися до низки продуктів і хочемо внести значні вдосконалення до кожного з них. Таким чином ми сподіваємося покращити досвід модерації вмісту в цілому.
Ми визначимо напрямні для поширених інструментів модерування, які будуть охоплені цією програмою, щоб визначити збільшення задоволення від роботи з кожним інструментом. Список побажань спільноти матиме істотний вплив на вибір пріоритетів для цього КР. |
Sam Walton |
| WE2.1 | До кінця 2-го кварталу організатори, дописувачі та установи отримають 3 практичні і суттєві підстави для збільшення наповнення в ключових тематичних галузях, як ґендер (жіноче здоров'я, біографії жінок) та географія (біорозмаїття). | Цей КР стосується покращення висвітлення окремих тем, щоб зменшити наявні прогалини у знаннях. Ми встановили, що спільноти отримують користь від ефективних інструментів у поєднанні з кампаніями, спрямованими на підвищення якості вмісту в наших проєктах. Цього року ми хочемо зосередитися на вдосконаленні наявних інструментів та експериментуванні з новими способами вибору пріоритетності ключових тем, щоб подолати прогалини в знаннях. | Purity Waigi & Fiona Romeo |
| WE2.2 | До кінця 2-го кварталу впровадити та протестувати дві рекомендації, як соціальні, так і технічні, для підтримки мовної адаптації малих мовних спільнот, з оцінкою для аналізу відгуків спільноти. | Існують версії Вікіпедії приблизно 300 мовами. І все ж є набагато більше мов, якими розмовляють мільйони людей, якими немає Вікіпедії та взагалі Вікісайтів. Це перешкода на шляху до реалізації нашого бачення: щоб кожна людина могла вільно створювати інформацію і знання, обмінюватися ними і мати доступ до суми всіх знань. Інкубатор Вікімедіа — це місце, де потенційні вікіпроєкти Вікімедіа у нових мовних версіях можуть бути організовані, написані, протестовані й доведені до того, що вони гідні бути розміщеними на ресурсах Фонду Вікімедіа. Інкубатор був започаткований у 2006 році з припущенням, що його користувачі матимуть попередні знання з редагування вікі. Ця проблема загострюється тим, що цей процес здебільшого мають виконувати люди, які є найновішими і найменш досвідченими в нашому русі. Хоча редагування у вікіпроєктах Вікімедіа з того часу значно покращилося, Інкубатор не отримував цих оновлень через технічні обмеження. Наразі випуск вікі з Інкубатора займає кілька тижнів, а щороку створюється лише близько 12 вікі, що свідчить про значне вузьке місце.
Наявні дослідження та матеріали свідчать про технічні проблеми на кожному етапі впровадження мови: додавання нових мов до Інкубатора, складнощі в розробці та перевірці вмісту, а також повільний процес створення вікісайту після того, як мова вийде з Інкубатора. Кожна фаза є повільною, ручною та складною, що вказує на необхідність вдосконалення. Розв'язання цієї проблеми дозволить створювати вікі новими мовами швидше і простіше, а також дасть змогу більшій кількості людей ділитися знаннями. Різні зацікавлені сторони, наявні дослідження та ресурси виявили запропоновані рекомендації як соціального, так і технічного характеру. Цей ключовий результат пропонує протестувати дві рекомендації, як соціальні, так і технічні, та оцінити відгуки спільноти. |
Satdeep Gill & Mary Munyoki |
| WE2.3 | На кінець другого кварталу дві нові функції допомагають дописувачам додавати джерельні матеріали, які відповідають настановам проєкту, а 3-5 партнерів надали джерельні матеріали, які заповнюють мовні та географічні прогалини. | Щоб розширювати доступ до якісних джерельних матеріалів, необхідних для заповнення стратегічних прогалин у вмісті, ми будемо:
|
Fiona Romeo & Alexandra Ugolnikova |
| WE2.4 | До кінця другого кварталу увімкнути виклик Вікіфункцій на test2wiki, щоб забезпечити більш масштабований спосіб додавання нового вмісту. | Щоб ефективно зменшити наші прогалини в знаннях, нам потрібно вдосконалити робочі процеси, які підтримують масштабоване зростання якісного вмісту, особливо в менших мовних спільнотах. | Amy Tsay |
| WE2.5 | До кінця четвертого кварталу сприяти організаторам, учасникам та інституціям задля збільшення охоплення якісного контенту в ключових тематичних галузях, як-от ґендер (жіноче здоров'я, біографії жінок) та географія (біорозмаїття) на 138 статей протягом експерименту. | Як пряме продовження WE2.1, цей КР стосується покращення висвітлення окремих тем, щоб зменшити наявні прогалини у знаннях. Ми встановили, що спільноти отримують користь від ефективних інструментів у поєднанні з кампаніями, спрямованими на підвищення якості вмісту в наших проєктах. Цього року ми хочемо зосередитися на вдосконаленні наявних інструментів та експериментуванні з новими способами вибору пріоритетності ключових тем, щоб подолати прогалини в знаннях. | Purity Waigi & Satdeep Gill |
| WE3.1 | Створити два куровані, доступні та керовані спільнотою досвіди перегляду та навчання у репрезентативних вікі з метою збільшення на 5% утримання читачів, що вийшли з системи, серед користувачів, які отримали досвід. | Цей КР фокусується на збільшенні утримання нового покоління читачів на нашому сайті, дозволяючи новому поколінню побудувати тривалий зв'язок з Вікіпедією, досліджуючи можливості для читачів легше відкривати й вивчати вміст, який їх цікавить. Це включатиме дослідження та розробку нових курованих, персоналізованих і керованих спільнотою можливостей для перегляду та навчання (наприклад, стрічки з відповідним вмістом, рекомендації та пропозиції щодо тематичного вмісту, можливості для вивчення вмісту, куровані спільнотою тощо).
Ми плануємо розпочати фінансовий рік із серії експериментів з досвіду перегляду вебсторінок, щоб визначити, які з них ми хотіли б масштабувати для робочого використання і на якій платформі (веб, застосунки, або і те й інше). Потім ми зосередимося на масштабуванні цих експериментів і перевірці їхньої ефективності в підвищенні утримання користувачів у робочих середовищах. Наша мета до кінця року - запустити принаймні два експерименти на репрезентативних вікі й точно виміряти 5% збільшення утримання читачів, які беруть участь у цих експериментах. Щоб оптимально ефективно досягти цього КР, нам знадобиться можливість «A/B» тестування з користувачами, які вийшли з системи, а також інструменти, здатні вимірювати утримання читачів. Нам також можуть знадобитися нові API або сервіси, необхідні для представлення рекомендацій та інших механізмів кураторства. |
Olga Vasileva |
| WE3.2 | Збільшити на 50% на кожну платформу кількість пожертв через контактні точки, окрім щорічних банерів та звернень через електронну пошту. | Наша мета — забезпечити різноманітність джерел надходжень, визнаючи при цьому наших наявних донорів. Спираючись на відгуки та дані, ми зосереджуємось на збільшенні кількості пожертв поза межами методів, на які Фонд покладався в минулому, зокрема, щорічних банерних закликів. Ми хочемо показати, що, інвестуючи в більш інтегрований донорський досвід, ми можемо підтримувати нашу роботу і розширювати наш вплив, надаючи альтернативу донорам і потенційним донорам, які не реагують на банерні заклики. 50% — це початкова оцінка, що базується на зменшенні видимості кнопки «Пожертвувати» в Інтернеті внаслідок впровадження Вектора 2022, а також на збільшенні кількості пожертв завдяки пілотному проєкту 2023-2024 фінансового року в застосунках Вікіпедії, спрямованому на покращення досвіду донорів (збільшення кількості пожертв на 50,1%). Оцінка цієї метрики за платформами допоможе нам зрозуміти тенденції на платформах і те, чи слід застосовувати різні тактики в майбутньому, виходячи з різниці в поведінці залежно від аудиторії платформи. | Jazmin Tanner |
| WE3.3 | До кінця другого кварталу 2024-25 волонтери розпочнуть конвертувати старі графіки в нові графічні розширення при створенні статей Вікіпедії. | Графічні розширення було відключено з міркувань безпеки з квітня 2023 року, і читачі не змогли побачити багатьох діаграм, у які члени спільноти вклали час і енергію протягом останніх 10 років.
Візуалізація даних відіграє важливу роль у створенні привабливого енциклопедичного контенту, тому в 2024-25 фінансовому році ми побудуємо нову безпечну послугу, яка замінить розширення Graph, і яка буде обробляти більшість простих випадків візуалізації даних у статтях Вікіпедії. Цей новий інструмент передбачатиме можливість розширеного варіанту для підтримки більш складних випадків використання, якщо ФВМ або розробники спільноти вирішать це зробити в майбутньому. Ми дізнаємося, що досягли успіху, коли члени спільноти успішно конвертують старі графіки і опублікують нові графіки за допомогою нового інструменту. Ми визначимо, яку бібліотеку візуалізації вихідних даних використовувати і які типи графіків підтримувати на початковому етапі проєкту. |
Christopher Ciufo |
| WE3.4 | Розробити модель можливостей для поліпшення продуктивності вебсайту за допомогою розміщення кешу сайтів у меншому масштабі, що займе один місяць для реалізації, зберігаючи технічні можливості, безпеку та приватність. |
Команда трафіку відповідає за підтримання мережі надання контенту (МНК). Цей шар зберігає часто доступний контент, сторінки і т.ін. в пам'яті і на диску. Це зменшує час, потрібний для обробки запитів користувачів. Другий частина - це зберігання контенту ближче до користувача в фізичному сенсі. Це зменшує час, необхідний, щоб дані досягли користувача (запізнення). Минулого року ми включили один сайт в Бразилії, який мав на меті скоротити затримку в Південноамериканському регіоні. Було б чудово постворювати нові центри обробки даних, але це дорого в грошах, у часі і в кількості роботи - наприклад, минулорічна робота тривала цілий рік. Ми хотіли б мати центри в Африці та Південно-Східній Азії, і було б чудово мати їх по всьому світу. Наша гіпотеза полягає в тому, щоб розгорнути невеликі центри в інших місцях по всьому світу, де є менший трафік. Для цього потрібно було б менше серверів, не більше чотирьох або п'яти. Це знижує наші витрати. Це все ще допоможе нам зменшити затримку для користувачів у цих регіонах, але буде меншим за часом і зусиллями на їх підтримку. |
Kwaku Ofori |
| WE3.5 | До кінця третього кварталу 2024-25 зацікавлені волонтери з будь-якої Вікіпедії можуть створити графіки, а робоча група успішно передає обслуговування групі Reader Experiences. |
Розширення Chart знаходиться в режимі виробництва і введене для обраного списку пілотних вікі (itwiki, svwiki, hewiki). Мета пілоту - заздалегідь виявити помилки і проблеми з використанням, перш ніж розширити масштаби розгортання на більше число вікі. До мандату проєкту входить надання оновленої версії розширення графів на всіх вікі, і треба ще постаратись, щоб це зробити можливим. Ця робоча група також є тимчасовою, тобто обслуговування та будь-яка майбутня розробка функцій мають бути передані після завершення проекту. |
Chris Ciufo |
| WE4.1 | До кінця четвертого кварталу надати пропозицію щодо трьох контрзаходів проти переслідувань і шкідливого вмісту на основі даних і відповідно до змін у регуляторному середовищі, що розвивається. | Забезпечення безпеки та гаразду користувачів є основним обов'язком онлайн-платформ. У багатьох юрисдикціях діють закони та нормативні акти, які вимагають від онлайн-платформ вживати заходів проти домагань, кібербулінгу та іншого шкідливого вмісту. Невиконання цих вимог може призвести до юридичної відповідальності платформи та регуляторних санкцій.
Наразі ми не дуже добре уявляємо собі, наскільки великими є ці проблеми або причини, що їх породжують. Ми значною мірою покладаємося на окремі свідчення та ручні процеси, що залишає нас вразливими як до юридичних ризиків, так і до інших далекосяжних наслідків: недооцінки проблеми, ескалації шкоди, репутаційних збитків та підриву довіри користувачів. Нам потрібно створити сильну культуру вимірювання частоти випадків домагань і шкідливого вмісту та проактивно впроваджувати контрзаходи. |
Madalina Ana |
| WE4.2 | До кінця третього кварталу розробити щонайменше два сигнали для використання в робочих процесах протидії зловживанням, щоб підвищити точність дій щодо зловмисників. | Вікі значною мірою покладаються на блокування IP-адрес як на механізм блокування вандалізму, спаму та зловживань. Але IP-адреси стають все менш корисними як стабільні ідентифікатори окремих учасників, а блокування IP-адрес має непередбачувані негативні наслідки для добросовісних користувачів, які випадково мають одну IP-адресу зі зловмисниками. Поєднання зниження стабільності IP-адрес і нашої значної залежності від блокування IP-адрес призводить до зниження точності та ефективності націлювання на зловмисників, а також до зростання рівня супутньої шкоди для добросовісних користувачів. Ми хочемо бачити протилежну ситуацію: зниження рівня супутньої шкоди та підвищення точності заходів, спрямованих на зловмисників.
Щоб краще підтримати роботу функціонерів у боротьбі зі зловживаннями та надати будівельні блоки для повторного використання в наявних (наприклад, CheckUser, Special:Block) і нових інструментах, в цьому КР ми пропонуємо дослідити способи надійно пов'язати особу з її діями (нівелювання використання кількох облікових записів), а також об'єднати наявні сигнали (наприклад, IP-адреси, історію облікових записів, атрибути запитів), щоб забезпечити більш точне націлювання дій на зловмисників. |
Kosta Harlan |
| WE4.3 | Зменшити ефективність великомасштабної розподіленої атаки на 50%, що вимірюється часом, необхідним для адаптації наших заходів, та обсягом трафіку, який ми можемо витримати при симулюванні. | Еволюція ландшафту Інтернету, включаючи зростання масштабних бот-мереж і почастішання атак, зробила наші традиційні методи обмеження масштабних зловживань застарілими. Такі атаки можуть зробити наші сайти недоступними, переповнивши нашу інфраструктуру запитами, або перевантажити здатність нашої спільноти боротися з масштабним вандалізмом. Це також створює невиправдане навантаження на наших редакторів з високими привілеями та технічну спільноту.
Нам терміново потрібно покращити нашу здатність автоматично виявляти, протистояти і нівелювати або зупиняти такі атаки. Для того, щоб виміряти наші покращення, ми не можемо покладатися виключно на частоту/інтенсивність реальних атак, оскільки ми будемо залежати від зовнішніх дій, і нам буде важко отримати чітку кількісну картину нашого прогресу. Налаштувавши кілька симульованих атак різної природи/складності/тривалості, які можна безпечно запустити проти нашої інфраструктури, і запускаючи їх щоквартально, ми зможемо як тестувати наші нові контрзаходи, не бувши атакованими, так і об'єктивно звітувати про наші вдосконалення. |
Giuseppe Lavagetto |
| WE4.4 | Запустити тимчасові облікові записи на 100% всіх вікі. | Тимчасові обліківки є рішенням для виконання різних нормативних вимог щодо експозиції IP на нашій платформі на різних поверхнях. Ця робота включає в себе оновлення багатьох продуктів, ліній даних, функціональних інструментів та різних добровільних робочих процесів для вирішення існування додаткових облікових записів. | Madalina Ana |
| WE5.1 | До кінця третього кварталу завершити щонайменше 5 втручань, спрямованих на підвищення життєздатності платформи. | Стійкість платформи МедіаВікі — це постійна робота, важлива для нашої здатності масштабувати, підвищувати або уникати погіршення задоволеності розробників і розвивати нашу технічну спільноту. Це важко виміряти і залежить від технічних та соціальних факторів. Однак ми володіємо неявними знаннями про конкретні сфери вдосконалення, які є стратегічно важливими для стійкості. Заплановані втручання можуть допомогти підвищити стійкість і зручність супроводу платформи або уникнути її деградації. Ми плануємо оцінити вплив цієї роботи в четвертому кварталі та надати рекомендації щодо подальшого досягнення цілей стійкості. Приклади заходів зі стійкості: спрощення складних областей коду, які є основними для МедіаВікі, але лише кілька людей знають, як вони працюють; збільшення використання інструментів для аналізу коду, щоб інформувати про якість нашої кодової бази; оптимізація таких процесів, як формування пакетів та випуски версій. | Mateus Santos |
| WE5.2 | Визначити до кінця другого кварталу і завершити до кінця четвертого кварталу одне або кілька втручань для розвитку програмних інтерфейсів екосистеми МедіаВікі, щоб надати можливість відокремленої, простішої і стійкішої розробки функцій. | Основна мета КР 5.2 — покращити та прояснити взаємодію між основною платформою МедіаВікі та її розширеннями, оформленнями та іншими частинами. Ми прагнемо забезпечити функціональні покращення архітектури МедіаВікі, які уможливлять практичну модульність та зручність супроводу, що полегшить розробку розширень, а також розширить можливості для виконання вимог ширшого бачення продукту МедіаВікі. Ця робота також має на меті проінформувати, що має бути (чи не бути) в ядрі, розширеннях чи інтерфейсах між ними. Рік буде розділений на дві фази: 5-місячна фаза досліджень та експериментів, яка дасть інформацію для другої фази, де будуть реалізовані конкретні втручання. | Jonathan Tweed |
| WE5.3 | До кінця другого кварталу завершити одну ініціативу зі збору даних та один експеримент з покращення продуктивності, щоб інформувати про подальші втручання щодо продукту та платформи для використання можливостей, розблокованих завдяки моделюванню сторінки у МедіаВікі як композиції структурованих фрагментів. | Основна мета полягає в тому, щоб дати можливість розробникам і менеджерам продуктів використовувати нові можливості платформи МедіаВікі для задоволення поточних і майбутніх потреб в енциклопедичному вмісті, уможливлюючи нові пропозиції продуктів, які наразі важко реалізувати, а також підвищити продуктивність і стійкість платформи.
Зокрема, на рівні платформи МедіаВікі ми хочемо змінити модель обробки МедіаВікі, яка не розглядає сторінку як монолітну одиницю, а розглядає її як композицію структурованих одиниць вмісту. Парсоїдні перегляди прочитаного, інтеграція Вікіданих та інтеграція Вікіфункцій у вікі — все це неявні кроки до цього. В рамках цього КР ми хочемо більш цілеспрямовано експериментувати з цими новими можливостями і збирати дані для майбутніх втручань на основі цих нових можливостей, щоб гарантувати, що ми зможемо досягти запланованого впливу на інфраструктуру і продукт. |
Subramanya Sastry |
| WE5.4 | Виконати випуск MediaWiki з новим процесом, який синхронізується з оновленнями PHP в четвертому кварталі. | Платформа програмного забезпечення MediaWiki спирається на регулярні оновлення наступної версії PHP, щоб залишатися безпечною і стабільною, що є проблемним моментом у нашому процесі і важливою для модернізації нашої інфраструктури. У той же час ми регулярно випускаємо нові версії програмного забезпечення MediaWiki, від яких, зокрема, залежить translatewiki.net, платформа, яка використовується для перекладу програмних повідомлень для проектів Вікімедіа. Синхронізуючи PHP-оновлення з процесом випуску, ми не залишаємося позаду на давніших версіях PHP. Це покращить обслуговування та безпеку платформи MediaWiki та досвіду розробників. | Mateus Santos |
| WE6.1 | Вирішити 5 питань для забезпечення ефективності та прийняття обґрунтованих рішень щодо робочих процесів і послуг розробників та інженерів, а також зробити відповідні дані доступними до кінця четвертого кварталу. | «Це складно» — часта відповідь на питання на кшталт «які сховища використовуються у виробництві Вікімедіа». У цьому КР ми розглянемо деякі з наших «вічнозелених» питань у сфері інженерної продуктивності та досвіду — повторювані питання, які здаються простими, але на які важко відповісти; питання, на які ми можемо відповісти, але дані недоступні і потребують спеціальних запитів від експертів у певній галузі; питання, на які важко отримати відповідь через прогалини у процесах або з інших причин. Ми визначимо, що означає «вирішити» для кожного з цих питань: для деяких це може означати просто зробити доступними наявні точні дані. Інші питання потребуватимуть більше часу на дослідження та інженерні розробки для їх вирішення. Основна мета цієї роботи — скоротити час, обхідні шляхи і зусилля, необхідні для отримання інформації про ключові аспекти досвіду розробників, і дозволити нам поліпшити робочі процеси і послуги для інженерів і розробників. | [TBD] |
| WE6.2 | До кінця четвертого кварталу вдосконалити теперішній проєкт і провести щонайменше два експерименти, спрямовані на створення зручних у супроводі цільових середовищ, що наближають нас до безпечної, напівбезперервної підтримки функціонування. | Розробники і користувачі покладаються на бета-кластер Вікімедіа (бета), щоб виловлювати помилки до того, як вони вплинуть на користувачів у їхній діяльності. З часом використання бета-версій розширилося і вступило в конфлікт — вони надто різноманітні, щоб вміститися в одному середовищі. Ми покращимо одне з наявних альтернативних середовищ і проведемо експерименти, спрямовані на заміну однієї високопріоритетної потреби в тестуванні, яку наразі задовольняє бета-кластер, на підтримуване альтернативне середовище, яке краще відповідає потребам кожного варіанту використання. | Tyler Cipriani |
| WE6.3 | Розробити рамки оцінки стабільності Toolforge у третьому кварталі. Використати його для поліпшення принаймні одного критичного аспекту платформи в четвертому кварталі і інформувати більш довгострокову стратегію. | Toolforge, ключова платформа для інструментів Вікімедіа, створених волонтерами, відіграє вирішальну роль — від редагування до захисту від вандалізму. Наша мета — покращити зручність використання Toolforge, знизити бар'єри для внеску, покращити практики спільноти та сприяти дотриманню встановлених політик. Для цього до кінця другого кварталу ми запровадимо систему балів для оцінки стійкості платформи Toolforge, зосередившись на технічних і соціальних аспектах. Використовуючи цю систему як орієнтир, ми прагнемо покращити один з ключових технічних факторів на 50%. | Slavina Stefanova |
| Ключові результати щодо сигнальних служб та збереження даних (SDS)
[ Цілі ] | |||
|---|---|---|---|
| Скорочення ключового результату | Текст ключового результату | Контекст ключового результату | Власник |
| SDS1.1 | До кінця третього кварталу 2 програми або ініціативи, спрямовані на КР, оцінили прямий вплив їхньої роботи на один або кілька основних показників. | Наші основні організаційні показники слугують основою для оцінки прогресу Фонду в досягненні його цілей. Коли ми розподіляємо ресурси на програми та розробляємо робочі потоки, орієнтовані на ключові результати (КР), ці показники високого рівня мають визначати, як ми пов'язуємо ці інвестиції з основними цілями Фонду, визначеними в річному плані.
Робота над цим ключовим результатом підтверджує, що Фонд в цілому перебуває на ранній стадії своєї здатності кількісно пов'язувати вплив усіх запланованих втручань із високорівневими або основними показниками. Для досягнення цієї кінцевої мети цей КР спрямований на розробку процесу, за допомогою якого ми ділимося логічними та теоретичними зв'язками між нашими ініціативами та нашими показниками високого рівня. На практиці це означає співпрацю з власниками ініціатив у всьому Фонді, щоб зрозуміти, як результати їхньої роботи на рівні проєкту пов’язані з нашими основними показниками на рівні Фонду та впливають на них. В даний час Фонд перебуває на ранній стадії своєї мети, щоб бути здатним виконувати програми або інструментальні ініціативи і пов'язувати вплив цих заходів на показники рівня основ Фонду. Для досягнення цієї мети цей КР має на меті зробити наступне: визначити принаймні дві програми-кандидати або ініціативи, спрямовані на продукт, розробити стратегію оцінки щоб виміряти основні метричні наслідки та виконати цю стратегію оцінювання. Починаючи з двох ініціатив, ми швидко зрозуміємо виклики проведення аналізів, які дозволять пов'язати вплив нашої роботи на осяжні зміни в наших основних показниках. Висновки з цього КР будуть втілюватись у більш широку стратегію застосування цієї методики вимірювання до більш широкого кола і кількості ініціатив Фонду. |
Omari Sefu |
| SDS1.2 | Дати відповідь на три стратегічні відкриті дослідницькі питання до грудня 2024 року, щоб надати рекомендації або інформацію для річного планування на 26 фінансовий рік. | В екосистемі Вікімедіа є багато відкритих дослідницьких питань, і відповіді на деякі з них мають стратегічне значення для ФВМ чи афілітатів. Відповіді на ці питання можуть допомогти у майбутньому розвитку продукту чи технології або підтримати прийняття рішень чи адвокацію у політичному просторі. Хоча на деякі з цих питань можна відповісти, використовуючи суто дослідницький або дослідницько-інженерний досвід, з огляду на соціально-технічну природу проєктів Вікімедіа, отримання достовірної інформації часто вимагає міжкомандної співпраці для збору даних, створення вмісту, взаємодії з користувачами, ретельного планування експериментів тощо. За допомогою цього КР ми прагнемо визначити пріоритетність деяких наших ресурсів для відповіді на одне або кілька таких питань.
Робота в рамках цього КР включає визначення пріоритетності списку стратегічних відкритих питань, а також проведення експериментальної роботи для пошуку відповіді на X (наразі оцінюється в 2) з них. Ідеальним типом питань, які ми розглядаємо в цьому КР, є питання, відповідь на які може мати ефект розблокування, дозволяючи багатьом іншим командам або групам працювати (краще? поінформованіше) над продуктом, технологією або політикою. Ми маємо намір, щоб робота в цьому КР доповнювала такі КР:
|
Leila Zia |
| SDS1.3 | Досягти щонайменше 50% скорочення середнього часу, необхідного зацікавленим сторонам у сфері даних для розуміння та відстеження потоків даних для трьох основних та важливих показників. | Необхідно для дотримання стандартів Врядування даними.
Відстеження трансформації та джерел наборів даних є складним і вимагає знання різних сховищ і систем. Ми повинні спростити розуміння того, як потоки даних рухаються в наших системах, щоб зацікавлені у сфері даних сторони могли працювати в режимі самообслуговування. Ця робота підтримуватиме робочі процеси, де дані трансформуються і використовуються для аналітики, функцій, API і завдань з якості даних. Буде продовжена робота над КР щодо документування показників. |
Luke Bowmaker |
| SDS2.1 | До кінця другого кварталу ми зможемо підтримувати одну продуктову команду для оцінки функції або продукту за допомогою базового A/B тестування, що скоротить час на отримання даних про взаємодію з користувачем на 50%. | Ми вважаємо, що використання спільних інструментів підвищить впевненість продуктових команд у прийнятті рішень на основі даних, підвищить ефективність та продуктивність, а також покращить продуктову стратегію та інновації.
Створення UX та технічних систем для зареєстрованих користувачів дозволяє нам рухатися вперед до довгострокової мети підтримки тестів A/B на розлогінених користувачах, поки ведеться робота над реалізацією SDS 2.3. Ми розглянемо прийняття індивідуального часу команди до базових ліній даних взаємодії користувачів і поліпшити його на 50%. Ми також дослідимо, як можна контекстуалізувати ці досягнення в ширшому контексті всіх продуктових команд. Ми сподіваємося дізнатися, як ми можемо покращити сприйняття та визначити пріоритети для покращення можливостей на основі відгуків від команди впровадження та результатів SDS 2.2. |
Virginia Poundstone |
| SDS2.2 | До кінця другого кварталу ми матимемо три основні метрики для аналізу експериментів (A/B-тести) для підтримки перевірки гіпотез щодо продукту/функцій, пов'язаних з КР 2024-2025 фінансового року. | Коли менеджер продукту (або проєктувальник) має гіпотези, що продукт/функція розв'яже проблему/потребу користувачів або організації, то експеримент — це спосіб перевірити ці гіпотези і дізнатися про потенційний вплив їхньої ідеї на показник. Результати експерименту надають інформацію менеджеру продукту і допомагають йому прийняти рішення про те, що робити далі (відмовитися від цієї ідеї і спробувати інші гіпотези, продовжити розробку, якщо експеримент був проведений на початку життєвого циклу розробки, або випустити продукт/функцію для більшої кількості користувачів). Менеджери продукту повинні бути здатними приймати таке рішення з упевненістю, спираючись на докази, яким вони довіряють і які вони розуміють.
Основною перешкодою на цьому шляху є те, що продуктові команди наразі формулюють свої гіпотези за допомогою спеціальних показників для конкретних проєктів, які потребують спеціальної аналітичної підтримки для їх визначення, вимірювання, аналізу та звітування про них. Перехід на набір основних метрик для формулювання всіх гіпотез щодо продукту/функції, які можна перевірити, зробить це:
Ми думаємо, що набір основних метрик, які широко зрозумілі і послідовно використовуються — і які засновані і є під впливом стандартних галузевих метрик — також покращить організаційну грамотність щодо даних і сприятиме культурі оцінювання, експериментування і навчання. Ми зосереджуємося на основних метриках, які: (1) необхідні для найкращого вимірювання та оцінки успіху/впливу продуктів/функцій, пов'язаних з двома ключовими критеріями Вікідосвіду – WE3.1 і WE1.2; (2) відображають або зіставляються зі стандартними галузевими метриками, що використовуються у вебаналітиці. |
Mikhail Popov |
| SDS2.3 | Запровадити унікальний механізм відстеження агентів у нашій CDN, який дозволяє тестування функцій продукту A/B з анонімними читачами. | Без такого механізму відстеження не є розумним проводити тестування A/B характеристик продукту з анонімними читачами.
Це, загалом, результат, що базується на етапі створення нової технічної можливості, на якій інші зможуть побудувати вимірювані речі. Ключовим пріоритетним прикладом використання буде тестування функцій A/B з анонімними читачами, але ця робота також дозволить зробити інші важливі майбутні речі, які можуть створити наступні гіпотези пізніше в WE4.x (для рейтингу ризику запитів і зменшення масштабних атак) та для метрики/дослідження щодо розрахунку унікальних пристроїв, наскільки це дозволять їхнє забезпечення ресурсами і пріоритети. |
Brandon Black |
| Ключові результати Майбутніх цільових груп (МЦГ)
[ Цілі ] | |||
|---|---|---|---|
| Скорочення ключового результату | Текст ключового результату | Контекст ключового результату | Власник |
| FA1.1 | Завдяки експериментальним висновкам та рекомендаціям щодо Майбутніх цільових груп, до кінця третього кварталу у проєкті річного плану на наступний рік буде присутня принаймні одна ціль або ключовий результат, що належить команді, яка не є учасницею Майбутніх цільових груп. | З 2020 року Фонд Вікімедіа відстежує зовнішні тенденції, які можуть вплинути на нашу здатність служити майбутнім поколінням споживачів і дописувачів знань і залишатися квітучим рухом вільних знань для наступних поколінь. Майбутні цільові групи, невелика команда дослідників, будуть:
|
Maryana Pinchuk |
| Ключові результати Продуктової та інженерної підтримки (ПІП)
[ Цілі ] | |||
|---|---|---|---|
| Скорочення ключового результату | Текст ключового результату | Контекст ключового результату | Власник |
| PES1.1 | Культура оцінювання: в рамках щоквартального опитування поступово покращувати оцінки настрою персоналу відділів Продукту і Технології, що стосується наших результатів, напрямків, лідерства та стану команди. | Культура оцінювання — це культура розробки продукту, що базується на коротших циклах ітерацій, навчання та адаптації. Це означає, що наша організація може встановлювати річні цілі, але те, що ми робимо для досягнення цих цілей, буде змінюватися і адаптуватися протягом року в міру того, як ми вчимося. Побудова культури оцінювання має два компоненти: процеси та поведінка. Цей КР фокусується на останній. Зміни в поведінці можуть розвивати і зміцнювати нашу культуру оцінювання. Це передбачає зміни в індивідуальних звичках і традиціях, коли ми переходимо до більш ітеративної розробки продукту. Цей КР базуватиметься на змінах в індивідуальній поведінці згідно з самозвітами, а також на вимірюванні змін у настроях персоналу, якщо такі є. | Amy Tsay |
| PES1.2 | На кінець другого кварталу новий Список побажань краще пов'язує ідеї та запити руху з діяльністю Фонду в сфері Продукту і Технології: пункти зі Списку побажань вирішуються через КР 2024-2025 років, Фонд виконав 10 менших побажань, і Фонд у партнерстві з волонтерами визначив три чи більше областей можливостей на 2025-2026 фінансовий рік. | Список побажань спільноти представляє вузький зріз руху; у ньому беруть участь приблизно 1 тис. людей, більшість з яких є дописувачами або адміністраторами. Люди часто оминають Список побажань, пишучи запити щодо функцій та повідомлення про помилки через Phabricator, де важко відрізнити — чи запити від ФВМ, чи від спільноти. Для учасників Cписок побажань — це дорога інвестиція часу з мінімальними наслідками. Вони все ще беруть участь у Cписку побажань, тому що вважають, що це єдиний спосіб привернути увагу до важливих помилок і поліпшення функцій, або сигналізувати про потребу в ширших, стратегічних можливостях. Побажання часто описують як рішення, а не як проблеми. Рішення можуть здаватися розумними на папері, але не обов'язково враховують технічну складність або наслідки для стратегії руху.
Масштаб і обсяг побажань іноді перевищує повноваження і можливості Технічної спільноти або окремої команди, множачи розчарування, що призводить до запитів на коментар і закликів ліквідувати Список побажань. У той час як члени спільноти вважають за краще використовувати Список побажань для проєктних ідей, команди Фонду дивляться на Список побажань та інші процеси приймання заявок для визначення пріоритетів, частково через те, що побажання не встигають до річного планування і їх важко включити в дорожні карти / Цілі і ключові результати. Майбутній Список побажань має стати мостом між спільнотою та Фондом, де спільноти надаватимуть інформацію в структурованому вигляді, щоб ми могли вжити заходів і, своєю чергою, задовольнити волонтерів. Ми створюємо новий процес приймання заявок, щоб кожен зареєстрований волонтер міг подати побажання будь-якого дня року. Побажання можуть містити повідомлення про помилку, запит на покращення або ідею щодо нової функції. Будь-хто може прокоментувати побажання, взяти участь у семінарі або підтримати його, щоб вплинути на визначення пріоритетів. Фонд не класифікуватиме побажання як «завеликі» або «надто незначні». Побажання, які тематично стосуються ширшої проблемної сфери, можуть впливати на річне планування та дорожні карти команд, пропонуючи стратегічні напрямки та можливості. Побажання будуть видимими для Руху на інформаційній панелі, яка класифікує побажання за проєктами, продуктами/проблемними галузями та типами побажань. Фонд своєчасно реагуватиме на побажання та співпрацюватиме зі Спільнотою, щоб класифікувати та визначити пріоритетність побажань. Ми співпрацюватимемо з вікімедійцями, щоб визначити та встановити як пріоритет три сфери покращення, включені до Річного плану Фонду на 2025-2026 роки, що має покращити рівень прийняття та виконання побажань, що мають вплив. Ми позначатимемо чітко сформульовані побажання для спільноти волонтерів-розробників та команд Фонду, що сприятиме більшій залученості команд та розробників, а також більшій кількості виконаних побажань, що сприятиме задоволенню спільноти. Виконання більшої кількості побажань підвищує задоволеність дописувачів, їхню ефективність та зменшує плинність, що має призвести до якісніших редагувань, якіснішого вмісту та більшої кількості читачів. |
Jack Wheeler |
| PES1.3 | Провести і завершити два експерименти з наявними дослідницькими продуктами/функціями, які нададуть нам дані/інформацію про те, як ми розвиваємо Вікіпедію як джерело знань для нашої поточної аудиторії користувачів і волонтерів у першому і другому кварталах. До кінця третього кварталу завершити та поділитися отриманими знаннями та рекомендаціями для потенційного застосування у майбутній роботі ЦКР у кошику Вікідосвід. | Ця робота є відповідником цілі «Майбутні цільові групи», але натомість зосереджена на виявленні можливостей збільшити та поглибити залучення наших наявних цільових груп (користувачів та дописувачів Вікіпедії) шляхом більш вправного тестування більшої кількості ідей щодо продуктів на платформі.
Він знаходиться в PES1, оскільки є енерджайзером і мультиплікатором — переспрямовує час, який окремі особи й команди вже присвятили хакерству/експериментуванню над побічними проєктами, на те, щоб зосередитися на більш перспективних функціях. Замість того, щоб ці побічні проєкти довго і повільно тягнулися (не найкраще використання наших обмежених ресурсів), цей КР забезпечує шлях для деяких з цих ідей, які потенційно можуть потрапити до більшого середовища APP за допомогою перевірених експериментів, таким чином більш ефективно використовуючи час персоналу і мотивуючи їхню творчість і продуктивність. Беручи в роботу більшу кількість таких менших і коротших проєктів, ми також урізноманітнюємо наші «ставки» для отримання більшої кількості знань та випробування ідей, які можуть трансформувати Вікіпедію відповідно до мінливих потреб та очікувань нашої нинішньої аудиторії. Це зробить нашу роботу ефективнішою та швидшою, оскільки допоможе Фонду зосередитися на правильній меті за менший проміжок часу. |
Rita Ho |
| PES1.4 | Дізнатися, як формулювати, виконувати і контролювати рішення щодо ЦРО (Цілей рівня обслуговування). Вибрати принаймні одну нову річ, для якої, коли ми її випускаємо, потрібно визначити ЦРО. Співпрацювати з відповідною командою/командами (зазвичай: продуктовою, командою розробників, інжинірингу надійності сайту), щоб визначити ці ЦРО. Обміркувати і задокументувати настанови щодо того, які випуски повинні мати ЦРО в майбутньому і як їх встановлювати. | МАЙБУТНІЙ КР:
Налагодити процес та елементарні інструменти для встановлення та моніторингу ЦРО для нових релізів. Звітувати щоквартально і використовувати його, щоб вирішувати, коли варто (і не варто) визначати пріоритетність роботи, щоб щось виправити. Поділиться звітом зі спільнотою. НАВІЩО: Ми не знаємо, коли нам потрібно визначати пріоритетність робіт, щоб щось виправити. І у нас багато коду. Оскільки цей обсяг продовжує зростати, з'являється все більше ситуацій, коли нам слід вирішувати, чи займатись проблемами, чи зосередитися на інноваціях, і все більше невизначеності щодо того, коли ми повинні це робити. Крім того, персоналу і спільноті незрозуміло, який наш рівень підтримки/зобов'язань щодо надійності та продуктивності для всіх різних функцій і можливостей, з якими вони взаємодіють. Якщо ми визначимо очікуваний рівень обслуговування, ми зможемо знати, коли нам слід виділяти на нього ресурси, а коли ні. |
Mark Bergsma |
| PES1.5 | Визначити власність і зобов'язання (включаючи СЛО) щодо послуг і дізнатися, як відстежувати, звітувати і приймати рішення як стандартну та придатну до масштабування практику, випробувавши її у 3 командах серед старших лідерів у відділі. | Після спільного визначення SLO для функції EditCheck в рамках PES1.5 ми тепер спробуємо і навчимося використовувати SLO на практиці для сприяння вибору пріоритетів роботи над стійкістю. Ми також задокументуємо ролі та відповідальність за власність коду/служб, що дозволить нам чітко визначити спільні зобов'язання щодо рівня постійної підтримки. Ми спробуємо використовувати їх як практики у 3 командах по всьому відділу. | Mark Bergsma |
Гіпотези
Подальші гіпотези є конкретними речами, які ми робимо щокварталу, щоб досягти пов'язаних ключових результатів, зазначених вище.
Кожна гіпотеза - це експеримент або етап експерименту, який, на нашу думку, допоможе досягти ключового результату. Команди розробляють гіпотезу, перевіряють її, потім уточнюють свої висновки або розробляють зовсім іншу нову гіпотезу. Гіпотезу можна сприймати як припущення команди для перевірки протягом даного часу. Команди роблять малі припущення на кілька тижнів або великі припущення на кілька місяців, але з урахуванням ризиків результат повинен бути пропорційним часу, який команда в нього вкладає. Наші гіпотези мають бути гнучкими і швидко адаптуватися. Ми можемо відкинути, використати або почати нову гіпотезу в будь-який момент кварталу.
Щоб побачити найбільш актуалізований стан гіпотези і/або обговорити гіпотезу з командою, будь ласка, натисніть посилання на сторінку проєкту нижче.
Перший квартал
Перший квартал (Q1) річного плану ФВМ охоплює липень-вересень.
| Гіпотези Вікідосвіду (ВД) | ||
|---|---|---|
| Акронім гіпотези | Q1 текст | Деталі і обговорення |
| WE1.1.1 | Якщо розширити Список подій до Спільнотного списку включно з Вікіпроєктами, нам вдасться зібрати деякі перші враження щодо того, як застосувати Вікіпроєкти для розвитку продукту. | |
| WE1.1.2 | Якщо ми визначимо щонайменше 15 Вікіпроєктів у 3-х окремих Вікіпедіях, щоб включити їх у Спільнотні списки, то ми зможемо дати поради групі Продукту Кампанії щодо ключових характеристик, необхідних для створення MVP Спільнотного списку, який включає Вікіпроєкти. | |
| WE1.1.3 | Якщо ми порадимось із 20-ма організаторами заходів і 20-ма організаторами Вікіпроєктів про найкраще використання тем, доступних через LiftWing, то ми можемо встановити пріоритети змін до тематичної моделі, яка покращить актуальні зв'язки між подіями і Вікіпроєктами. | |
| WE1.2.1 | Якщо ми створимо першу версію Edit Check API і використаємо її для впровадження нового інструменту перевірки, ми зможемо оцінити швидкість і простоту, з якою інші команди та волонтери можуть використовувати API для створення нового інструменту перевірки і підказки редагувань. | |
| WE1.2.2 | Якщо ми побудуємо бібліотеку компонентів інтерфейсу користувача та візуальних артефактів, досвід користувача інструменту Edit Check можна буде поширити на адаптацію алгоритмів Structured Tasks. | |
| WE1.2.3 | Якщо ми проведемо користувацькі тестування на двох або більше прототипах дизайну з запровадженням структурованих завдань для нових користувачів у рамках Візуального редактора чи близьких до нього, ми можемо швидко дізнатися, які елементи будуть працювати найкраще для нових редакторів, а також дозволити інженерам оцінити технічну виправданість і оцінити зусилля для кожного варіанту. | mw:Growth/Constructive activation experimentation |
| WE1.2.4 | Якщо ми навчимо LLM виявляти "поведінку павича" (намагання привернути увагу), після чого переконаємось, чи може він виявити це порушення політики з не менше ніж 70% точністю і більш ніж 50% скасувань і, в кінцевому підсумку, вирішити, чи є цей LLM достатньо ефективним, щоб забезпечити новий Edit Check і/або Suggested Edit. | |
| WE1.2.5 | Якщо ми проведемо тест A/B/C з прототипом альт-тексту підказки редагування у робочій версії додатку iOS, ми зможемо дізнатися, чи додавання тексту підписів до зображень є завданням, з яким новачки успішно справляються, і в кінцевому підсумку, вирішити, чи ця дія є настільки важливою, щоб реалізувати її у вигляді підказки редагування в мережі та/або в додатках. | mw:Wikimedia Apps/iOS Suggested edits project/Alt Text Experiment |
| WE1.3.1 | Якщо ми запустимо додаткове налаштування поведінки Automoderator і внесемо зміни на основі відгуків пілотного проекту у Q1, більше модераторів будуть задоволені його набором функцій і надійністю, і вирішать використовувати його на своєму проєкті Вікімедіа, тим самим збільшуючи прийняття продукту. | mw:Automoderator |
| WE1.3.2 | Якщо ми зможемо інтерпретувати категорії побажань як фокусну зону, пов'язану з модератором, і поділитися цими фокусними зонами для внеску спільнот у Q1-Q2, відтак ми отримаємо високу ступінь впевненості в тому, що наша обрана фокусна зона покращить задоволення модератора, коли вона буде випущена в Q3. | |
| WE2.1.1 | Якщо ми побудуємо модель висновку на рівні країни для статей Вікіпедії, ми зможемо фільтрувати списки статей до тих, що стосуються конкретного регіону з точністю більше 70% і відкликання більше 50%. | m:Research:Language-Agnostic Topic Classification/Countries |
| WE2.1.2 | Якщо ми побудуємо доказ концепції, що надає пропозиції щодо перекладу, які базуються на тематичних сферах, вибраних користувачами, ми будемо готові успішно протестувати, чи знайдуть перекладачі більше можливостей зробити переклади в своїх сферах зацікавлень і чи робитимуть більший внесок порівняно з загальними пропозиціями, наявними на даний момент. | mw: Translation suggestions: Topic-based & Community-defined lists |
| WE2.1.3 | Якщо ми пропонуємо створення списку як послугу, ми сприятимемо принаймні 5 спільнотам зробити більш цільові внески до своїх тематичних сфер, що вимірюється шляхом (1) зміни стандартного якісного покриття відповідних тем у відповідній вікі і (2) короткого опитування щодо задоволення організатора покриттям тематичної сфери на вікі. | |
| WE2.1.4 | Якщо ми розробили доказ концепції, який додає завдання перекладу, отримані з Вікіпроєктів та інших ініціатив створення списку, і представимо їх як пропозиції в рамках мобільного робочого потоку CX, то більше редакторів виявили б і перекладали статті, яких саме бракує у вікіпедії. Запровадивши варіант, який дозволяє редакторам вибирати пропозиції перекладу на основі тематичних списків, ми перевіряли б, чи цей підхід збільшує охоплення контенту в наших проєктах. | mw:Translation suggestions: Topic-based & Community-defined lists |
| WE2.2.1 | Якщо ми розширимо дані про стан мов Вікімедіа шляхом забезпечення домовленостей про обмін даними з ЮНЕСКО та Ethnologue, принаймні один партнер вирішить представити прогрес у включенні мов Вікімідії в своїх власних продуктах даних та комунікаціях. Крім того, що це корисно для наших організацій-партнерів, наш розширеній набір даних забезпечить важливу контекстну інформацію для прийняття рішень і надасть спільнотам інформацію, необхідну для визначення критичних сфер для втручання. | |
| WE2.2.2 | Якщо ми закартуємо діяльність у сфері документування мов, яку ведуть Вікімедійці за останні 2 роки, ми розробимо інформативну базу даних для досвіду спільноти щодо залучення нових мов. | |
| WE2.2.3 | Якщо ми надамо доступ до 5 нових мов, з Інкубатором або без нього, ми дізнаємося, чи доступ до повноцінної вікі з сучасними функціями, такими як на англійській Вікіпедії (включаючи підтримку ContentTranslation і Wikidata, розвинені інструменти редагувань та пошуку), сприятиме швидшому редагуванню. У кінцевому підсумку, це допоможе нам дізнатися, чи може цей підхід стати життєздатним напрямком для започаткування нових мовних розділів на основі нових або існуючих мов, виправдовуючи або ні подальші дослідження. | mw:Future of Language Incubation |
| WE2.3.1 | Якщо ми зробимо два подальші поліпшення потоку завантаження медіа на Вікісховище і поділимось ними зі спільнотою, відгуки будуть позитивними і це допоможе завантажувачам зробити менше невдалих завантажень (з огляду на авторські права), виміряні співвідношенням запитів на вилучення протягом 30 днів після завантаження. Це включатиме визначення дизайнів для подальших поліпшень UX на етапі вибору ліцензії при завантаженні на Вікісховище та запровадження MVP виявлення логотипів у ході завантаження. | |
| WE2.4.1 | Якщо ми побудуємо прототип запитів Вікіфункцій, вбудованих у вміст Медіавікі, ми будемо готові використовувати асинхронний процес обробки контенту Медіавікі і перевірити, наскільки ефективно він справляється, у другому кварталі. | phab:T261472 |
| WE2.4.2 | Якщо ми створимо прототип дизайну початкового випадку використання Вікіфункцій у Вікіпедії, ми будемо готові побудувати та перевірити нашу інтеграцію, і реалізація продуктивності буде перевірена у другому кварталі (див. гіпотезу 1). | phab:T363391 |
| WE2.4.3 | Якщо ми дозволимо користувачам Вікіфункцій отримати доступ до лексикографічних даних Вікіданих, вони розпочнуть створювати функції натуральної мови, які генеруватимуть фрази розмовної мови, включно з такими, що зможуть обробляти нестандартні форми. Якщо ми побачимо середній щомісячний рівень створення до 31 цих функцій, після того, як програма стане доступною, ми отримаємо підтвердження успішності нашого експерименту. | phab:T282926 |
| WE3.1.1 | Розробка і якісна оцінка трьох доказів концепції, спрямованих на створення курованих, персоналізованих та спільнотних навичок перегляду та навчання дозволить нам оцінити потенціал для збільшення повторного звернення читачів (експеримент 1: надання рекомендованого контенту в контексті пошуку та теми статті, експеримент 2: скорочення і спрощення змісту статті, експеримент 3: спрощення виконання розгалужених завдань на різних вікі). | |
| WE3.1.3 | Якщо ми розробимо моделі переробки змісту, наприклад, спрощення змісту або резюмування, яке можна буде розмістити і обслуговувати через нашу інфраструктуру (наприклад, LiftWing), ми створимо технічну організацію роботи, спрямовану на підвищення повторного звернення читачів за допомогою нових функцій отримання інформації. | |
| WE3.1.4 | Якщо ми аналізуємо прогнозований вплив на продуктивність гіпотез WE3.1.1 і WE3.1.2 на API пошуку, ми можемо визначити і вирішити проблеми з продуктивністю і масштабуванням, перш ніж вони негативно вплинуть на наших користувачів. | |
| WE3.1.5 | Якщо ми покращимо поле пошуку в додатку Android, щоб рекомендувати персоналізований контент на основі інтересів користувача і краще відобразити результати, ми дізнаємося, чи це покращує залучення користувачів, спостерігаючи, чи збільшує це показник враження і клікабельність (CTR) результатів пошуку на 5% у експериментальній групі порівняно з контрольною групою протягом 30-денного тесту A/B. Це поліпшення може потенційно призвести до збільшення на 1% повторного звернення незареєстрованих користувачів. | phab:T370117 |
| WE3.2.1 | Якщо ми створимо клікабельний прототип дизайну, який демонструє концепцію значка, що представляє донорів, зацікавлених у певних тематичних статтях, ми можемо дізнатися, чи буде прийнято спільнотою робочу версію цього методу для збору коштів у додатках. | Fundraising Experiment in the iOS App |
| WE3.2.2 | Збільшення виразності закликів до пожертв на незареєстрованих користувачів веб-мобільних та настільних пристроїв збільшить клікабельність посилання на пожертви на 30% рік за роком. | phab:T368765 |
| WE3.2.3 | Якщо зробити кнопку "Зробити пожертву" в iOS-версії більш виразною, наблизивши її на один клік або менше від головного навігаційного екрану, ми дізнаємося, чи пошукова простота була перешкодою для небанерних пожертв. | |
| WE3.3.1 | Якщо ми виберемо бібліотеку візуалізації даних і отримаємо початкову версію нової серверно-рендерної графічної служби доступної до кінця липня, ми зможемо дізнатися від волонтерів на Вікіманії, чи працюємо ми над рішенням, яке б вони використали для заміни старих графів. | |
| WE4.1.1 | Якщо ми впровадимо спосіб, яким користувачі можуть повідомляти про потенційні випадки переслідування та шкідливого контенту, наведеного в дискусіях, через систему звітності про інциденти, ми зможемо збирати дані про кількість і тип повідомлених інцидентів і, таким чином, краще зрозуміти контекст і дії, яких нам потрібно вжити. | |
| WE4.2.1 | Якщо ми вивчимо і визначимо методи, які стосуються Вікімедіа для унікальної ідентифікації пристроїв, ми зможемо визначити механізми збору та зберігання, які ми можемо пізніше реалізувати в наших робочих потоках проти зловживання, щоб забезпечити більш цільове блокування недобросовісних користувачів. | phab:T368388 |
| WE4.2.9 | Якщо ми надамо контекстуальну інформацію про репутацію, пов'язану з IP, щодо якого є намір блокуванння, ми завдамо менше супутньої шкоди через блокування пов'язаних IP і IP-діапазонів, тому що адміністратори матимуть більше уявлення про потенційну шкоду блокування для супутніх IP. Ми можемо виміряти це, використовуючи інструмент Special:Block і спостерігаючи, як змінюється поведінка, коли є додаткова інформація, і коли її немає. | WE4.2.9 Talk page |
| WE4.2.2 | Якщо ми визначимо алгоритм розрахунку рейтингу репутації користувача для використання в заходах протидії зловживанням, ми підготуємо основу для розробки заходів з використанням цього рейтингу як додаткового сигналу для адміністраторів, які вираховують ініціаторів шкідливих дій на нашій платформі. Ми знаємо, що гіпотеза є успішною, якщо алгоритм для розрахунку бальної оцінки з точністю X% для категорій існуючих облікових записів, наприклад, "низький" бал повинен застосовуватися до X% постійно заблокованих облікових записів. | WE4.2.2 Talk page |
| WE4.2.3 | Якщо ми побудуємо базу оцінювання, використовуючи доступні для публіки технології, подібні до тих, які використовувалися в попередніх атаках, ми дізнаємося більше про ефективність нашої нинішньої CAPTCHA при блокуванні атак і зможемо рекомендувати заміну CAPTCHA, яка приносить вимірюване поліпшення з точки зору зменшення рівня атак, досягнутого порівняно з витратами часу і фінансів. | |
| WE4.3.1 | Якщо ми застосуємо деякі інструменти машинного навчання та аналізу даних до журналів веб-запитів під час відомих атак, ми зможемо ідентифікувати неналежні IP-адреси з не менш ніж 80% точністю, звідки надходить переважно шкідливий трафік, який ми можемо потім скоротити, обмеживши найбільш виразний його край, тим самим покращуючи надійність для наших користувачів. | phab:T368389 |
| WE4.3.2 | Якщо ми обмежимо потік повторних атак з відомих нам IP-адрес, обмеживши інформацію, яку вони можуть розмістити на нашій інфраструктурі, ми зменшимо кількість ефективних перевантажувальних атак на 20%, покращуючи надійність для наших користувачів. | |
| WE4.3.3 | Якщо ми отримаємо докази концепції балансувальника навантаження 'Liberica', ми отримаємо вимір 33% поліпшення нашої спроможності в справі обробки потоків TCP SYN. | |
| WE4.3.4 | Якщо ми зробимо поліпшення в використанні і також виконаємо деякі тренувальні вправи на нашому інструменті 'requestctl', то SREs повідомлять про більшу впевненість у використанні інструменту. | phab:T369480 |
| WE4.4.1 | Якщо ми запустимо принаймні 2 цикли розгортання тимчасових рахунків, ми зможемо перевірити, чи це працює успішно. | |
| WE5.1.1 | Якщо ми успішно розгорнемо Parsoid Read Views на всіх Вікімандрах до першого кварталу, це підвищить нашу впевненість у розширенні Parsoid Reading Views на всі Вікіпедії. Ми вимірюємо успіх цього запуску шляхом детальних оцінок за допомогою звітів Confidence Framework, з особливим акцентом на звітах Visual Diff та показниках, пов'язаних з продуктивністю та зручністю використання. Крім того, ми оцінимо зменшення списку потенційних блокаторів, забезпечивши вирішення критичних питань до поширення Parsoid Read Views. | |
| WE5.1.2 | Якщо ми відключимо невикористану метрику Graphite, зосередимось на міграції з використанням db-префіксованої фабрики даних і збільшимо наші зусилля щодо поширення інформації до інших команд і спільноти в першому кварталі, то ми будемо на шляху до досягнення нашої мети зробити Graphite у режимі тільки для читання до третього кварталу 2015 року, спостерігаючи збільшення прогресу міграції на 30%. | |
| WE5.1.3 | Якщо ми реалізуємо канонічну структуру URL з налагодженням версії для нашого REST API, то ми можемо дозволити міграцію послуг і тестування для кінцевих точок Parsoid і аналогічних послуг у першому кварталі. | phab:T344944 |
| WE5.1.4 | Якщо ми завершимо решту роботи з метою зменшення впливу заходів анти-тракінгу переглядачів на автологін CentralAuth та перейдемо до більш стійкої інфраструктури автентифікації (SUL3), ми будемо готові розпочати продуктивні вікі у другому кварталі. | |
| 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. | Simplify feature development |
| 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. | Simplify feature development |
| 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. | завдання 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 ] | ||
|---|---|---|
| Акронім гіпотези | Q1 текст | Деталі і обговорення |
| 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 conversation and/or affect the technical implementation itself. | |
| Future Audiences (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Акронім гіпотези | Q1 текст | Деталі і обговорення |
| 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 ] | ||
|---|---|---|
| Акронім гіпотези | Q1 текст | Деталі і обговорення |
| 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. | 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. | 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. | 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. | Rabbit Holes |
| WE3.1.7 | If we run a qualitative experiment focused on presenting article summaries to web readers, we will determine whether or not article summaries have the potential to increase reader retention, as proxied by clickthrough rate and usage patterns | |
| WE3.1.8 | If we build one feature which provides additional article-level recommendations, we will see an increase in clickthrough rate of 10% over existing recommendation options and a significant increase in external referrals for users who actively interact with the new feature. | |
| WE3.2.2 | Increasing the prominence of entry points to donations on the logged-out experiences of the Vector web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY. | mw:Readers/2024 Reader and Donor Experiences |
| WE3.2.3 | If we make the “Donate” button in the iOS App more prominent by making it one click or less away from the main navigation screen, we will learn if discoverability was a barrier to non banner donations. | Navigation Refresh |
| WE3.2.4 | If we update the contributions page for logged-in users in the app to include an active badge for someone that is an app donor and display an inactive state with a prompt to donate for someone that decided not to donate in app, we will learn if this recognition is of value to current donors and encourages behavior of donating for prospective donors, informing if it is worth expanding on the concept of donor badges or abandoning it. | Private Donor Recognition Experiment |
| WE3.2.5 | If we create a Wikipedia in Review experiment in the Wikipedia app, to allow users to see and share personalized data about their reading, editing, and donation habits, we will see 2% of viewers donate on iOS as a result of this feature, 5% click share and, 65% of users rating the feature neutral or satisfactory. | Personalized Wikipedia Year in Review |
| WE3.2.7 | Increasing the prominence of entry points to donations on the logged-out experiences of the Minerva web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY. | |
| WE3.3.2 | If we develop the Charts MVP and get it working end-to-end in production test wikis, at least two Wikipedias + Commons agree to pilot it before the code freeze in December. | |
| WE3.4.1 | If we were to explore the feasibility by doing an experiment of setting up smaller PoPs in cloud providers like Amazon, we can expand our data center map and reach more users around the world, at reduced cost and increased turn-around time. | |
| WE4.1.2 | If we deploy at least one iteration of the Incident Reporting System MVP on pilot wikis, we will be able to gather valuable data around the frequency and type of incidents being reported. | 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. | 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 ] | ||
|---|---|---|
| Акронім гіпотези | Q2 text | Деталі і обговорення |
| 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. | завдання 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 conversation and/or affect the technical implementation itself. | |
| Future Audiences (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Акронім гіпотези | Q2 text | Деталі і обговорення |
| 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 ] | ||
|---|---|---|
| Акронім гіпотези | Q1 текст | Деталі і обговорення |
| 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 | |
Q3
The third quarter (Q3) of the WMF annual plan covers January-March.
| Wiki Experiences (WE) Hypotheses
[ WE Key Results ] | ||
|---|---|---|
| Акронім гіпотези | Q3 text | Деталі і обговорення |
| 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.5 | If we implement at least 2 methods to discover the Collaboration List, then we will increase pageviews of the Collaboration List, thereby allowing more people to discover events and WikiProjects that interest them | |
| WE1.1.6 | If we identify and then contact 20 affiliates and/or groups connected to wikis that have high organizer activity in Q2, we can build advocacy networks that will set the stage for the extension being enabled on 3 more wikis by the end of Q3. | |
| WE1.1.7 | If we add at least 2 improvements to the Collaboration List for events, then at least 50% of surveyed respondents will find the Collaboration List to be more useful in finding events than before the changes were made. | |
| 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.7 | If we deploy the Multi-Check sidebar (desktop) at all wikis where the Reference Check is available, we will unlock our ability to present multiple Edit Checks within a new "mid-edit" moment without negatively impacting the quality of new content edits newcomers publish. | |
| WE1.2.9 | If we surface the ‘Add a Link’ Structured Task to new account holders who are reading Wikipedia articles through an A/B test on pilot wikis, then we expect to increase the percentage of these people who constructively activate on mobile by 10% compared to the control group. | |
| WE1.2.10 | If the Structured Content team improves the code health of the Article-level Image Suggestions data pipeline to meet 90% of code deduplication, article and section level image suggestion separation on the index level; and adapt the image suggestion evaluation tool to be able to get baselines for quality of suggestions for target wikis, then the “Add an Image” task can be released to newcomers on additional Wikipedias. This will enable the Growth team to pursue a follow-up hypothesis focused on increasing constructive activation across at least 10 additional Wikipedias. | |
| WE1.2.11 | If we release the “Add a Link” Structured Task to at least 5% percent of newcomers on English Wikipedia, then newcomers with access to this structured task will demonstrate a constructive activation rate on mobile that is 10% percent higher than the baseline, as measured through an A/B test. | |
| 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. | |
| WE1.3.4 | If we improve the user experience and features of Recent Changes, we will increase administrator satisfaction of the product by 5pp. | |
| WE1.5.1 | If we create a strategy brief by February 2025, including a prioritized strategy and trade-offs, we can use it as one of the main inputs for APP25/26. | |
| WE1.5.2 | If we develop a unified measurement strategy, we will enable evaluation of the multi-year product strategy for contributors and set the landscape for prioritization of next steps in metric development and reporting | |
| 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.1.6 | 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.7 | "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.2.4 | If we document the pre-incubator, incubator, and post-incubator journeys for the five pilot wikis with quantitative and qualitative data, we will be able to better support new languages in the future. | |
| WE2.4.4 | If we develop a live proof-of-concept, using MediaWiki’s async content processing pipeline, for the first use case of Wikifunctions in Wikipedia, we will be ready to switch it on in the new year for the Dagbani community. | |
| WE2.6.1 | If we propagate the integration of Wikifunctions from Test2Wiki to a small production Wikipedia with the MVP user experience, we will see the feature used organically without being reverted. | |
| WE2.6.2 | If we make it possible to translate sentences in Wikifunctions from something “abstract” like a function, we will see an organic increase of at least 5 multilingual functions that generate natural language sentences. This is a milestone towards building an Abstract Wikipedia. | |
| 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.8 | (Q2-Q3, web) 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.1.9 | If we create a daily-use Wikipedia-based trivia game in the Android app, logged-out readers who engage with this feature will open the app on multiple days within a 20-day period at a rate at least 5% higher than those who do not engage with the feature. | |
| WE3.1.10 | If we develop and test design prototypes for tabbed browsing in the Wikipedia iOS app, we will gain and incorporate actionable insights on usability, while also enabling engineers to assess technical feasibility of different approaches, building a solid foundation for adding Tabs to the app in Q4. | |
| WE3.1.11 | If we make the article search bar more prominent, we will increase the number of users who initiate searches by 8%, possibly leading to a 1% increase in search retention rate for logged out users. | |
| 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.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. | |
| 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.2.8 | If we make improvements to the personalised and collective content of the iOS apps’ Year in Review, and scale its availability, we will learn if this is an effective fundraising method. | |
| 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. | |
| WE3.5.1 | If we make it possible for Commons Data namespace pages to be categorized and surface their usage across wikis, Commons admins will have the minimum tools they need to manage the increased usage of the Data namespace, ensuring we can sustainably scale up deployment to all wikis | |
| WE3.5.2 | If we improve test coverage and documentation for Charts, we will be comfortable handing off maintenance and future feature development [to reading engineering, contractors, and volunteers], allowing us to wind down the project and task force. | |
| WE3.5.3 | If we seed the Community Wishlist with Charts features we know volunteers have asked for that are out of scope for the MVP, there will be a central place for volunteers and staff to discuss future Charts-related work, allowing the future maintainers to manage expectations and source input for annual planning | |
| WE4.1.3 | If we deploy the Incident Reporting System MVP to x more wikis (representative sample) we will be able to gather valuable data that will help us identify patterns of harmful conduct across wikis | |
| WE4.1.4 | If we engage stakeholders across key departments in structured discussions, we can collaboratively define a shared vision and realistic scope for the Incident Reporting System, aligned with organizational priorities and compliance requirements, providing valuable insights to inform annual planning. | |
| WE4.2.11a | If we define a terminology and thresholds for revert risk scores across wikis, we will make it possible to use revert risk scores in a wider range of user facing anti-abuse tools. This hypothesis impacts the WE4.2 KR by doing the background work necessary to build upon revert risk scores. | |
| WE4.2.20 | Implement a trial enablement which will gather data on the efficacy of the new CAPTCHA on enabled wikis at preventing sockpupppet account creation and bot-based spam edits to measure the efficacy and value of a production rollout of the new technology | |
| WE4.2.15 | If we analyze attributes of blocked user accounts on multiple wikis, we will identify patterns across these accounts and assign weights based on the relative importance of each attribute on block rates to use in calculating a user account reputation score. The success of this hypothesis would be measured by whether we are successful in defining a formula for multiplying attributes of an account to provide an account reputation score that maps to blocked users. | |
| WE4.2.10 | If we add two more data points to the client hints collection pipeline, we will have more entropy to better identify sockpuppets and potential ban evasion. We will know we are successful when we are able to use the client hints data to identify X% of confirmed sock puppets on en:Wikipedia:Sockpuppet investigations. Or when we are able to use the collected data to identify Y% of suspected ban invasion pair. This hypothesis directly contributes to the KR by providing new signals (browser canvas fingerprint, list of fonts) that will allow CheckUsers to more precisely target sockpuppets and accounts attempting to evade bans. | |
| WE4.2.14b | "If we introduce IP reputation data variables in AbuseFilter variables, we will enable mitigations that can reduce the amount of submissions of vandalism, spam and abuse. Context:This directly contributes to the KR goal by introducing a new signal (IP reputation) to allow for more precision in mitigations (only actions matching the variable are impacted). We could measure the impact of this hypothesis by examining the volume of reverted edits on wikis before/after the variables are introduced. (Other ideas?) We would initially introduce variables like “is likely a VPN” or “is likely a proxy”. We could also consider exposing other variables, depending on discussions in T354599: Make IP reputation available as a variable in AbuseFilter." |
|
| WE4.2.14a | If we analyze IP reputation data associated with problematic editing activity and user accounts, we will be able to prioritize a set of IP reputation facets that can be provided as variables in AbuseFilter. This analysis would then be used by WE4.2.14b later Q3 to build out the variables in AbuseFilter, along with specific guidance about what mitigations would be reasonable to use alongside a given set of IP reputation variables. For example, the recommended mitigation for one IP reputation variable might be to block edits outright, while the recommended mitigation for a different IP reputation variable might be to tag the edit for further review, or to show a CAPTCHA. | |
| WE4.2.18a | If we design and build a clickable component to display public data related to user account reputation to functionaries, we will be able to learn if this is useful to them by observing the number of repeat usages of the tool | |
| WE4.3.3b | 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 | |
| WE 4.3.6b | 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. | |
| WE 4.3.8 | If we deploy the liberica load balancers to all datacenters, we will increase the capacity to handle TCP SYN floods by 33% everywhere | |
| WE 4.3.9 | If we establish and follow a verified procedure for the regular testing of large-scale abuse scenarios, then we will consistently measure and improve our ability to respond effectively to such incidents. | |
| WE 4.3.10 | If we define a policy for review and maintenance of requestctl rules, we will keep the system understandable and manageable over time | |
| WE 4.3.11 | If we can identify patterns and separate web scrapping from general traffic, we will be able to create reporting systematically to reduce the traffic and maintain sustainability of our serving infrastructure. | |
| WE 4.4.3 | If we improve the interface of the iOS app, we will be able to clearly communicate how temporary accounts work to users as they edit without logging in, and the iOS app will be prepared for the imminent release of temporary accounts to all projects. | |
| WE 4.4.4 | If we update the data models in the data lake, and the corresponding data pipelines and dashboards, to accurately represent the new user account types, we'll be able to provide accurate analytics reporting related to activities of corresponding user types. | |
| WE 4.4.5 | If we resolve all remaining product, design and legal blockers for the engineering work that needs to be done before the major pilots deployment, we will be able to complete the engineering work on time for the next round of pilot deployment. | |
| WE5.1.9 | If we enable Parsoid on Incubator and all newly created Wikis by Q2, we’ll further ensure sustainability by not allowing the number of wikis that run on the legacy parser to grow. 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.11 | The Observability team aims to sunset graphite by enabling read-only mode and disabling new metric ingest by the end of Q3 FY2024/2025. To achieve this goal, the team has set a 90% coverage target of converting the remaining dashboard and retiring legacy metrics and panels that point to graphite metrics. | |
| WE5.1.12 | If we release an interactive documentation sandbox for MediaWiki REST APIs, it will introduce a repeatable pattern for low maintenance, high quality API documentation while making the APIs easier to adopt for developers around the world. This will ensure that our API documentation is fully up to date, testable, and localized for generations of developers, while reducing the maintenance cost and increasing sustainability for API publishers. | |
| WE5.1.13 | If we roll out SUL3 for all existing accounts and new account creation across all wikis, we will ensure compatibility with browser anti-tracking measures and improve security, by moving authentication to a dedicated domain that requires user interaction and further prevents XSS vulnerabilities. | |
| WE5.2.5 | If we model at least one more page state change (e.g. PageDelete) as a PHP event and drive further adoption of in-process domain events across MediaWiki components and extensions currently utilizing event-like hooks, then we will build confidence in events as a platform sustainability pattern by improving component boundaries, improving interface flexibility, and reducing high risk boilerplate code. | |
| WE5.2.6 | If we explore designing an architecture for serializing and broadcasting events generated within MediaWiki core, we will create a foundation for offering first class event support that will enable us to consume events outside of the originating MediaWiki PHP process (e.g. JobQueue, EventBus). This will make MediaWiki data more reusable beyond the MediaWiki platform. | |
| WE5.2.7 | If we identify and align on a set of domains that can be used for MediaWiki platform events by the end of Q3, we will have an initial map of core component boundaries and can improve consistency across MediaWiki interfaces by utilizing the same domains for the MediaWiki REST API modules. | |
| WE5.2.8 | If we clearly define the concept of extension interfaces in the MediaWiki documentation, we can make it easier to develop new functionality on top of MediaWiki and provide a clearer path for defining new extension interfaces, such as Domain Events. We will measure this by identifying places in the documentation where extension interfaces are presented as “extension types” and replacing 100% of those instances. | |
| WE5.4.3 | If we enable developers with PHP8.1 MediaWiki images and infrastructure for testing them on Kubernetes, they will be able to validate and certify them to be deployed to production. If we also develop infrastructure for progressive traffic migration and use it to safely migrate production to 8.1, this helps MediaWiki drop unsupported PHP versions in the upcoming May release. Success will be observed by the ability to ramp up production traffic to PHP 8.1 instances. | |
| WE5.4.4 | If we decouple the legacy dumps processes from their current bare-metal hosts and instead run them as workloads on the DSE Kubernetes cluster, this will bring about demonstrable benefit to the maintainability of these data pipelines and facilitate the upgrade of PHP to version 8.1 by using shared mediawiki containers. | |
| WE5.4.6 | If the beta cluster is configured to run MediaWiki with PHP 8.1 then the Data Platform Engineering group and their SRE team will be able to validate whether the existing dumps code functions correctly, or whether any significant functional changes would be required. | |
| WE5.5.1 | If, by the end of January, we are able to measure and monitor Wikimedia hosted dumps traffic using log data, we will have clarity on how users are consuming the different dumps formatting options and access points. This will unblock additional metrics for overall consumption across streams, and improve our understanding of what users care about in terms of recency, data completion, and structure, so that we can tailor the overall API strategy accordingly. | |
| WE5.5.2 | If, by the end of Q3, we create a consolidated view of developer personas and use cases collected through a listening and discovery tour, then we will uncover lesser understood gaps and opportunities in this space. This will leverage existing work completed by stakeholder teams in their respective areas (eg: Dumps, WME), in addition to creating new insights by conducting interviews with WMF staff, technical volunteers, and high impact content reuse partners (eg: WME customers and prospects). | |
| WE6.1.7 | If we review the user feedback, decide on a code search and code browsing solution, deploy it to the production infrastructure as an officially supported service and enable indexing of both existing and new repositories from both code tracking systems, we will increase the scope of code that is indexed and searchable and simplify the process of locating code in day to day operations as well as during incident response. | |
| WE6.1.8 | If we analyze the documentation metrics scores from our test dataset, we can evaluate the usefulness and effectiveness of the draft metrics, collect feedback, and provide actionable insights for implementing automated metrics computation | |
| WE6.1.9 | If we transition 5 additional access groups to management within the Identity Management system, it will enhance access governance by improving efficiency, significantly reducing TOIL and improving the onboarding experience for incoming Wikimedia staff and new members of the technical communities. | |
| 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. | |
| WE6.2.3 | If we create a new deployment UI that provides a web interface for deployments that is open to existing deployers it will allow backporters to have a shared view of deployments in progress and provide greater visibility for deployments in progress. | |
| WE6.2.5 | If we publish a planning doc to move single-version routing out of MediaWiki and gather comments from stakeholders on the implementation, then we will reduce friction during implementation. | |
| 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 during when we start deploying that container. | |
| WE6.2.7 | If we make a deployment web UI available behind our single sign-on system and open it to the Wikimedia development community it will increase the number of backport deployers. | |
| WE6.2.8 | Continuing on the capabilities of Catalyst to deliver pre-merge test environments of MediaWiki and its extensions & skins on Kubernetes, if we facilitate deployments of pre-merge patches for MediaWiki services, by running pre-merge tests for Wikifunctions, then contributors will be able test more MediaWiki projects with stable, well-defined, isolated test environments. | |
| WE6.2.9 | If we test the proposed MediaWiki routing implementation with a single wiki, we will have proven the plan works and can proceed with an accelerated rollout to other wikis and we will be able to route a single version container to Wikimedia’s wiki hosting infrastructure. | |
| WE6.3.7 | By establishing detailed measurement criteria and evolution guidelines for our sustainability framework, we will create an actionable scoring system for platform improvements. | |
| WE6.3.8 | Engaging with prospective users to explore Toolforge UI’s early design prototype will help us uncover improvement opportunities and risks to be addressed in a follow-up iteration. | |
| Signals & Data Services (SDS) Hypotheses
[ SDS Key Results ] | ||
|---|---|---|
| Акронім гіпотези | Q3 text | Деталі і обговорення |
| SDS1.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.1.2 | If we assess the impact of the new South American data center (MAGRU) on our relevance metric (unique devices), we will be able to produce a report that provides insights into the return on investment of current and future data center investments. | |
| 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 | Якщо ми реалізуємо часто використовувану роботу щодо запиту даних історії MariaDB MW на основі Spark, узгодимо відсутні елементи і збагатимо їх, ми надаватимемо щодня оновлювану таблицю даних про історію вікітексту MW. | |
| Гіпотези Майбутніх цільових груп (МЦГ) | ||
|---|---|---|
| Акронім гіпотези | Q3 text | Деталі і обговорення |
| FA1.1.1 | Якщо ми проведемо в позаплатформний дуже низькозатратний експеримент із застосуванням ШІ “Add a Fact”, ми можемо дізнатися, чи позаплатформні користувачі можуть допомогти зростанню/підтримці збереження знань у можливому майбутньому, де контент Вікіпедії переважно споживається поза платформою. | |
| Product and Engineering Support (PES) Hypotheses | ||
|---|---|---|
| Акронім гіпотези | Q3 text | Деталі і обговорення |
| PES1.1.2 | Якщо ми виберемо три основні напрямки, у яких збільшити зусилля, спрямовані на поліпшення нашої культури рецензування, і спілкуватися про них на правильних каналах, ми побачимо поліпшення у відгуках на ітеративний розвиток, прийняття рішень та співпрацю в наступному дослідженні культури (січня 2025 року). | |
| PES1.1.3 | Якщо ми надішлемо переглянуте опитування щодо культури, ми визначимо галузі, де ми можемо надати підтримку менеджерам, щоб продовжити зміцнювати нашу культуру патрулювання. | |
| PES1.3.5 | Якщо ми створимо гру на основі Вікіпедії для щоденного використання, яка підкреслює зв'язки в широких областях знань, це заохотить споживачів регулярно відвідувати Вікіпедію і сприятиме активному навчанню, що призведе до збільшення взаємодії з контентом на Вікіпедії і довших сеансів використання. | |
| PES1.3.6 | Якщо ми застосуємо уроки з першого Sprinthackular до другого заходу, спрямованого на поліпшення інструментів і процесів прототипування, принаймні один проєкт Sprinthackular покаже достатньо цінності і шансів щодо його інтеграції в АПП. Ми також зможемо розробити повторну систему Sprinthackular, яку інші команди визнають придатною для вивчення будь-якої фокусної зони. | |
| PES1.5.1 | (Розпочинаючи з 1 жовтня) Якщо ми завершимо і опублікуємо проєкт SLO Edit Check, практикуючи його включення в регулярні робочі процеси і рішення, а також розробимо SLO Citoid, ми продовжимо вчитися, як визначити і відстежувати спільні SLO для користувачів та команд. | |
| PES1.5.2 | (Починаючи з 1 жовтня) Якщо ми уточнимо і письмово подамо документ з набором ролей і обов'язків зацікавлених сторін протягом усього життєвого циклу послуг, це дозволить командам зробити свідомі зобов'язання в каталозі послуг, включаючи їхні SLO. | |
Пояснення кошиків
Вікідосвід
Метою цього кошика є ефективне надання, покращення та впровадження інновацій у забезпечення вікідосвіду, що дозволяє поширювати вільні знання по всьому світу. Цей кошик відповідає рекомендаціям стратегії руху №2 (Покращуйте досвід користування) та №3 (Забезпечте безпеку та інклюзію). Наші аудиторії включають всіх, хто спільно працює на наших вебсайтах, а також читачів та інших споживачів вільних знань. Ми підтримуємо сайт, що входить в топ-10 світових вебсайтів і багато інших важливих вільних культурних ресурсів. Ці системи мають вимоги до продуктивності та часу безвідмовної роботи на рівні з вимогами найбільших технологічних компаній у світі. Ми надаємо користувацькі інтерфейси для вікі, переклад, API розробників (і багато іншого!), а також допоміжні застосунки та інфраструктуру, які всі разом утворюють надійну платформу для співпраці волонтерів для створення вільних знань у всьому світі. Наші цілі для цього кошика повинні дозволити нам удосконалити нашу основну технологію та можливості, забезпечити постійне покращення нами досвіду редакторів-волонтерів і модераторів наших проєктів, покращити досвід усіх технічних вкладників, які працюють над покращенням або розширенням такого вікідосвіду і забезпечити найкращі враження для читачів і споживачів вільних знань у всьому світі. Ми зробимо це за допомогою роботи над продуктом і технологією, а також за допомогою досліджень і маркетингу. Ми очікуємо, що будемо мати щонайбільше п'ять цілей для цього кошика.
Знання створюються людьми! І тому наш річний план буде зосереджений на вмісті, а також на людях, які його створюють, і на тих, хто має до нього доступ і читає його.
Наша мета — розробити операційний план на основі наявної стратегії, головним чином, наших гіпотез про «маховик» дописувача, споживача та вмісту. Основна зміна, про яку я прошу, — це акцент на тій частині маховика, яка стосується вмісту, і дослідження того, що наші модератори й функціонери можуть потребувати від нас зараз, з метою визначення показників стану спільноти в майбутньому.
Сервіси сигналів і даних
Щоб відповідати рекомендаціям Стратегії руху щодо Забезпечення справедливості у прийнятті рішень (Рекомендація №4), Покращення досвіду користування (Рекомендація №2) та Оцінювання, ітерації та адаптації (Рекомендація №10), особи, які приймають рішення у всьому русі Вікімедіа, повинні мати доступ до надійних, релевантних та своєчасних даних, моделей, інсайтів та інструментів, які можуть допомогти їм оцінити вплив (як реалізований, так і потенційний) їхньої роботи та роботи їхніх спільнот, що дасть їм змогу ухвалювати кращі стратегічні рішення.
У кошику «Сервіси сигналів і даних» ми виділили чотири основні аудиторії: співробітників Фонду Вікімедіа, афіліатів і груп користувачів Вікімедіа, розробників, які повторно використовують наш вміст, і дослідників Вікімедіа, а також ми визначаємо пріоритети й задовольняємо потреби цих аудиторій у даних і відомостях. Наша робота охоплюватиме низку видів діяльності: визначення прогалин, розробку показників, побудова потоків для обчислення показників, а також розробка шляхів дослідження даних і сигналів, які допомагають особам, які приймають рішення, ефективніше та з задоволенням взаємодіяти з даними та інсайтами.
Майбутні цільові групи
.svg)
Метою цього кошика є дослідження стратегій розширення за межі наших наявних цільових груп споживачів і дописувачів, щоб, як необхідна інфраструктура екосистеми вільних знань, справді охопити кожного у світі. Цей кошик відповідає Рекомендації №9 Стратегії Руху (Впроваджуйте інновації у вільних знаннях). Люди все більше і більше споживають інформацію в інтерфейсах і формах, які відрізняються від нашої традиційної пропозиції вебсайту зі статтями — люди користуються голосовими помічниками, проводять час з відео, взаємодіють зі штучним інтелектом і т.д. У цьому кошику ми запропонуємо і перевіримо гіпотези щодо потенційного довгострокового майбутнього екосистеми вільних знань і того, як ми будемо її необхідною інфраструктурою. Ми робитимемо це через роботу над продуктом та технологією, а також через дослідження, партнерства та маркетинг. У міру того, як ми визначатимемо перспективні майбутні стани, уроки з цього кошика впливатимуть і розширюватимуться через кошики №1 і №2 у наступних річних планах, підштовхуючи наші продуктові та технологічні пропозиції туди, де вони повинні бути, щоб служити шукачам знань майбутнього. Наші цілі для цього кошика повинні спонукати нас до експериментів та досліджень, оскільки ми зосереджуємось на баченні майбутнього вільних знань.
Менші кошики
У нас також є два інші «менші кошики», які складаються з областей критично важливих функцій, які повинні існувати у Фонді для підтримки наших основних операцій, і щодо деяких з них ми маємо спільні риси з будь-якою організацією, що має справу з програмним забезпеченням. Ці «менші кошики» не матимуть власних цілей вищого рівня, але будуть робити внесок у досягнення цілей вищого рівня інших груп і підтримувати їх. Вони такі:
- Базова інфраструктура. До цього кошика належать команди, які підтримують та розвивають наші центри обробки даних, обчислювальні платформи та платформи зберігання даних, сервіси для їх експлуатації, інструменти та процеси, які забезпечують роботу наших загальнодоступних сайтів та сервісів.
- Продуктова та інженерна підтримка. До цього кошика належать команди, які працюють «масштабно», надаючи послуги іншим командам, що підвищує продуктивність та покращує роботу цих інших команд.