Jump to content

Річний план Фонду Вікімедіа/2025-2026/ЦКР Продукту і технології

Add links
From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs and the translation is 77% complete.
Outdated translations are marked like this.
Other languages:
Річний план Фонду Вікімедіа на 2025-2026 роки

В наступному році

Хоч світ змінюється, Фонд Вікімедіа залишається впевненим, що ми хочемо, щоб наша місія — надавати і зберігати корисну інформацію з проєктів Вікімедіа в Інтернеті безплатно — була справою багатьох поколінь: ми хочемо, щоб вільні знання продовжували бути доступними для багатьох наступних поколінь.

Інтернет швидко змінюється. Нові покоління отримують інформацію через соціальні відео та штучний інтелект, і, порівняно зі старшими поколіннями, менше з них знають про Вікіпедію. Ми спостерігаємо відповідне зменшення кількості людей, які відвідують наші сайти, та кількості людей, які редагують. Водночас щоб підтримувати свої пропозиції зі штучного інтелекту та пошуку, платформи у всьому Інтернеті залежать від вмісту Вікімедіа. Така динаміка є серйозним викликом, але вона дає зрозуміти, чому надійні вільні знання, які ми створюємо разом, є такими важливими. Світ як ніколи потребує джерела достовірних, перевірених людьми знань, і проєкти Вікімедіа продовжують демонструвати, що вони можуть забезпечити таке джерело.

Щоб відповісти на ці виклики в наступному році, ми будемо створювати шляхи для стійкого використання вмісту Вікімедіа, а також приносити вміст Вікімедіа в соціальні онлайн-простори, де проводять час нові покоління. Ми будемо вдосконалювати наші власні сайти так, щоб читачі хотіли повертатися, глибоко залучатися та робити свій внесок значущими для них способами. І ми будеми інвестувати в нашу здатність швидко експериментувати з новими технологіями, щоб наш темп розвитку відповідав темпу змін у світі.

Інфраструктурна мета полягає в тому, як платформа та користувацький досвід допоможуть вирішити ці завдання та охопити більшість учасників руху. Це не перелік проєктів, а набір напрямків, які сприятимуть зростанню кількості волонтерів, дадуть їм змогу створювати достовірний енциклопедичний вміст, фінансувати нашу місію та розвивати наші пропозиції, щоб формувати інтернет, що змінюється. Ви можете прочитати більше про ці чотири стратегічні напрямки.

Стимулювати зростання волонтерів

Спільнота волонтерів є унікальним двигуном успіху проєктів Вікімедіа, і нам потрібно, щоб вона була в доброму стані та зростала. Але протягом останнього року ми спостерігали постійне зменшення кількості нових редакторів та тих, що повертаються до проєктів. Щоб краще розуміти потреби наших поточних волонтерів і ефективніше на них реагувати, Фонд перетворив щорічне опитування «Список побажань спільноти» на постійно відкритий процес приймання побажань, де потреби користувачів та ідеї щодо проєктів можуть бути враховані в роботі різних команд Фонду. Ми згрупували побажання в «Області зацікавленості» і включили три з них до ключових результатів річного плану. Ми також започаткували пілотну Консультативну раду з продукту і технології, щоб доповнити численні розмови, які команди Фонду проводять з членами спільноти на вікі та поза нею протягом року. Крім того, ми визначили можливості залучення нових поколінь до наших проєктів, наприклад, той факт, що молодь охоче бере участь в інших онлайнових соціальних просторах, де вона має прості, зручні для мобільних пристроїв способи спілкування на спільні теми, що їх цікавлять.

У наступному році ми будемо сприяти зростанню кількості волонтерів, роблячи внесок простішим і привабливішим для нових поколінь завдяки розширенню mobile-first, новим способам редагування («структуровані завдання») та додаванню інтелектуальних робочих процесів, які спрощують конструктивне редагування з мобільних пристроїв для нових дописувачів («перевірка редагування»). Щоб глибше залучити та утримати наявних волонтерів, ми будемо пропонувати рекомендовані дії та завдання і розміщувати їх у центральному хабі, що спростить організацію діяльності у вікі. Ми будемо вдумливо використовувати штучний інтелект для посилення роботи волонтерів, завжди залишаючи людей у процесі та надаючи пріоритет прозорості. Як для нових, так і для досвідчених волонтерів, ми створимо можливості для спілкування та спільної роботи на наших сайтах — натхненні успішними кампаніями та Вікіпроєктами — що дозволить їм знайти редакторів-однодумців та покращити вміст, пов'язаний з їхніми інтересами (відповідно до цієї області зацікавленості Списку побажань).

Надавати достовірний енциклопедичний вміст

У міру того, як матеріали, створені за допомогою штучного інтелекту, множаться в Інтернеті, світ як ніколи потребує достовірного енциклопедичного вмісту. Ми хочемо підвищити здатність волонтерів як створювати новий вміст, так і забезпечувати достовірність наявного вмісту, а також надавати достовірний вміст новому поколінню читачів з новими потребами та уподобаннями.

Щоб допомогти волонтерам створювати новий вміст, ми будемо розвивати наявні інструменти та робочі процеси (такі як Інструмент перекладу вмісту), щоб як великі, так і малі спільноти могли охопити важливий вміст. Щоб забезпечити те, що наявний вміст продовжує бути достовірним, ми допоможемо досвідченим волонтерам краще управляти зростаючим обсягом роботи, розширивши інструменти, які вони використовують для пошуку завдань, що потребують їхньої уваги. Це полегшить їм оновлення статей та скасування некорисних правок (відповідно до цієї області зацікавленості Списку побажань).

Ми також допоможемо посадовим особам захищати наш вміст, виявляючи нові сигнали (поза IP-адресами), які ідентифікують недобросовісних учасників, що дозволить блокувати користувачів таким чином, щоб звести до мінімуму помилкове блокування добросовісних редакторів.

Щоб донести енциклопедичний вміст до нового покоління, ми створимо функції, які допоможуть новим типам читачів легко розуміти статті, допомагатимуть їм знаходити інформацію, яка їх цікавить, і дозволять їм при читанні брати активну участь. Ці зміни мають на меті заохотити нових читачів Вікіпедії стати відданими читачами Вікіпедії, а деяких з них — стати донорами (відповідно до цієї Області зацікавленості Списку побажань).

Надання достовірного вмісту також означає підтримку моделі «знання як послуги», коли весь інтернет спирається на вміст Вікімедіа. У цій моделі наша інфраструктура є цінним ресурсом не лише для людей, які заходять на наш веб-сайт, але й для пошукових компаній та компаній зі штучного інтелекту, які автоматично отримують доступ до нашого вмісту як до основних вхідних та вихідних даних своїх продуктів. Такі компанії є лише одним із багатьох видів використання, які дедалі більше створюють непосильне навантаження на нашу інфраструктуру. Минулого року значне збільшення обсягу запитів від скрейперних інструментів і ботів зробило для нас виправлення цієї тенденції ще нагальнішим. Нам потрібно створити стійкі шляхи доступу до вмісту знань для розробників і повторних користувачів, щоб люди були пріоритетнішими за ботів.

Фінансувати майбутнє «вільного»

Відділ продукту і технології відіграє важливу роль у забезпеченні стійкості нашого руху. У наступному році ми будемо тісно співпрацювати з Командою збору коштів, щоб наші донори отримували все більш зрозумілий і корисний досвід. На наших сайтах і мобільних застосунках ми створимо можливості для читачів висловити свою вдячність Вікіпедії через пожертви, для донорів створимо нові способи, щоб вони відчували визнання і продовжували свої пожертви рік за роком.

Формувати мінливий Інтернет

Щоб донести вільні знання до кожного у світі, нам потрібно зустрітися з ними там, де вони є, з досвідом, який допомагає їм вчитися. Люди у віці 18-24 років менш обізнані з Вікіпедією та менше користуються нею, ніж попередні покоління. Вони здебільшого навчаються та взаємодіють з платформами короткометражних відео, авторитетними онлайн-особистостями, соціальними іграми та, дедалі частіше, застосунками штучного інтелекту. Цього року ми зробимо Вікіпедію доступною для цих аудиторій у місцях, де вони проводять час онлайн, щоб вони знали Вікіпедію як джерело достовірних і створених людьми знань. Ми збільшимо нашу присутність на популярних відеоплатформах, поширюючи вміст Вікіпедії та створюючи спільноти у цих просторах. І ми будемо досліджувати ідеї, як перенести знання з Вікіпедії на ігрові та соціальні платформи.

В рамках Інфраструктури це поділено на три робочі портфоліо (які називаються «кошиками»): Вікідосвід, Сервіси сигналів і даних, а також Майбутні аудиторії. Ці кошики такі ж, як минулого та позаминулого року.

Ми віримо, що цей план відповідає вирішальному моменту в історії інтернету і дає нам можливість гарантувати, що вільний вміст знань і надалі буде доступним для всіх поколінь і формуватиметься ними. Наші цілі та ключові результати детальніше показують структуру та вміст цього плану, і ми з нетерпінням чекаємо на запитання та ідеї від ширшої спільноти.

Створення, вдосконалення та підтримка інфраструктури для проєктів Вікімедіа та волонтерів, засновуючись на наших цінностях

«Фонд зробить та зберігатиме корисну інформацію зі своїх проєктів доступною в Інтернеті безоплатно, назавжди.»

Команди Продукту та Технології надають постійний, цілорічний пріоритет створенню, поліпшенню та підтримці інфраструктури, яка обслуговує проєкти Вікімедіа. Ми інвестуємо в хостинг проєктів Вікімедіа, розробку програмного забезпечення з відкритим кодом та дизайн систем, а також у підтримку та поліпшення інфраструктури для продуктів даних та моделей штучного інтелекту.

Частина нашої основної роботи зосереджена на фундаментальних аспектах розробки та хостингу великого популярного вебсайту. Ми розміщуємо наші проєкти Вікімедіа в дата-центрах, на серверах та апаратному забезпеченні, яке ми купуємо, встановлюємо та підтримуємо, підключеному між собою та до решти Інтернету через високошвидкісну мережу. Ми контролюємо та за потреби додаємо потужність, а також оновлюємо обладнання, коли воно застаріває. Наприклад, цього року ми плануємо розширити наші потужності та оновити апаратне забезпечення в наших дата-центрах в Ашберні, штат Вірджинія, та Керролтоні, штат Техас.

Ми розробляємо та створюємо програмне забезпечення з відкритим кодом (найвідоміше — Медіавікі). Ми також використовуємо та впроваджуємо багато наявних сторонніх застосунків, бібліотек та фреймворків з відкритим кодом. Важливі помилки в нашому програмному забезпеченні отримують пріоритет і виправляються. Підтримка програмного забезпечення з відкритим кодом вимагає висококваліфікованої роботи людей зі спеціальними знаннями в галузі розробки програмного забезпечення з відкритим кодом, інженерії надійності сайтів (SRE), управління продуктами, управління програмами, дизайну тощо. Наші співробітники працюють над тим, щоб наше програмне забезпечення та системи були сучасними та адаптувалися до постійно мінливого середовища. Це включає модернізацію нашого коду, щоб і надалі користуватися перевагами виправлень безпеки та добре працювати з новим програмним забезпеченням сторонніх розробників. Наприклад, Медіавікі написано на PHP, і минулого року ми перейшли з PHP 7.4 на 8.1, що вимагало змін як у коді, так і в інфраструктурі, де ми розміщуємо наші сайти та послуги. Цього року ми будемо продовжувати цю роботу і перейдемо на версію 8.3, використовуючи отриманий під час оновлення до версії 8.1 досвід та розроблені інструменти. Оновлення зробить наші системи швидшими для читачів, простішими у використанні для співробітників та волонтерів і безпечнішими для всіх. Це також заощадить час майбутньої розробки завдяки покращенням у безпеці, продуктивності та підтримці, які супроводжуються також мовними оновленнями.

Щоб наші проєкти та вміст залишалися доступними в Інтернеті як сьогодні, так і завжди, наші команди докладають значних зусиль для забезпечення високої доступності наших сайтів і сервісів. Один з аспектів цієї роботи зосереджений на відновленні після катастрофічних або зловмисних подій. Наприклад, ми забезпечуємо резервне копіювання важливих даних і можливість їх відновлення. Аналогічно, двічі на рік ми перевіряємо нашу здатність автоматично перемикати сайти між нашими центрами обробки даних і виправляємо виявлені проблеми. Інший аспект цієї роботи зосереджений на виявленні та адаптації до мінливих тенденцій у типах і обсягах трафіку, який ми отримуємо. Наприклад, з огляду на безпрецедентний ріст автоматизованих скреперів, ми надаємо пріоритет роботі, спрямованій на забезпечення доступності наших сайтів і послуг для користувачів-людей, застосовуючи системний підхід до встановлення норм відповідального використання нашої інфраструктури.

Не вся робота планується заздалегідь. Ми також реагуємо на несподівані події та інциденти, такі як відключення сайтів, звіти про порушення безпеки або інциденти безпеки, а також масштабні атаки вандалів на наші проєкти. Ми моніторимо нашу продуктивність та перешкоди для доступності по всьому світу (включно з проблемами підключення до Інтернету або цензурними блокуваннями) та розслідуємо будь-які виявлені аномалії. Деякі з цих несподіваних подій або повторюваних патернів проблем змушують співробітників надавати пріоритет короткостроковим проєктам, спрямованим на послаблення або повне запобігання подальшому негативному впливу. Наприклад, такі зусилля були вирішальними для того, щоб наші проєкти Вікімедіа витримали глобальні сплески трафіку, спричинені важливими подіями (наприклад, смерть відомих особистостей), завдяки поєднанню оптимізації продуктивності, перепроєктуванню архітектури вузьких місць та збільшенню місткості. Аналогічно, нещодавні поліпшення зручності використання наших інструментів та систем управління трафіком, який ми отримуємо, дозволили нам швидше та ефективніше реагувати на мінливі умови. Такий адаптивний підхід є невіддільною частиною нашої здатності реагувати на нові події, часто в короткі терміни, а також забезпечувати доступність наших проєктів та вмісту.

Цілі щодо Продукту і технології

Цілі, представлені тут, мають форму проєкту і відкриті для коментарів та обговорення.

  • Дані Цілі становлять напрямок високого рівня.
  • «Ключові результати» (КР) є вимірюваним способом відстеження успіху в досягненні цілей.
  • «Гіпотези», що лежать в основі кожного КР, представляють фактичну роботу, яку ми виконуємо, щоб спробувати досягти відповідних ключових результатів. Вони будуть оновлюватися в цьому документі та на вікі відповідного проєкту чи команди в міру накопичення інформації протягом року.
  • wishlist item призначений для роботи, яку Фонд визначив як пріоритетну згідно зі Списком побажань спільноти.

Вікідосвід (WE)

Досвід дописувачів (WE1)

Ціль: дописування збільшується, оскільки волонтерам пропонують цікаві можливості і вони розуміють їхній вплив. Обговорити

    • Контекст: Ця ціль стане основою для реалізації нової стратегії щодо дописувачів, яка складається з трьох основ: 1) надання волонтерам централізованого способу організації їхньої діяльності у вікі; 2) надання менших, дискретних завдань, щоб створити більшу ясність і допомогти волонтерам реалізувати свій потенціал; 3) підвищення значущості дописування. У 2025/26 фінансовому році ми плануємо створити базову інфраструктуру, щоб допомогти волонтерам централізовано організувати свою діяльність у вікі, починаючи з заходів, орієнтованих на досвідчених редакторів і модераторів. У наступні роки ми зачепимо всі ролі дописувачів і включимо більше проблемних просторів. Крім того, ми продовжимо інвестувати в Перевірку редагування та Структуровані завдання, створюючи основу для масштабованого використання штучного інтелекту — як для настанов у процесі редагування, так і для того, щоб вказувати волонтерам на привабливі можливості. І нарешті, ми будемо інвестувати в те, щоб зробити вплив волонтерів більш помітним, щоб їхній досвід був для них більш значущим.
      • пункт списку побажань Ключовий результат WE1.1: Збільшити на 4% [ii] виміряну за допомогою контрольованих експериментів частоту, з якою редактори, що мають ≤100 сукупних редагувань, публікують конструктивні редагування при мобільному веб-перегляді [i] (до кінця другого кварталу).
        • i. «Конструктивні редагування» = редагування сторінок у будь-якому основному просторі імен Вікіпедії, які не відмінені протягом 48 годин після публікації.
        • ii. T389403#10960480
        • Новим волонтерам важко почати успішно редагувати. Особливо тим, хто користується мобільними пристроями, де простір екрана обмежений, а увага часто фрагментована.
        • Дехто втомлюється від контексту, необхідності терпіння, а також спроб і помилок, потрібних для конструктивного внеску. Інші ще не мали переконливої нагоди спробувати.
        • У розділі WE 1.1 ці питання будуть вирішуватися шляхом:
          • Висвітлення пропозицій редагування
          • Надання дієвих порад під час редагування
          • Створення робочих процесів редагування, більш орієнтованих на конкретні завдання
        • В основі цих зусиль лежить потреба в масштабованих способах визначення того, як можна покращити поточне редагування та наявний вміст. Щоб розширити ці можливості, ми продовжимо експериментувати з машинним навчанням, щоб дізнатися, як воно може найкраще служити всім редакторам, незалежно від їхніх ролей та рівнів досвіду.
        • Запропонована методологія оцінки КР: На основі кожної платформи ми розрахуємо частку інтервенцій, які ми впровадили та оцінили за допомогою контрольованих експериментів, що відповідали та/або перевищували цільовий показник конструктивних редагувань, який ми встановили на початку цього року. Див. phab:T379285#10782051 для ознайомлення з міркуваннями.
          • Примітка: станом на 30 червня 2025, для WE 1.1 заплановані два контрольовані експерименти.
      • пункт списку побажань Ключовий результат WE1.2: Збільшення кількості колаборацій у вікі на 55% рік до року до кінця четвертого кварталу.
        • Дописувачам часто важко знайти можливості для співпраці один з одним, особливо навколо тем і завдань, які їх цікавлять. Це може призвести до відчуття самотності у вікі для новачків, а також до вигорання для досвідчених редакторів. Крім того, вплив спільної діяльності часто незрозумілий, що може призвести до того, що менше людей захочуть долучатися, організовувати чи підтримувати співпрацю у вікі.
        • Ми хочемо зробити цінність співпраці зрозумілішою, зробивши наступне:
        1. Створити нові способи для того, щоб ділитися впливом спільної діяльності на вікі
        2. Розпочати збір даних про вплив спільної діяльності на весь рух
        3. Створити базову інфраструктуру для відстеження спільних внесків, щоб ми могли запропонувати нові інноваційні способи визнання та винагородження внесків у майбутньому.
        • Співпраця буде вимірюватися кількістю нових заходів, створених через реєстрацію подій у розширенні CampaignEvents. Ціль полягає в тому, щоб до кінця цього КР у нас було більше користувачів інструментами розширення і більше нових способів виявлення впливу співпраці. Це дасть нам змогу поєднати нашу наявну інфраструктуру з іншими способами визнання та винагороди за роботу у вікі (такими як модуль impact, подяки тощо).
        • Область зацікавленості Списку побажань: Список побажань спільноти/Області зацікавленості/Підключення дописувачів
      • пункт списку побажань Ключовий результат WE1.3: До кінця третього кварталу 10% учасників, які побачили головну сторінку, орієнтовану на нових модераторів, відвідували її два тижні поспіль.
        • Ми вважаємо, що можемо краще пропонувати можливості для участі волонтерів. У довгостроковій перспективі ми вважаємо, що головна сторінка може бути корисною, щоб допомогти будь-якому редактору організувати свою роботу, знайти нові можливості, а також зрозуміти свій вплив. Наша мета на 2025/2026 фінансовий рік — висвітлити досвідченим редакторам нові можливості для виконання завдань з модерації, з якими вони раніше могли не стикатися.
        • Спочатку ми перевіримо цю теорію, з'ясувавши, наскільки досвідчені редактори будуть взаємодіяти з головною сторінкою, подібною до тієї, до якої мають доступ новачки.
        • Потім ми запропонуємо конкретні заходи з модерації (деталі будуть визначені пізніше) учасникам, які не мають досвіду такого типу модерації, з метою зменшення навантаження на досвідчених редакторів шляхом скорочення відставання (відповідно до нового КР).
        • Якщо концепція головної сторінки виявиться успішною, ми плануємо зробити цю сторінку модульною, щоб задовольнити потреби спільнот. Ці модулі можуть включати такі речі, як полегшення розуміння редакторами свого впливу.
        • Примітки щодо цієї методології:
        • У нас буде гіпотеза для визначення нашої аудиторії, яка буде частиною WE1.3.1.
        • «Модератори» будуть відповідати визначенню, запропонованому в Research:Develop a working definition for moderation activity and moderators, хоча для уточнення кількісного визначення буде потрібно провести додаткову роботу.
        • Другий тиждень буде визначатися відносно часу першого відвідування кожного користувача. У цьому випадку ми переглянемо всіх нових модераторів, які відвідали головну сторінку протягом певного періоду часу, а пізніше (від 7 до 14 днів) зробили принаймні ще одне повторне відвідування.
        • Область зацікавленості Списку побажань: Список побажань спільноти/Області зацікавленості/Визначення пріоритетності завдань
      • пункт списку побажань Ключовий результат WE1.4: Покращити відсоток унікальних відвідувачів списку спостереження та/або останніх змін, які переходять до перегляду редагування.
        • Наша мета — допомогти редакторам, які зробили понад 100 редагувань, ефективніше знаходити та відкривати редагування, що відповідають їхнім інтересам. Ми дослідимо пріоритетну область завдань, виконаємо побажання в цій області та запросимо додаткові відгуки від волонтерів щодо того, як поліпшити ці інструменти. Ми можемо виміряти успіх, поліпшивши ефективність кожної сторінки в «пошуку роботи», що визначається показником клікабельності.
      • Ключовий результат WE1.5: Визначити та ввести в дію сім високопріоритетних метрик [1], необхідних для відстеження прогресу в досягненні цілей, визначених у стратегії для учасників, до кінця 4 кварталу, шляхом створення інформаційної панелі та введення в дію метрику щомісячної активності модераторів.
        [1] Редактори, що лишилися активними, конструктивна активація, конструктивні редагування, реєстрація облікових записів новачків, що залишилися активними, активні редактори за стажем, активні редактори за рівнем досвіду.
        • Стратегія досвіду учасників передбачає 3-5-річні зусилля, спрямовані на «стимулювання зростання кількості волонтерів» та «підвищення рівня утримання та активізації» як нових, так і існуючих учасників через три основні напрямки діяльності:
        1. Оптимізацію того, як волонтери можуть отримувати рекомендації, керувати своїми завданнями та інтересами, бачити, що відбувається на вікі, та розуміти свій вплив
        2. Надання належним чином структурованих завдань для створення чіткішого розуміння та допомоги волонтерам у реалізації їхнього потенціалу шляхом оптимізації робочих процесів, до яких ми їх залучаємо, включаючи постійні інвестиції у надання структурованих настанов та автоматизацію повторюваних завдань, з особливим акцентом на мобільному веб-досвіді
        3. Надання внескові значущості, показуючи волонтерам їхній вплив та інвестуючи у розвиток міжособистісних зв'язків і створюючи середовище, засноване на позитивному зворотному зв'язку.
        • Проєкт стратегії вимірювання потім склав розгалужену мережу показників для відстеження цієї теорії змін. Зроблений висновок, що основним показником успіху («ключовою метрикою») має бути кількість утриманих редакторів, доповнена вужчими індикаторними метриками, такими як конструктивна активація та намір учасників повернутися, а також ширшими «подальшими» показниками, такими як активні редактори та якісний вміст. Ми повинні забезпечити, щоб ці метрики були введені в дію та відображалися на інформаційній панелі, щоб ми могли відстежувати наш прогрес у реалізації цієї стратегії.
      • Ключовий результат WE1.6: До кінця третього кварталу користувачі списку спостереження можуть легше організовувати свою роботу та ефективніше діяти, вживаючи заходів патрулювання або редагування, що вимірюється якісним зворотним зв'язком.
        • Наша мета — допомогти редакторам, які мають понад 100 редагувань, ефективніше знаходити редагування, що відповідають їхнім інтересам. Ми дослідимо сферу пріоритетності завдань, врахуємо побажання в цій галузі та запросимо додаткові відгуки волонтерів щодо покращення цих поверхонь.
      • Key result WE1.7: Primary: Achieve a ≥ 10% relative increase in the edit completion rate of qualified newcomer and Junior Contributor mobile edit sessions, based on controlled A/B test(s).[i]
        [i]         Qualified edit session = edit session in which a logged-in user with ≤100 cumulative edits spent at least ≥2 seconds in VE's "ready" state.
        Guardrail:         No meaningful decreases in constructive edit rate among mobile edits published by newcomer and Junior Contributors, based on controlled A/B test(s).
        • 150,000–200,000 times/day, someone will tap "Edit" on mobile web, wait for the editing interface to load, look around for at least 2 seconds, and then leave without doing anything. No keystrokes, no taps on the toolbar…nothing.
        • WE 1.7 will meet these "curious clicks" with clear, compelling, and structured edit suggestions that cause the people making them to experience the satisfaction, joy, and meaning that can come with making Wikipedia, the resource they chose to visit, a bit better.
      • Key result WE1.8: By the end of Q4, target a 5 percent overall relative increase in the mobile web account creation completion rate, with success measured by at least three controlled experiments achieving a minimum 2 percent relative improvement each.
        • Account creation is the gateway to meaningful participation on Wikimedia projects, yet it remains an outdated experience in the newcomer journey. The current flows impose high cognitive load, present limited or confusing value propositions, and rely on legacy interface patterns that no longer reflect contemporary expectations. As a result, many potential contributors disengage before they have a chance to join the community.
        • This initiative aims to modernize account creation, reduce friction for good faith contributors, and introduce thoughtful experiments that encourage registration at the moments where motivation is naturally highest. The work lays essential groundwork for long term improvements in newcomer activation, retention, and editor diversity.
        • We estimate a 5 percent relative increase in account creation on Wikipedia on mobile would translate to several thousand additional new accounts per month, and several hundred more retained new editors per month, based on current registration volumes.
      • Key result WE1.9: By the end of Q4, deliver one tangible product recommendation each for goal setting, newcomer progression, and recognition to enable junior contributors to stay engaged and evolve.
        • Background: we know that retention of junior contributors is quite low despite recent gains (data). We believe that a fundamental challenge for overcoming this low junior contributor retention is developing our platforms to help editors stay highly motivated to contribute – i.e. not just reducing the barrier to contribute but also making the experience rewarding. This is not trivial though – e.g., editors enter the project with varying motivations; interventions such as gamification that may boost initial engagement might not help with long-term retention.
        • Why now: much of the focus of Contributors Product teams to date has been related to reducing technical barriers to activation/engagement but there are a suite of upcoming projects that are more retention-focused – e.g., Progression System and Recognition. The research under this KR aims to get ahead of this implementation work and provide clear recommendations to Product teams in this space about how they should design their platforms to better support the diverse motivations of editors and increase long-term retention. This links back to key questions related to newcomers and junior editors in the Contributor Strategy.
        • Proposed KR scoring methodology: for each identified project (goal setting; progression system; recognition), we will make at least one concrete recommendation with implications for design. Research is experimental work and the projects may evolve over the course of the KR but we will keep in close communication with the relevant product teams. In practice, these recommendations may include insights about what is most demotivating for newcomers (things to avoid) what is most satisfying (things to emphasize), common "tripping points" in journeys that need to be addressed, strategies for getting through these challenges, etc. The recommendation should help the PM identify clear next steps for design and/or engineering.
      • Key result WE1.10: By the end of Q4, implement a new guided article creation flow where the survival rate of articles created by junior editors on mobile is 5% greater on each deployed wiki than articles created by other means while the volume of surviving articles stays the same or higher, as measured by a controlled experiment.
        • The Article guidance initiative aims to develop new approaches that support editors in creating initial, well-structured contributions to Wikipedia that align with community policies and content quality. As an initial intervention, a new workflow for article creation was implemented last quarter, based on community-editable outlines that encapsulate the guidance for specific types of articles. In Q4, the goal is to run an A/B test experiment to measure the impact on a set of pilot wikis to evaluate the impact. Since the guidance is community-dependent, the experiment preparations will requires collaboration with the communities of the pilot wikis to adapt the system to their needs.

Життєво важливі знання (WE2)

  • Ціль: Зробити більше життєво важливих знань доступними та добре проілюстрованими за різними мовами та темами. Обговорити
    • Контекст цілі: Ця ціль сприятиме зростанню вмісту, який відповідатиме як інтересам дописувачів у певних темах і мовах, так і читацькому попиту на добре проілюстровані життєво важливі знання. Життєво важливі знання — це набір статей, які забезпечують широту і глибину тем, необхідних для корисного мовного проєкту Вікіпедії. Вони визначаються спільнотами з огляду на помітність (значущість), релевантність, прогнозовану читацьку аудиторію та зв'язки між статтями.
    • Ми будемо застосовувати соціотехнічний підхід, підвищуючи ефективність функцій, інструментів і соціальних процесів. Ми будемо спиратися на високоефективні функції продукту, такі як запропоновані завдання, пошук медіа та переклад вмісту, а також будемо сприяти вбудовуванню та розвитку Вікіпедій меншими мовами. Ми будемо підтримувати організаторів Вікімедіа, які залучають, навчають і підтримують дописувачів для роботи над спільними цілями щодо вмісту за допомогою таких спільних проєктів і кампаній, як Вікіпроєкти та кампанії. (За нашими оцінками, щонайменше 300 організаторів є активними щоквартально). Ми також розвиватимемо стосунки з найбільш важливими видавцями, щоб усунути бар'єри для доступу до джерельних матеріалів. (Наразі ми співпрацюємо з понад 100 найбільшими та найкращими світовими базами даних, які доступні лише за передплатою).
    • Щоб переконатися, що наші заходи позитивно впливають на життєво важливі знання, ми будемо вимірювати, як збільшення пріоритетного для спільноти вмісту, так і якість цього вмісту, беручи до уваги такі чинники, як коефіцієнт повернення, кількість цитувань та зображень.
      • Ключовий результат WE2.1: До кінця 2-го кварталу випробувати та оцінити три заходи, які допоможуть дописувачам покращити стан життєво важливого вмісту в їхніх Вікіпедіях.
        • Цей КР висвітлить прогалини в механізмах редагування, таких як виявлення зображень у Вікіпедії, переклад вмісту та кероване створення нових статей. Ми також впровадимо і протестуємо соціотехнічне втручання для підтримки діяльності зі створення вмісту для малих мовних спільнот. Успіх буде вимірюватися в рамках кожної гіпотези.
      • Ключовий результат WE2.2: До кінця четвертого кварталу створити можливості платформи, необхідні для підтвердження нашої спроможності підтримати бачення Абстрактної Вікіпедії у великому масштабі. Ми будемо вважати, що досягли успіху, якщо ми покажемо, що система видає багатий, багатомовний енциклопедичний вміст, використовуючи Вікідані та генерацію природної мови, контролюється спільнотою Вікімедіа та залишається ефективною при широкому розгортанні.
        • Тепер, коли ми можемо використовувати Вікідані для виведення базового текстового вмісту у Вікіпедіях, наступним кроком є продовження розбудови можливостей платформи, які можуть підтримувати Абстрактну Вікіпедію у великому масштабі. Платформа повинна підтримувати багатий, багатомовний вміст, який може контролюватися спільнотою і залишатися ефективним у великому масштабі. Це віховий КР, оскільки ми переходимо від 0 до 1.
      • Ключовий результат WE2.3: До кінця четвертого кварталу розгорнути початкову форму нової вікі для раннього створення спільнотою реферативних статей та створити прототип їх інтеграції у вікі контенту.
        • Цей ключовий результат дає нам можливість наступного року протестувати можливості платформи Абстрактної вікі. Нова, окрема вікі буде містити бібліотеку абстрактних статей, побудовану на Вікіфункціях, і надаватиме можливості платформи, необхідні для подальшої інтеграції в майбутньому абстрактних статей у Вікіпедію.
      • Ключовий результат WE2.4: До кінця другого кварталу узгодити з ФВМ та Вікімедіа Німеччина визначення успіху для покращення технічної інфраструктури, що підтримує критично важливий варіант використання Вікіданих, включаючи метрики та цілі на 2025-2026 фінансовий рік.
        • У серпні 2025 року було створено та укомплектовано команду ФВМ Платформа Вікіданих (Wikidata Platform — WDP) — один керівник продукту та один керівник з технічних питань. Як нове доповнення до програми, яка розроблялася протягом багатьох років технічними та продуктовими командами ФВМ та Вікімедіа Німеччина, відповідно, ця мета відображає наш намір передати відповідальність через узгодження випадків використання, залежностей та ключових критеріїв успіху. Цей КР стане основою для взаємного розуміння проблемного простору, яку ми будемо розвивати протягом решти фінансового року (травень 2026).
      • Ключовий результат WE2.5: До кінця четвертого кварталу наша заміна серверної частини була встановлена ​​паралельно з Blazegraph і здатна підтримувати перехід вибраних користувачів. Ми визначаємо «готовність до міграції» для цього ключового регіону як здатність підтримувати пілотну фазу нашої міграції в першому кварталі 2026-2027 фінансового року.‎
        • Після досягнення прогресу у визначенні критеріїв успіху в рамках WE2.4, ми зараз переходимо до режиму виконання. У наступних двох кварталах ми окреслимо всі змінні, пов'язані з переходом на Blazegraph, у плані міграції, визначимо, які з них є критичними для пілотного запуску, впровадимо їх у нову базу даних RDF та визначимо терміни міграції для всіх вимог, що виходять за рамки наших пілотних персон. Наша робота до запланованого запуску нового бекенду WDQS (орієнтовно, липень 2026 року) буде керуватися вимогами, викладеними в цьому плані.‎

Досвід споживачів (WE3)

  • Ціль: Залучити читачів різних поколінь до участі у Вікіпедії та підтримувати їхню зацікавленість, що призведе до помітного збільшення утримання та активності пожертвувань. Обговорити
    • Контекст цілі: Ця ціль буде зосереджена на утриманні нових читачів за допомогою інноваційних форматів вмісту, основних аудиторій за допомогою покращення звичної зручності читання, а також на забезпеченні довгострокової стійкості шляхом поглиблення читацьких зв'язків і диверсифікації пожертвувань. Ми продовжимо роботу над тим, щоб полегшити пошук вмісту за допомогою нових та більш експериментальних функцій, таких як стислий виклад від штучного інтелекту або персоналізовані «кролячі нори». Ми також будемо працювати над збереженням і покращенням якості читацького досвіду глибше в «читацькій лійці», а також над вивченням можливостей кураторства читання через списки читання та інші види участі, що не пов'язані з редагуванням. Для донорів ця робота і надалі буде зосереджена на диверсифікації джерел доходу всередині платформи.
      • пункт списку побажань Ключовий результат WE3.1: До кінця другого кварталу продемонструвати практично значне збільшення утримання незалогінених читачів, що вимірюється за допомогою A/B-тестування однієї функції на кожній платформі
        • Цей КР буде зосереджений на продовженні інвестування в досвід, який оптимізує нові способи перегляду та вивчення вмісту, часто через використання нових технологій та форматів — представлення наявного вмісту новими та цікавими способами. У цьому фінансовому році ми хотіли б продовжити експерименти з новими функціями, зосередившись на масштабуванні успішних експериментів на інших вікі та платформах. Робота в КР охоплюватиме мобільний і десктопний вебсайт, а також застосунки для iOS і Android і зосередиться на пошуку вмісту (перегляд точок входу і рекомендацій), а також адаптивних форматах навчання (машинні резюме, реміксинг вмісту).
        • Область зацікавленості Списку побажань: Новий досвід споживачів
      • Ключовий результат WE3.2: Збільшити до кінця 2-го кварталу кількість пожертв через небанерні методи або електронну пошту на 5% у річному обчисленні на кожній платформі за допомогою продуктових інтервенцій, які сприяють поглибленню зв'язків і зменшують незгоди для донорів
        • У цьому КР ми продовжимо досліджувати нові точки входу для пожертв та інші можливості перетворення читачів на донорів та утримання їх шляхом поглиблення їхнього зв'язку з вікі, включно з більш персоналізованим вмістом. У співпраці з командою збору коштів РК зосередиться на впровадженні нових точок входу для пожертв та ітерації на існуючих точках входу у застосунках і на вебсайтах.
      • Ключовий результат WE3.3: До кінця другого кварталу продемонструвати практично значне збільшення утримання залогінених читачів, виміряне за допомогою A/B-тестування однієї функції на кожній платформі
        • Цей КР буде зосереджений на покращенні читацького досвіду та навчання для існуючих та досвідчених читачів з метою утримання нашої поточної аудиторії та поглиблення їхнього зв'язку з сайтом, щоб вони могли дізнаватися більше, а також бути готовими та відкритими до пожертвування та редагування. Робота тут буде зосереджена на покращенні читацького досвіду на сайті та в застосунках (покращення читабельності, краща навігація та пошук), а також на розвитку та ітерації наших пропозицій з кураторства та персоналізації (списки для читання, персоналізовані пропозиції, історія користувачів та статей тощо).
      • Ключовий результат WE3.4: До кінця четвертого кварталу видалити всі виявлені блокувальники для розгортань кеш-сайтів невеликого масштабу, які відповідатимуть нашим поточним стандартам якості обслуговування та безпеки відповідно до наших поточних розгортань кеш-сайтів
        • Цей КР буде зосереджений на підтвердженні концепції, що ми можемо покращити продуктивність веб-сайту та зменшити затримки для наших читачів, спростивши нашу інфраструктуру кешування та вдосконаливши процеси розгортання сайту кешування, скоротивши базовий час розгортання з приблизно одного року в середньому до максимум кварталу. Основна увага тут буде зосереджена на завершенні спрощення, розгортанні PoC (перевірка концепції, англ. Proof of concept), проведенні огляду безпеки та підготовці аналітичної записки про те, чи варто продовжувати розгортання наших периферійних кешів у публічних хмарах. Зменшення затримок може призвести до перевіреного збільшення кількості переглядів сторінок і розширення географічного розмаїття читачів.
      • Ключовий результат WE3.5: Поліпшити ідентифікацію донорів — забезпечити, щоб усі залогінені читачі, які дали згоду, могли бути ідентифіковані за статусом донора для персоналізованого досвіду — до кінця 4 кварталу.
        • Ми впровадимо стратегії ідентифікації донорів для забезпечення, щоб усі зареєстровані читачі, які дали згоду, могли бути ідентифіковані за статусом донора, що дозволить створити більш персоналізований та захопливий досвід. Робота над ідентифікацією донорів буде пріоритетною протягом 4 кварталу, щоб у майбутньому підтримати більш ефективні ініціативи з персоналізації та активації.
      • Ключовий результат WE3.6: До кінця 4 кварталу завершити, опублікувати та прокомунікувати стратегію щодо досвіду читачів та споживачів Вікіпедії на різних платформах, визначивши цілі та базові показники, розроблені у співпраці із зацікавленими сторонами та спільнотою, які будуть направляти нашу роботу до 2030 року.
        • Робота над стратегією щодо споживачів буде продовжена, з акцентом на розробці та донесенні стратегії як всередині організації, так і до спільноти, а також на визначенні та встановленні основних показників для споживачів, а також їхніх відповідних базових показників.
      • Ключовий результат WE3.7: Збільшення кількості пожертвувань, зроблених не через банерні або електронні листи, на 10% у порівнянні з попереднім роком на кожну платформу завдяки втручанням у продукти, які сприяють глибшим зв'язкам і зменшують тертя для донорів до кінця третього кварталу.‎
        • У цьому ключовому звіті ми продовжимо досліджувати нові точки входу для пожертвувань та інші можливості для перетворення читачів на донорів та їх утримання шляхом поглиблення їхніх зв'язків з вікі, включаючи більш персоналізований контент. Королівський ключовий етап зосередиться на впровадженні нових точок входу та ітерації існуючих точок входу в додатках та веб-сайтах у співпраці з командою зі збору коштів.‎
      • Ключовий результат WE3.8: До кінця четвертого кварталу масштабувати принаймні один експеримент на кожну платформу (веб-сайт та додатки), який продемонстрував покращення утримання або індикаторний показник для активних читачів у тестовому середовищі, відстежуючи захисний бар'єр, відповідний для функції.
        • Цей ключовий етап зосередиться на масштабуванні функцій, які показали перспективність у покращенні утримання залучених читачів (або пов'язаного індикаторного показника) в веб-сайтах та додатках, на основі результатів експерименту за 1/2 квартал. Це включає масштабування списку для читання в веб-версії (для стимулювання створення облікових записів та внутрішнього рівня рефералів), вкладки активності на iOS (для створення та утримання облікових записів) та потенційно довший аналіз роботи вкладки активності на Android (вже випущено) для перевірки покращень утримання функцій.‎
      • Ключовий результат WE3.9: До кінця четвертого кварталу масштабувати принаймні один експеримент на кожну платформу (веб-версію та додатки), який показав покращення утримання або індикаторний показник для випадкових читачів, що не ввійшли в систему, у тестовому середовищі, відстежуючи захисний бар'єр, відповідний для функції.‎
        • У цьому ключовому звіті ми масштабуватимемо успішні експерименти, які довели свою цінність для читачів, нових та колишніх, які наразі не взаємодіють з вікі-проєктами. Ми масштабуватимемо покращення, зосереджені на досвіді читачів, що не ввійшли в систему, які підтримують пошук знань – досвід пошуку контенту, візуальні презентації та способи обміну (знання, контент, теми, що цікавлять). Цей ключовий показник охоплює мобільні веб-платформи та додатки (iOS та Android).‎
      • Ключовий результат WE3.10: До кінця четвертого кварталу провести принаймні один експеримент на кожній платформі (веб та додатки), який покаже практично значне покращення утримання випадкових читачів після виходу з системи або інший показник показника порівняно з контрольною групою (при цьому утримання випадкових читачів визначається як 21-денне сукупне утримання для веб-сайтів та 14-денне сукупне утримання для додатків).‎
        • Ми продовжуємо інвестувати в експерименти, які доносять цінність Вікіпедії до читачів, нових та колишніх, які наразі не взаємодіють з вікі-проєктами. Ми будемо прагнути протестувати покращення досвіду читачів після виходу з системи, зосереджуючись на пошуку контенту (наприклад, зміст Minerva, семантичний пошук, запитання та відповіді), візуальних презентаціях (наприклад, візуально привабливі картки посилань) та способах обміну (наприклад, дії обміну). Цей ключовий показник охоплює веб-сайти (мобільні пристрої та комп’ютери, хоча з акцентом на мобільні пристрої через аудиторію) та додатки (iOS та Android).‎

Безпека і захищеність (WE4)

  • Ціль: Наші системи за замовчуванням краще захищають облікові записи та приватну інформацію наших редакторів, одночасно пропонуючи редакторам та користувачам з розширеними правами більше можливостей для запобігання зловживанням та реагування на них. Обговорити
  • Ключовий результат WE4.1: До кінця другого кварталу розгорнути дієву та ефективну систему повідомлення про інциденти на всіх наших вікі, яка буде використовуватися та прийнята їхніми спільнотами.
    • Забезпечення безпеки та благополуччя користувачів є основним обов'язком нашої платформи. У багатьох юрисдикціях існують правила, які вимагають від таких онлайн-платформ, як наша, відстежувати і вживати заходів проти домагань, кібербулінгу та іншого шкідливого вмісту на їхній платформі. Невиконання цих вимог може призвести до юридичної відповідальності та регуляторних санкцій.
    • Ми хочемо надати нашим користувачам можливість повідомляти про безпосередні загрози шкоди за допомогою легкодоступного та інтуїтивно зрозумілого механізму звітності, щоб ми могли дізнаватися про такі інциденти та вживати в разі необхідності оперативних заходів. Це крок до того, щоб наші користувачі відчували себе в безпеці під час роботи на нашій платформі. Ми робимо це, впроваджуючи Систему повідомлень про інциденти на наших вікі.
  • Ключовий результат WE4.2: Посилити точність та ефективність інструментів боротьби зі зловживаннями, впровадивши два покращення до кінця другого кварталу.
    • Ми та наша спільнота маємо краще виявляти та запобігати неавтентичній та зловмисній діяльності на вікі. Ми зробимо це шляхом збільшення кількості та якості сигналів, доступних для платформи, об'єднання цих сигналів у інструменти, які ми надаємо користувачам з розширеними правами, та визначення, де ми можемо безпечно встановити автоматичні обмеження на підозрілу діяльність.
    • Ми також бачимо можливості одночасно поліпшити доступність Вікіпедії та інших наших проєктів. Наприклад, один із проєктів полягає в заміні дуже традиційної самокерованої CAPTCHA вікі, яка не дозволяє користувачеві увійти в систему, поки він не вирішить головоломку, на службу оцінки ризиків, яка рідко коли ставить завдання користувачеві. Натомість вона буде тихо позначати облікові записи рівнем підозрілості, який ми зможемо використовувати для вимкнення функціональності, і робити цей статус видимим для модераторів з високим рівнем привілеїв, щоб допомогти їм у роботі.
    • Загалом, проєкти Вікімедіа значною мірою покладаються на блокування IP-адрес для мінімізації зловживань з боку зловмисників. Це стає дедалі менш ефективним для запобігання зловживанням і негативно впливає на добросовісних користувачів, які страждають від блокування IP-адрес та діапазонів IP-адрес. У цьому ключовому результаті ми прагнемо покращити наявні можливості та надати нові інструменти, які дозволять більш точно та ефективно блокувати зловмисників і зменшити побічні збитки, спричинені блокуванням IP-адрес та діапазонів IP-адрес.
    • Щоб оцінити нашу ефективність, ми розглянемо якісні відгуки волонтерів, залучених до роботи з боротьби зі зловживаннями, а також кількісні показники, такі як частота застосування блокувань IP-адрес, впровадження засобів пом'якшення на основі репутації IP-адрес та сигналів браузера, швидкість ймовірної взаємодії з людиною, коли користувача блокують, а також впровадження нових сигналів в інструменти боротьби зі зловживаннями.
    • Робота в рамках цього ключового результату включає вдосконалення виявлення та мінімізації обходу блокування та створення фейкових облікових записів, виявлення інформації про потенційну побічну шкоду, посилення виявлення ботів, надання сигналів волонтерам, які борються зі зловживаннями, підвищення ефективності інтерфейсів інструментів для боротьби зі зловживаннями, вдосконалення показників, пов'язаних зі зловживаннями, а також надання чек'юзерам пропозицій щодо підозрілої активності облікових записів для розслідування.
  • Ключовий результат WE4.3: До кінця четвертого кварталу зменшити кількість великомасштабних атак, які потребують втручання персоналу SRE, на 50% (порівняно з попереднім фінансовим роком)
    • Еволюція ландшафту Інтернету, включаючи зростання масштабних бот-мереж і почастішання атак, зробила наші традиційні методи обмеження масштабних зловживань застарілими. Такі атаки можуть зробити наші сайти недоступними, переповнивши нашу інфраструктуру запитами, або перевантажити здатність нашої спільноти боротися з масштабним вандалізмом. Це також створює невиправдане навантаження на наших редакторів з високими привілеями та технічну спільноту.
    • Нам терміново потрібно покращити нашу здатність автоматично виявляти такі атаки, протистояти їм, а також їх послаблювати або зупиняти.
    • Цього року ми зосередимося на автоматизації виявлення IP-адрес і мереж, які регулярно беруть участь в атаках на нас, а також на зменшенні навантаження, яке можуть створювати на наші системи ці постійно шкідливі суб'єкти.
  • Ключовий результат WE4.4: До кінця другого кварталу розгорнути тимчасові акаунти на 100% наших проєктів таким чином, що особова інформація наших незареєстрованих редакторів доступна для менш ніж 0,1% зареєстрованих користувачів.
    • Тимчасові облікові записи мають на меті покращити приватність і, таким чином, безпеку наших незареєстрованих редакторів, захищаючи їхню особову інформацію (IP-адресу) від публічного перегляду та обмежуючи доступ до неї лише тими, кому вона необхідна для цілей патрулювання. Окрім значного підвищення безпеки користувачів, цей проєкт також важливий для дотримання різних регуляторних вимог.
  • Ключовий результат WE4.5: До кінця третього кварталу оцінити вплив генеративного ШІ на довіру та безпеку, а також визначити заходи щодо продукту, щоб використати можливості та запобігти загрозам для проєктів Вікімедіа.
    • В Інтернеті швидко зростає використання ШІ, а особливо генеративного ШІ. З поширенням ШІ з'являються як можливості для довіри та безпеки, так і загрози. Наприклад, стало легше та дешевше створювати вміст, але модерація стала більш напруженою. Аналогічно, дослідження можна проводити з набагато меншими зусиллями, але важче виявити галюцинації ШІ.
    • Цей проєкт має на меті розширити Оцінку впливу машинного навчання та штучного інтелекту на права людини, оцінивши вплив ШІ на аспекти довіри та безпеки екосистеми Вікімедіа. Це включає:
      • Консультації з користувачами з розширеними правами.
      • Виявлення прикладів зловживань, здійснених за допомогою генеративного ШІ та потенційних заходів для їхнього послаблення.
      • Виявлення можливостей машинного навчання для зменшення навантаження на користувачів з розширеними правами.
      • Проведення експериментів, щоб зрозуміти, на чому слід зосередитися, щоб досягти найбільшого впливу.
  • Ключовий результат WE4.6: До кінця 4 кварталу технічно забезпечити, щоб 100% привілеїв, які дозволяють користувачам виконувати дії, що стосуються безпеки або приватності, могли виконуватися лише обліковими записами, для яких увімкнено двофакторну автентифікацію.
    • Ми маємо посилити безпеку облікових записів користувачів на наших вікі, особливо для користувачів із чутливими дозволами. Основна увага приділяється вимозі, щоб будь-які чутливі дії могли виконуватися лише користувачами, які увімкнули двофакторну автентифікацію (2ФА). Ми створимо більш розширювану систему для забезпечення дотримання привілеїв, яка дозволить уникнути необхідності перевірок та ручного забезпечення дотримання 2ФА, а також розширимо перелік привілеїв, для яких на платформі необхідно увімкнути 2ФА.
    • У рамках цього ми вдосконалимо наші системи автентифікації та відновлення, щоб ми (ФВМ) та наші користувачі могли легше підтримувати більш суворе ставлення до 2ФА. Ми розширимо загальну доступність двофакторної автентифікації на всій платформі, щоб кожен користувач міг увімкнути її за бажанням і щоб вона була увімкнена перед наданням доступу до чутливих привілеїв. Ми також зосередимо свою увагу на зменшенні операційного навантаження на наші системи відновлення облікових записів та підтримки, що допоможе оптимізувати процеси скидання та відновлення облікових записів. Ми також маємо намір поліпшити зручність використання нашої реалізації 2ФА, пропонуючи користувачам більше можливостей для захисту своїх облікових записів та уникнення випадкового блокування.
  • Key result WE4.7: Publicly conclude our bot detection trial, by the end of Q4.
    • This KR is a focused, one-quarter effort to evaluate the results of this trial, to decide inside WMF about whether to maintain and expand this system across our wikis, and to publicly publish the results of the trial and our path forward.
  • Key result WE4.8: Simplify the patrolling of temporary accounts, by making it quicker to identify and address abuse, by the end of Q4.
    • The purpose of temporary accounts is to continue to safely support participation from good-faith unregistered editors. However, some anti-vandalism workflows became more complicated by the release of temporary accounts. To ensure temporary account vandalism can be sustainably managed, we will make it easier and quicker for patrollers to understand and respond to temporary-account activity, both good- and bad-faith.
      We will surface clusters of related temporary accounts to patrollers, while also exploring other interventions that could improve early identification and rapid response.
  • Key result WE4.9: Empower volunteer investigators to deter and block more inauthentic activity on wikis where they actively review flagged accounts, as measured by a 20% increase in the rate of mitigating actions on those accounts, by the end of Q4.
    • For Q3 and Q4, recognizing the strategic potential that Suggested Investigations has demonstrated, we will invest in deploying new signals independent of bot detection, and will set aside time to prioritize a variety of efficiency and quality-of-life features that have been requested by SI users since its original MVP release.
  • Key result WE4.10: By the end of Q4, we'll increase hCaptcha bot detection coverage from 18% to 100% of account creations and from 18% to 90% of higher risk edits.
    • In Q3, we concluded our hCaptcha trial, during which we enabled hCaptcha during account creation, and later expanded it to include new users on the desktop wikitext editor, on eight large Wikipedias, including English Wikipedia. Based on the results of that trial, we’re now expanding hCaptcha to more editing interfaces and more wikis. Our main priority will be expanding what we currently have to all wikis, but we’ll also focus on new avenues to (discussion tools, uploads), as well as categories of users whose actions will be protected by hCaptcha.
  • Key result WE4.11: By the end of Q4, complete an IRS trial on enwiki with a graduated deployment, reaching at least 50% of logged in users and resulting in 5 new reporting metrics.
    • We are trialing an incident reporting system (IRS) on English Wikipedia that is designed to help less experienced community members more easily report potentially bad behavior to the community-managed place that can best deal with it. For more rare and severe cases, it also provides a form to directly report imminent threats of harm to the WMF Trust and Safety team.
    • This trial will be primarily focused on calibrating the first use case: helping editors report potentially bad behavior, without overloading the system.
    • During the trial, we will focus on monitoring the volume of new reports, checking that reports are routed correctly, and identifying any immediate issues. We will be coordinating closely with all community members to fix bugs if they arise, and to otherwise streamline the process. For example, we are exploring some ways to tighten the user experience and help people more directly submit their reports, which we may deploy and measure during the trial as well.
  • Key result WE4.12: By end of Q4, we will have defined a detection pipeline for classifiers that automatically detect English Wikipedia policy-prohibited content, and evaluated the impact of at least one classifier detecting at least one type of prohibited content, validated against community datasets, on its potential for reducing volunteer workload.
    • We want to support volunteers and UWERs by reducing work needed to remove harmful content from the projects, to enable volunteers to handle more difficult cases.
    • In this quarter, we want to gain experience in defining repeatable processes for building detection pipelines for different types of content, and take first steps to evaluate these pipelines safely on large projects (A/B tests, log-only mode deployments, etc). We will start with a focus on content that should very likely be suppressed, such as threats, or disclosure of personal information.
    • We plan to expand on these initiatives in FY26-27 work as part of an overhaul of anti-abuse tooling that supports UWERs and volunteers in reducing the time to mitigation for bad-faith activity.

Відповідальне використання інфраструктури (WE5)

  • Ціль: Розробники та повторні користувачі отримують доступ до вмісту знань через спеціально створені шляхи, забезпечуючи стійкість нашої інфраструктури та відповідальне повторне використання вмісту. Обговорити
    • Контекст цілі: Ця ціль буде зосереджена на створенні шляхів для відповідального повторного використання вмісту.
    • Вікімедіа містить найбільшу колекцію знань в мережі, куратором яких є людина. Це зробило нашу інфраструктуру знань неоціненним місцем призначення не лише для людей, але й для автоматичних споживачів даних. Наш вміст потрапляє до пошукових систем, платформ соціальних мереж, електронної комерції, а з появою ШІ використовується для навчання великих моделей машинного навчання. Споживачі отримують дані, скануючи сторінки, використовуючи API та завантажуючи вміст — як правило, без зазначення авторства. У світі неавтентифікованого трафіку ми не можемо надійно відрізнити одного користувача від іншого, що значно обмежує наші можливості щодо забезпечення відповідального використання нашої інфраструктури: Як ми можемо продовжувати розширювати можливості нашої спільноти, одночасно встановлюючи межі для автоматичного споживання вмісту? Як ми можемо спрямувати користувачів до бажаних, підтримуваних каналів? Які настанови нам потрібні, щоб стимулювати відповідальне повторне використання вмісту? Як ми можемо сприяти згуртованості розробників та створювати продукти, що відповідають потребам як волонтерів-розробників, так і штатних працівників та користувачів, що повторно використовують вміст? Хоча ці питання не є новими, нагальність їх вирішення зростає в геометричній прогресії: Починаючи з 2024 року, ми спостерігаємо різке зростання кількості запитів, причому більша частина з них припадає на скрейпинг-ботів, які збирають навчальні дані для робочих процесів і продуктів зі штучним інтелектом. Навантаження на нашу інфраструктуру надмірне і ставить під загрозу доступ людей до знань: Нам потрібно діяти негайно, щоб відновити здоровий баланс, щоб ми могли ефективно підтримувати проєкти Вікімедіа та забезпечувати стійкий успіх нашої місії.
      • Ключовий результат WE5.1: До кінця четвертого кварталу 50% запитів до програмних каналів доступу можна буде віднести до відомого розробника чи застосунку.

Наразі ми маємо обмежені способи визначити, хто відповідає за автоматизований трафік, і, на відміну від вікі, маємо обмежені способи зв'язатися з користувачами або регулювати їхній доступ. Ми спостерігаємо значне збільшення обсягу зовнішнього автоматизованого трафіку, що не є для нас посильним і ставить під загрозу доступ людей до знань. Ми прагнемо збільшити відсоток автоматизованого трафіку, який приписується відомому обліковому запису, вимагаючи автентифікації та авторизації на основі багаторівневих рівнів доступу для великих обсягів скрейпингу та використання API. Це допоможе нам визначити, хто повторно використовує вміст у великих масштабах, що дасть нам змогу захистити нашу інфраструктуру та вдосконалити управління навколо добросовісного використання, водночас ефективніше задовольняючи їхні потреби. Ми також дослідимо, як краще підтримувати технічну спільноту, створюючи більш згуртоване середовище для розробників, яке захищатиме привілейований доступ для членів спільноти та надаватиме розробникам нові функціональні можливості.

      • Ключовий результат WE5.2: До кінця 4 кварталу 70% кінцевих точок мережевих API Вікімедіа будуть підтримуватися спільною інфраструктурою.
        • Ми прагнемо покращити досвід та сталість наших шляхів розробки, пропонуючи більш послідовні, стабільні та легкодоступні веб-API для всіх розробників Вікімедіа. Ми спростимо наші пропозиції API, запровадивши більш централізовану інфраструктуру для основних можливостей API, що дозволить нам мати послідовні шляхи та управління для: специфікацій та документації OpenAPI, ідентифікації розробників та контролю доступу, забезпечення виконання політик API, маршрутизації, керування версіями та обробки помилок. Завдяки оптимізації наших пропозицій API ми зробимо створення інструментів, ботів, дослідницьких проєктів та функцій, що служать місії Вікімедіа, швидшим, простішим та приємнішим. Цього року основна увага приділяється створенню базової інфраструктури та функцій, з метою MVP, щоб 70% кінцевих точок API впровадили принаймні одну функцію з 3 основних областей інфраструктури API: як API створюються для забезпечення послідовності та якості; як API надаються розробникам Вікімедіа; та як базова інфраструктура використовується для обслуговування, спостереження та контролю доступу до наших API. Цей підхід підтримує багатопоколіннєве майбутнє місії, зменшуючи витрати на обслуговування інфраструктури API, підвищуючи видимість та контроль доступу для боротьби з недобросовісними діячами та сприяючи зміцненню спільноти розробників.
      • Ключовий результат WE5.3: До кінця четвертого кварталу буде опублікована та розміщена на всіх сайтах Вікімедіа нова система атрибуції для веб, застосунків, голосових помічників та ВММ, з двома демонстраційними версіями повторного використання, що сприятимуть вимірюваному залученню, а також з одним зовнішнім партнером з повторного використання, який перейде на найкращі практики атрибуції.
        • Щоб підвищити рівень належного атрибутування вмісту Вікімедіа, ми надамо чітку систему щодо найкращих практик, які сприятимуть відповідальному повторному використанню. Це включає створення настанов з атрибуції для ключових платформ (веб, застосунки, голос, мультимедіа) та демонстрацію щонайменше двох практичних прикладів, що висвітлюють зразкові застосування вмісту Вікімедіа. Приклади результатів включають заохочення медіаорганізацій посилатися на зображення Вікісховища, заохочення пошукових систем до більш ефективного пошуку релевантних даних Вікімедіа або заохочення ШІ-помічників до прозорої та відповідальної інтеграції знань з Вікіпедії, що підвищує довіру до їхньої надійності. Посилення практики атрибуції не лише підвищує публічну обізнаність та стимулює залучення до проєктів Вікімедіа, але й допомагає створити відповідальні та нові способи реміксу знань і запобігти неправомірному використанню.
      • Ключовий результат WE5.4: Зменшити обсяг трафіку, що генерується скрейперами, на 20%, якщо вимірювати його за частотою запитів, і на 30% — за смугою пропускання
        • Скрейпинг існував завжди: пошукові системи покладалися на Вікіпедію для надання інформації своїм користувачам протягом десятиліть; однак останнім часом з'явилася ще одна велика мотивація для скрейпингу наших даних: це найбільший багатомовний набір знань, який ви можете знайти в Інтернеті, і це фундаментальний інструмент для навчання великих мовних моделей. Це стосується як нашого енциклопедичного вмісту, так і нашого мультимедійного репозиторію Вікісховища, який є неоціненним для моделей машинного навчання, що генерують зображення.
        • Як наслідок, за останній рік ми спостерігали значне збільшення кількості скрейперського трафіку, а також пов'язаних з ним інцидентів зі стабільністю сайту: Інженерам з надійності сайту неодноразово доводилося в кожному конкретному випадку обмежувати швидкість або забороняти роботу пошукових роботів, щоб захистити нашу інфраструктуру. Скрейпинг став настільки помітним, що наша вихідна смуга пропускання збільшилася 2024 року на 50%. Понад те, нещодавній аналіз показав, що принаймні 65% наших найдорожчих запитів (тих, які ми не можемо обслужити з наших кешуючих серверів і які замість цього обслуговуються з основних баз даних) виконуються ботами.
        • Наші обчислювальні ресурси надзвичайно обмежені порівняно з обсягом трафіку, який ми генеруємо, тому нам доводиться визначати пріоритети, кого ми обслуговуємо цими ресурсами, і ми хочемо надавати перевагу людському споживанню, а також за допомогою наших обмежених ресурсів підтримувати проєкти Вікімедіа та дописувачів.

Пришвидшити шлях до Результатів продукту (WE6)

  • Ціль: Розробники Вікімедіа швидко і впевнено надають свої продукти кінцевим користувачам. Обговорити
    • Контекст цілі: Щоб бути ефективними у досягненні 4-х стратегічних основ, розробники Вікімедіа повинні витрачати свій час і зусилля на діяльність з високим рівнем впливу, яка призводить до створення якісних продуктів якомога раніше. Надто складні робочі процеси, брак стандартних інструментів та нестабільні системні компоненти стають на заваді цим результатам.
    • Ця робота ґрунтується на імпульсі, який ми набрали за останні 2 річні плани, розвиваючи Медіавікі як платформу, а також програмне забезпечення, що підтримує її розробку і розгортання. Цього року ми зосередимося на створенні надійнішого середовища для розробників, спрощенні робочих процесів перед виробництвом, а також зменшенні ризиків, пов'язаних з платформою та інфраструктурою.
      • Ключовий результат WE6.1: До кінця четвертого кварталу кількість помилок, що блокують роботу, які виходять за межі тестових вікі, зменшено на 10%.
        • У 2024 році розробникам 144 рази доводилося повертатися до роботи через надзвичайні ситуації, що перешкоджали розгортанню Медіавікі. У багатьох з цих випадків помилки були виявлені після розгортання в тестових вікі, тобто проблема досягла потенційної аудиторії в мільярди користувачів. Ми не можемо контролювати той факт, що помилки існуватимуть, але виявлення їх раніше означало б, що потрібно менше героїчної роботи. Це також підвищить впевненість розробників у тому, що коли щось потрапить до реального виробництва, пожежі не станеться.
        • Ми будемо виявляти ці помилки раніше, надаючи середовище, необхідне розробникам для впевненого доставлення і тестування їх коду протягом усього життєвого циклу розробки і розгортання. Ми також повинні переконатися, що ці покращення не відбуваються коштом швидкості роботи розробників.
      • Ключовий результат WE6.2: До кінця 4 кварталу 4 кроки з контрольного списку перевірки виробничої готовності можуть бути виконані без втручання SRE
        • Запуск нової послуги або функції у виробництво наразі залежить від виконання 24 кроків, кожен з яких, як правило, потребує підтримки SRE (Site reliability engineering — Інженерного забезпечення надійності сайтів). Ми створили програму амбасадорів SRE, щоб втручатися на більш ранніх стадіях циклу розробки та розбудовувати потенціал самих команд розробників, але багато завдань мають бути повністю самодостатніми. Наразі це зводиться до ручної, повторюваної, автоматизованої роботи, яка лінійно масштабується залежно від кількості команд розробників. Команда SRE не зможе цього витримувати в довгостроковій перспективі.
        • У минулому значна частина цієї роботи була абстрагована від команд розробників шляхом підтримки набору спільних бібліотек та найкращих практик для взаємодії з нашою платформою. Від них відмовилися, коли ми перейшли на нову інфраструктуру Kubernetes, і для них немає прямої заміни. Надаючи подібні бібліотеки, документацію та навчання, які відповідають тому, як ми будуємо та розгортаємо речі сьогодні, ми віримо, що зможемо зменшити обсяг залучення SRE перед розгортанням нової послуги або функції у виробництво.
      • Ключовий результат WE6.3: До кінця четвертого кварталу 100% переглядів сторінок Вікіпедії обслуговуються через Parsoid
        • Parsoid пропонує розширені можливості для розвитку вікітексту та забезпечення майбутнього платформи. Одночасна підтримка двох парсерів не є життєздатною в довгостроковій перспективі, оскільки це збільшує технічний борг і складність. Крім того, успіх деяких нових проєктів, таких як Вікіфункції, залежить від широкої доступності Parsoid.
        • Ми масштабуємо розгортання до менших проєктів і цього року будемо готові до Вікіпедій. Обслуговування всіх переглядів сторінок Вікіпедії через Parsoid є найважливішою наступною віхою. Окрім самого розгортання, ця робота також включає розв'язання проблем продуктивності та ефективне інформування читачів і редакторів про вплив проєкту.
      • Ключовий результат WE6.4: До кінця 2-го кварталу щонайменше два виявлені ризики, які загрожують нашій здатності продовжувати розгортати чи масштабувати вікі, були послаблені або зменшені до прийнятного рівня
        • За допомогою кількох цілеспрямованих ініціатив ми зменшимо або послабимо кілька ризиків масштабування, надійності чи безпеки, які ми визначили як ймовірну потенційну загрозу зростанню та стабільності нашої платформи і наших публічних проєктів.
        • Наприклад, ми проведемо рефакторинг структури основних баз даних Вікісховища, щоб гарантувати, що його зростання не буде обмежене можливостями наявного серверного обладнання протягом наступних кількох років. Ми також оновимо PHP, мову програмування, на якій працює Медіавікі та пов'язані з нею сервіси, до більш сучасної версії. Інші виявлені ризики, ймовірно, вимагатимуть впровадження додаткових заходів безпеки для захисту і зміцнення нашої інфраструктури.
      • Key result WE6.5: By the end of Q4, determine the feasibility of and next steps for scalable cross-wiki code collaboration and logged-in reader support.
        • One of the central features of wikis is collaborative content creation. In the context of the Wikimedia movement, the collaboration needs are very specific to the evolution of the projects and the challenges that arise at the scales that some of the larger projects operate in.
        • Code collaboration (cross-wiki or on-wiki) is a legitimate need and should be accommodated. This is less a single problem and more a problem space that includes several overlapping problems around code (templates & modules primarily) and solving problems in this space requires shared understanding around priorities that are most impactful.
        • With an experimentation mindset, we're exploring a leaner approach to test shared code libraries that could improve cross-wiki collaboration in a small and controlled environment. This means we will go through a phase of technical feasibility and scope exploration to approach the experiment roll-out in small iterations to collect insights that can help us decide how we want to tackle the aforementioned problem. Our intention is to demonstrate our learnings and progress in the Wikimedia Hackathon 2026.
        • Similarly, if we want to improve the experience of logged-in users, we need to know where the performance gains are, what product work will make demands, and what a sustainable approach will look like for this work next FY. Research in this area will set us up for starting platform work quickly next FY.
      • Key result WE6.6: By end of Q4, developers are able to get the results of MediaWiki Core CI in under 10 minutes.
        • Our current median CI cycle time baseline is over 24 minutes while a DevEx industry standard for high performing teams is 10 minutes or less.
        • To bridge this gap, we're planning to optimize the CI workflows, address main bottlenecks such us browser tests by optimizing how we run them, the underlying testing framework and its configuration.
        • By slashing median CI wait times from 24 to 10 minutes we ensure the rapid feedback loop needed to test and fix issues quickly, significantly accelerating iteration speed. Additionally, improving this metric speeds up merge times, shortening the time between a change being ready and being available for deployment, which directly contributes to the top-level OW5 metric of making it "easier and faster to build products".
      • Key result WE6.7: By end of Q1 of 2026-27 fiscal year, developers are able to test MediaWiki code in production within 1 day of it being merged.
        • Currently, on average developers can test their code on production ~4 days after merging. By shrinking this time, developers can test sooner, and by improving test environments they will have more confidence that their tests will result in fewer bugs reaching production.

Сервіси сигналів і даних (SDS)

Метрики (SDS1)

  • Ціль: Особи, які приймають рішення, використовують більш достовірні та своєчасні метрики для обґрунтованого прийняття продуктових і стратегічних рішень. Обговорити
    • Контекст цілі: Ми використовуємо метрики для обґрунтування рішень Фонду щодо того, на що слід зосередити наші зусилля, щоб якнайкраще служити Руху. Однак деякі з наших каналів передачі даних схильні до збоїв, що спричиняє затримки в доставці. Коли виникають проблеми з даними, час на їх виявлення та розв'язання занадто великий. Крім того, багато наших наборів даних не оптимізовані для зручного дослідження тенденцій і не містять вимірів, важливих для інтерпретації даних. Ці проблеми уповільнюють і обмежують нашу здатність оцінювати метрики.
    • У 2025-2026 фінансовому році ми зосередимося на конкретних випадках використання річного плану для усунення прогалин у якості даних у наших поточних каналах, налагодження інфраструктури та процесів для моніторингу та розв'язання проблем якості даних, а також на наданні інструментів, які дозволять особам, що приймають рішення, розуміти тенденції.
    • Один із випадків використання стосується того, як ми вимірюємо трафік людей і ботів. Зростання автоматизованого трафіку в останні кілька років ускладнило розуміння ступеня того, наскільки люди взаємодіють із проєктами Вікімедіа та сприяють їх розвитку. Ми прагнемо поліпшити нашу здатність оцінювати патерни трафіку людей і ботів, які є критично важливими даними для планування та прийняття рішень щодо продукту.
      • Ключовий результат SDS1.1: До кінця першого кварталу аналітики, які використовують метрики перегляду сторінок, мають доступ до базових показників якості даних та показників продуктивності евристики виявлення автоматизованого трафіку.
        • За допомогою гіпотез, досліджених у цьому КР, ми прагнемо виявити прогалини в наших поточних евристиках виявлення автоматизованого трафіку і зрозуміти, де вони не можуть належним чином класифікувати трафік перегляду сторінок. Ці знання допоможуть поліпшити потоки даних, які генерують і класифікують показники перегляду сторінок. Крім того, ми визначимо показники якості даних для моніторингу та вимірювання покращення точності даних.
        • Цей КР закладе основу для наступного КР, спрямованого на реалізацію необхідних удосконалень в потоках даних, визначених тут. Показники якості даних, встановлені на цьому етапі, слугуватимуть орієнтирами для оцінки ефективності цих майбутніх удосконалень.
      • Ключовий результат SDS1.2: До кінця першого кварталу вміст набору даних історії вмісту медіавікі буде доступний через експорт файлів із щотижневими гарантіями доставки (SLO — цілі рівня обслуговування). Експортовані дані файлів матимуть паритет у порівнянні з традиційним конвеєром експорту XML Dumps 1.
        • Метою КР 1.4 на 2024/25 фінансовий рік було усунення залежності від щомісяця оновлюваних наборів даних mediawiki_wikitext_history та mediawiki_wikitext_history_current для трьох найважливіших низхідних потоків та надання альтернативного набору даних із гарантованими щотижневими SLO.
        • Хоча КР 1.4 на 2024/25 фінансовий рік допоміг зменшити проблеми з надійністю для найбільш важливих залежних потоків, залишилися потоки з ненадійним застарілим джерелом вхідних даних. Їх також слід перенести, як і файлове джерело вхідних даних, до самого набору даних історії вікітексту.
      • Ключовий результат SDS1.3: До кінця другого кварталу система виявлення ботів буде включати один додатковий сигнал і генерувати автоматичні сповіщення про аномалії.
        • У всій Фундації команди приймають рішення щодо продукту та фінансування на основі можливості визначити різницю між читачами-людьми та автоматизованим трафіком. Платформа даних є центральним сховищем сигналів для виявлення ботів та пакетного аналізу. На основі гіпотез, які ми розглянули протягом першого та другого кварталів, ми плануємо розпочати впровадження нових сигналів для виявлення ботів, щоб підвищити точність нашого аналізу автоматизованого трафіку, а також зробити процес впровадження нових сигналів ефективним та відтворюваним.
      • Ключовий результат SDS1.4: До кінця другого кварталу особи, які приймають рішення, матимуть чітке уявлення про поточний стан аналітики, наданої нашими організаційними метриками. Ми будемо вважати, що досягли успіху, якщо надамо презентацію для засідання Ради, яка міститиме аналіз наших метрик як в екосистемі Вікімедіа, так і в ширших інтернет-тенденціях та викликах на ринку.
        • Інформація, отримана з наших організаційних метрик, використовується для прийняття безлічі рішень у фонді, включаючи рішення про те, як ми створюємо наш продукт, як розподіляємо ресурси інфраструктури та як збираємо кошти. Водночас ландшафт Інтернету еволюціонує, а автоматизований трафік, зокрема, впливає на наші показники. Мета полягає в тому, щоб керівництво Фонду прийшло на засідання Ради в грудні з чітким описом загроз для екосистеми Вікімедіа та можливостей в ній, підкріпленим безсумнівним аналізом внутрішніх метрик та зовнішніх тенденцій. Ми зможемо розповісти цю історію, зібравши аналітику, метрики та дані, які дають нам впевненість щодо:
          • Тенденцій у наших внутрішніх показниках читацької аудиторії (переглядів сторінок)
          • Тенденцій у нашій екосистемі авторів
          • Тенденцій із зовнішніх даних та порівняльних показників конкурентів
          • Аналітики з внутрішніх та зовнішніх досліджень і надійних наукових досліджень
      • Key result SDS1.5: By the end of FY25-26 Q4, analytics bot detection will incorporate 2 signals calibrated against 1 trusted classification.
        • In Q1/Q2, SDS1.3 addressed the big gap in incident detection time and analyzed additional signals for bot detection. We learned that:
          • Modern and feasible signals come with a number of caveats and uncertainties that need to be expressed in our metrics.
          • Evaluating the quality of our model, as well as doing robust analysis of signals to enable future iteration, will require labeled data, trusted by definition and preferably sourced from independent systems (formerly called “ground truths”).

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

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

Платформа для експериментів (SDS2)

  • Ціль: Менеджери продукту можуть швидко, легко і впевнено оцінювати вплив змін функцій продукту у Вікіпедії. Обговорити
    • Контекст мети: Щоб уможливити і прискорити прийняття рішень, на основі даних, про розробку функцій продукту, менеджери продукту потребують платформи для експериментів, на якій вони можуть визначати функції, вибирати цільові аудиторії користувачів і вимірювати вплив. Прискорення часу від запуску до аналізу є критично важливим, оскільки скорочення часу для дослідження прискорить експерименти і, зрештою, інновації. Ручні завдання та індивідуальні підходи до вимірювання були визначені як бар'єри на шляху до швидкості. Ідеальний сценарій полягає в тому, що менеджери продуктів можуть пройти шлях від запуску експерименту до виявлення результатів з мінімальним ручним втручанням інженерів та аналітиків або взагалі без нього.
    • У наступному фінансовому році ми зосередилися на Вікіпедії, тому що саме там команда Ключового досвіду зацікавлена в експериментах (організаційна стратегія передбачає, що ми подвоюємо зусилля у Вікіпедії), а також тому, що це дозволяє нам сфокусуватися і чіткіше сигналізувати, з якими командами та проєктами ми працюємо. Інші команди використовували компоненти експериментальної платформи і можуть продовжувати це робити, але це використання не буде в центрі уваги цієї цілі.
      • Ключовий результат SDS2.1: До кінця другого кварталу забезпечити завершення щонайменше двох повних циклів експериментів з використанням експериментальної платформи.
        • Оскільки організація все більше наголошує на прийнятті рішень щодо продукту на основі даних, ми повинні зробити експерименти доступними для всіх команд продукту, а не тільки для тих, хто має спеціальні навички. Команди продукту потребують спільних стандартів, інструментів та інфраструктури, які дозволяють їм:
          • Швидко тестувати ідеї серед наших користувачів по всьому світу
          • Вимірювати вплив змін у продукті за допомогою стандартизованих метрик
          • Прозоро ділитися результатами з зацікавленими сторонами нашого Руху
        • Чому ми переходимо від зосередження на кількості «задіяних команд» до «завершених експериментів»
        1. Стратегічна узгодженість: це основна метрика успіху платформи
        2. Підхід на основі даних: наше дослідження користувачів (у процесі) показує, що готовність команд в організації є різною, тоді як веб-команда підтвердила зацікавленість у двох конкретних експериментах.
        3. Оптимізація ресурсів: розгортання нашої платформи, як мінімально життєздатного продукту (MVP), вимагатиме інтенсивного навчання, тому в найближчій перспективі ефективніше буде зосередитися на можливостях для експериментів, а не розкидати сили на кілька команд. Ми плануємо просуватися до загального випуску і не хочемо знову інвестувати в навчання команд, якщо цього можна уникнути.
        4. Орієнтованість на майбутнє: відгуки про завершені цикли експериментів будуть більш ефективними для вдосконалення нашої платформи, ніж висновки з часткового або неповного впровадження. У міру просування до загального випуску, зосередження уваги на завершенні експериментів дозволяє уникнути інвестицій у тимчасові підходи, які потрібно буде переробляти.
        • Ми проводимо дослідження користувачів, щоб визначити потреби та вимоги різних команд: опитування та інтерв'ю заплановані на другу половину травня 2025 року, щоб уточнити потреби команди продукту. Після завершення дослідження ми складемо календар експериментів, який можна буде використовувати для встановлення наступних цілей КР та визначення пріоритетів.
      • Ключовий результат SDS2.2: До кінця третього кварталу результати щонайменше одного веб-експерименту можна буде проаналізувати та переглянути в GrowthBook.‎
        • Після тривалого та виснажливого процесу ми нарешті прийняли рішення інтегрувати GrowthBook як стороннє рішення для експериментів, яке пропонує позначення експериментів, автоматизований аналіз та інформаційні панелі з підтримкою метрик guardrail. Experiment Platform має намір замінити інтерфейс користувача для визначення та розгортання експериментів (1) та конвеєр аналітики експериментів (5) на GrowthBook.‎
        • Через ризики, пов'язані з цією інтеграцією, команда Experiment Platform вважає, що GrowthBook слід інтегрувати спочатку як конвеєр аналітики експериментів, оскільки він не перериває роботу та є найбільшим джерелом ризику.‎
        • Архітектурні рішення, які ми прийняли протягом SDS2 за 2024/25 фінансовий рік, та модульність GrowthBook дозволяють нам замінювати частини Experimentation Lab поза порядком, тобто співробітники WMF можуть визначати та розгортати експерименти за допомогою інтерфейсу користувача xLab, одночасно аналізуючи їх за допомогою GrowthBook. Крім того, ми можемо паралельно запускати поточний конвеєр аналітики експериментів та GrowthBook, що дозволяє проводити порівняння, а також тестування прийняття користувачами в реальних сценаріях.
      • Key result SDS2.3: By the end of Q4, all new Test Kitchen experiments are configured in GrowthBook.
        • After having enabled WMF staff to use GrowthBook for analyzing experiment results, the Experiment Platform team held a design sprint to assess options for experiment configuration. The decision was to use GrowthBook as the source of truth for experiment configuration but keep Test Kitchen UI (TKUI) as the source of truth for instrument configuration.
          In making GrowthBook the source of truth for experiment configuration, we aim to:
          • Reduce coordination when running an experiment
          • Enable more frequent and repeatable experimentation
          • Clearly delineate between instruments and experiments
          • Move toward a mental model centered on metrics rather than instruments
      • Ключовий результат SDS2.4: Щонайменше 14 з 20 команд розробників продуктів використовували Test Kitchen для прийняття стратегічного рішення щодо ініціативи OKR до кінця четвертого кварталу.‎
        • Робота, виконана в рамках SDS2.1, виявила важливе розуміння: створення експериментальної платформи недостатньо — команди розробників продуктів та технологій стикаються з деякими перешкодами для впровадження. Навіть якщо команди бачать цінність, їм часто не вистачає часу, інфраструктури, інструментів або впевненості, щоб розпочати. ​​Крім того, вони можуть зіткнутися з технічними перешкодами, які потрібно буде вирішити за допомогою продуманого партнерства.
        • Ключовий результат SDS2.4 зміщує нашу увагу з розробки на масштабування впровадження. Продовжуючи співпрацю з командами під час їхньої адаптації до платформи, долаючи технічні бар'єри та надаючи практичну підтримку міграції, ми прагнемо консолідувати експерименти на Test Kitchen як єдиній платформі для команд розробників продуктів, забезпечуючи швидкі цикли самостійного тестування, що зменшують залежність від інженерної та аналітичної підтримки.
        • Цей ключовий етап був запланований після того, як ми вирішили розділити SDS2.2 на дві частини, що вплинуло на нумерацію. SDS2.3 – це майбутній ключовий етап, який є послідовним після GrowthBook для Experiment Analytics.

Майбутні аудиторії (FA)

Майбутні аудиторії (FA1)

  • Ціль: Фонд Вікімедіа має рекомендації щодо втілення стратегічних інвестицій, які допоможуть нашому руху служити новим аудиторіям в умовах мінливого Інтернету. Обговорити
    • Контекст цілі: Через постійні зміни в технологіях і онлайновій поведінці користувачів (наприклад, зростання переваги отримання інформації через соціальні застосунки, популярність короткого відео, розвиток генеративного ШІ) рух Вікімедіа стикається з викликами у залученні та утриманні читачів і дописувачів. Ці зміни також приносять можливості служити новим аудиторіям, створюючи і доставляючи інформацію новими способами. Однак ми як рух не маємо чіткої, заснованої на даних картини переваг і компромісів різних потенційних стратегій, які ми могли б застосувати для подолання викликів або використання нових можливостей. Наприклад, чи варто нам…
      • Інвестувати у великі нові функції, такі як чат-боти?
      • Нести знання Вікімедіа та створювати шляхи для внеску до популярних сторонніх платформ?
      • Ще щось?
    • Щоб Вікімедіа стала проєктом для багатьох поколінь, ми перевіримо гіпотези, щоб краще зрозуміти і порекомендувати перспективні стратегії для Фонду Вікімедіа та руху Вікімедіа, які слід втілювати, щоб залучати й утримувати майбутні аудиторії.
      • Ключовий результат FA1.1: В результаті експериментальних досліджень та рекомендацій Майбутніх аудиторій до кінця третього кварталу принаймні одна ціль або ключовий результат, що належить команді за межами Майбутніх аудиторій, присутній у проєкті річного плану на наступний рік.
        • З 2020 року Фонд Вікімедіа відстежує зовнішні тенденції, які можуть вплинути на нашу здатність служити майбутнім поколінням споживачів і дописувачів знань і залишатися квітучим рухом вільних знань для наступних поколінь. Майбутні аудиторії, невелика команда дослідників, буде:
          • Проводити швидкі, обмежені в часі експерименти (маючи на меті щонайменше три експерименти на фінансовий рік), щоб дослідити шляхи, як успішно впоратися з цими тенденціями
          • На основі результатів експериментів надавати рекомендації щодо нових неекспериментальних інвестицій, які повинен здійснювати ФВМ, тобто нових продуктів або програм, над якими повинна працювати повна команда або команди, протягом нашого звичайного річного періоду планування.
        • Цей ключовий результат буде досягнутий, якщо в проєкті річного плану на наступний фінансовий рік з'явиться принаймні одна ціль або ключовий результат, що належить команді за межами Майбутніх аудиторій, і керується рекомендацією Майбутніх аудиторій.

Соціальне відео (FA2)

  • Ціль: Молоді люди (віком до 25 років) люблять Вікіпедію, навчаються з неї, взаємодіють з нею та діляться вмістом на платформах, де вони люблять проводити час онлайн. Обговорити
    • Контекст цілі: Експерименти команди Майбутніх аудиторій з короткометражними відео цього фінансового року показали, що ми можемо охопити молоду аудиторію на цих платформах, але наші дані про стан бренду показують, що наших поточних інвестицій недостатньо, щоб протистояти зниженню обізнаності та прихильності до Вікіпедії серед аудиторії покоління «Z».
    • Щоб забезпечити ефективне охоплення та залучення цього покоління, ми вважаємо, що нам потрібно буде застосувати різноманітні тактики та значно збільшити нашу участь у таких сферах, як платний маркетинг та маркетинг впливу, креативні кампанії, реагування на тенденції та підвищення рівня експериментування на цих каналах.
    • Ми очікуємо, що виклики, з якими ми стикаємося, вимагатимуть суттєвіших інвестицій, щоб допомогти нам їх подолати, зокрема в зусиллях Комунікації та Маркетингу, спрямованих на залучення користувачів, а також співпраці між відділами над створенням нових продуктів і досвідів, спрямованих на збільшення присутності бренду Вікіпедії та її вмісту на цих платформах.
      • Ключовий результат FA2.1: Згенерувати 9 500 000 переглядів короткометражного відеовмісту на всіх власних каналах до кінця першого півріччя.
        • Цього року ми досягли близько 1 мільйона переглядів протягом 3 місяців після запуску коротких відео на каналах @Wikipedia в TikTok, Instagram та YouTube. До початку наступного фінансового року ми очікуємо збільшення кількості підписників на наших власних каналах та більше ідей щодо ефективного/цікавого вмісту, які ми зможемо застосувати на практиці, щоб охопити ще більше глядачів.
        • Поставивши амбітну мету на перше півріччя, ми сподіваємося досягти більш значного впливу, створити нові стратегії/процеси для полегшення роботи, а також зможемо адвокатувати додаткові ресурси для досягнення цієї мети.
      • Збільшити кількість наших позаплатформових підписників у TikTok із середнього рівня (100 тис. – 250 тис. підписників) до макрорівня (250 тис. – 1 млн підписників) до кінця 2025/26 фінансового року (червень 2026).
        • Наразі ми перебуваємо на середньому рівні підписників TikTok (100 тис. – 250 тис. підписників), і наша мета — досягти макрорівня (250 тис. – 1 млн підписників) до кінця 2025/26 фінансового року (червень 2026). Ці рівні — мікро, середній та макро — є стандартними орієнтирами в галузі щодо розміру аудиторії та охоплення. Щоб досягти цього, ми вдосконалимо нашу стратегію щодо вмісту, щоб краще залучати підписників покоління Z та підвищити нашу загальну видимість за допомогою управління спільнотою. Результати першого півріччя забезпечать тактичні коригування другого півріччя для прискорення зростання та досягнення цієї віхи.
      • Ключовий результат FA2.3: Запустити позаплатформовий продукт, спрямований на нові методи навчання/споживання медіа майбутніми аудиторіями, та вивести його на ринок за допомогою спільної маркетингової кампанії та брендингу продукту.
        • Команда Майбутні аудиторії зазвичай працює над невеликими експериментами з мінімальним/органічним маркетингом. Цього року ми хотіли б виділити час для масштабнішого створення нового продукту + маркетингової кампанії, орієнтованої на молоду аудиторію поза платформою.

Продуктова та інженерна підтримка (PES)

Продуктова та інженерна підтримка (PES1)

  • Ціль: Підвищити ефективність роботи продуктової та інженерної команд ФВМ завдяки вдосконаленню процесів, що сприятиме позитивним змінам у нашій культурі. Обговорити
    • Контекст цілі: Ця ціль полягає в тому, щоб зробити способи роботи Фонду Вікімедіа швидшими, розумнішими та кращими. Йдеться про те, як ми працюємо. Це означає менше тертя та перешкод (неефективності та помилок) у процесах, а також швидше досягнення впливу. Ця Ціль також передбачає вивчення методів роботи, які можуть бути застосовані у всьому відділі та організації.
      • Ключовий результат PES1.1: До кінця 2-го кварталу визначити ЦРО (Ціль рівня обслуговування) для шести виробничих послуг на основі рубрикатора пріоритетів, який має на меті максимізувати наше навчання тому, як визначати і використовувати ЦРО для прийняття обґрунтованих рішень командами зацікавлених сторін щодо визначення пріоритетності робіт, пов'язаних з надійністю.
        • Ціль рівня обслуговування (ЦРО) — це угода між командами зацікавлених сторін про цільовий рівень обслуговування (надійність/продуктивність), який команди повинні досягти (і не занадто перевищити). Наприклад, це допомагає визначити, коли для команди розробників робота над надійністю чи продуктивністю має бути пріоритетною, чи непріоритетною, або що становить проблему. Команди повинні дбати про визначення того, що є негайним (оповіщення/реагування на інциденти/критичні помилки), а що ні. Мета полягає в тому, щоб зменшити тертя між функціями шляхом узгодження цілей, а також спільного та чіткого визначення пріоритетів.
      • Ключовий результат PES1.2: До кінця другого кварталу сигнали спільноти (включно зі Списком побажань) вплинули на ФВМ, щоб він визначив пріоритетність щонайменше п'яти продуктових робочих процесів для третього та четвертого кварталів.
        • Наша мета — визначити та відзначити випадки, коли команди надають пріоритет роботі на основі обґрунтованих запитів спільноти.
        • Дві заплановані гіпотези зосереджені виключно на Списку побажань. Вони покликані підвищити довіру, оптимізувати процеси та збільшити участь співробітників і волонтерів. Інша гіпотеза — це експеримент, покликаний перевірити, чи є достатньо цінних сигналів від Кнайпи тощо, і чи може штучний інтелект посилити нас у зборі сигналів.
      • Ключовий результат PES1.3: Два експерименти на ранніх стадіях за участю кількох відділів, схвалені нашими зовнішніми аудиторіями споживачів, донорів та дописувачів, включені Фондом до річного плану.
        • Ця робота полягає у створенні експериментів та експериментальних процесів для впровадження в усій нашій організації.
        • Фонд зміцнює культуру експериментів за участі кількох відділів шляхом включення двох перевірених експериментів на ранніх стадіях у свій річний план. Ця ініціатива сприяє співпраці за межами функціональних груп Відділу продукту і технології, заохочуючи більше інновацій з іншими відділами організації (такими як відділи Комунікацій і Розвитку). Висуваючи неперевірені нові ідеї та оптимізуючи процеси для експериментів, команди підвищують продуктивність та масштабність впливу. Успіх вимірюється проведенням двох експериментів на рік за участі кількох відділів, інтеграцією їх у майбутню роботу над ЦКР, а також ширшим впровадженням експериментальних практик. Прикладами результатів є нові прототипи, що сприяють зростанню та продуктивності нових редакторів, а також експериментальні функції, що поглиблюють зв'язок читачів і донорів з Вікіпедією. Одна конкретна виявлена ​​можливість полягає в об'єднанні невеликих досліджень функцій для святкування 25-річчя Вікіпедії.
      • Ключовий результат PES1.4: До кінця четвертого кварталу ми побачимо 10% зростання темпів впровадження Codex серед команд P&T.‎
        • Як стандартизована бібліотека інтерфейсу користувача, Codex значно зменшує як навантаження на обслуговування, пов'язане зі створенням власних компонентів інтерфейсу користувача, так і час, необхідний для впровадження інтерфейсів користувача продукту. Codex також надає спільний словник для обговорення дизайну та впровадження, що підвищує ефективність між дизайном та інженерією.
        • Codex втратить корисність, якщо його впровадження не зросте, і Codex не буде широко використовуватися, і наразі він не впроваджується або не використовується широко в деяких місцях, оскільки інструменти не готові до деяких випадків використання. Можливо, йому також знадобиться більш помітна реклама/підвищення обізнаності. Ця робота є пріоритетною, оскільки команди повинні мати можливість органічно впроваджувати Codex, і наразі не всі можуть це зробити, не враховуючи спочатку перешкоди для впровадження.
        • Ми очікуємо, що це означатиме:
          • Відкриття - Що, як показують нам різні команди, блокує їх? Які варіанти використання та блокуючі фактори нам ще невідомі?
          • Покращення - Приклад: Ми знаємо, що Codex PHP 1.0 розблокує впровадження на стороні сервера.
          • Глибоке занурення в метрики - Приклад: Що нам говорять базові метрики, встановлені в першому кварталі, про те, де органічне впровадження не працює (і чи є уроки з впровадження OOUI в минулі роки)?
        • Ключовий результат зосередиться на відстеженні «офіційного» використання (тобто впровадження, яке відповідає задокументованим інструкціям) окремо від часткового або фрагментарного використання, наприклад, коли команди використовують лише частину компонента або лише CSS. Останній тип впровадження тягне за собою вищі витрати на обслуговування, ніж використання готових компонентів.
      • Ключовий результат PES1.5: 20% SLO сервісу призводять до прийняття впливового рішення до кінця четвертого кварталу.‎
        • Цілі рівня обслуговування (SLO) - це інструмент, який використовується для визначення пріоритетів на основі даних про надійність сервісу. Наприклад, чи потребує несправний сервіс негайної уваги. SLO працюють найефективніше, коли право власності чітко визначено, і всі їх використовують. Щоб це сталося, нам потрібно змінити культуру розробки в бік впровадження SLO для кожної послуги. Спираючись на останні кілька кварталів створення SLO та їх тестування з командами сервісів, ми визначили можливість уточнити цінність SLO, щоб ми могли продовжувати поширювати цю культуру.
          • Наразі у нас є 19 SLO.
          • Ми хочемо стимулювати SLO для послуг, які з найбільшою ймовірністю використовуватимуть їх. Якщо ми отримаємо ~3-4 (~20% з 19) «впливових рішень» з нашого поточного врожаю, чудово, але ми очікуємо, що нам потрібно буде прийняти більше. Знаменник збільшиться, але це ще більше стимулює орієнтацію на правильні послуги.
          • Четвертий квартал – це кінець часових рамок, оскільки нам потрібно більше одного циклу даних, а кожен квартал – це цикл. Це також дає нам простір для вдосконалення інструментарію, пілотного оповіщення про SRE тощо.
        • Успіх виглядає так:
          • Впливове рішення = «чи достатньо надійний цей сервіс наразі, чи нам потрібно визначити пріоритети роботи з його виправлення» – тобто, це так само рішення знайти помилку та сказати, що можна не визначати її пріоритети, як і рішення знайти помилку та визначити пріоритети її виправлення.
          • Ми хочемо, щоб рішення були різноманітними (наприклад, Архітектурні проти Організаційних проти Впровадження; або Стверджувальні проти рішення не робити чогось), оскільки йдеться про поширення цінності SLO та зміну культури. Усі однакові рішення або всі рішення від однієї команди не досягнуть цього, навіть якщо вони хороші.
          • Навіть якщо ми не досягнемо цілі KR, ми припускаємо, що дізнаємося цінну інформацію про причини (наприклад, ми орієнтуємося на неправильні сервіси).
          • Важливо: 80% наших SLO, які не мають впливового рішення, не є станом невдачі для них, оскільки більшу частину часу сервіси не повинні виходити з ладу.
      • Ключовий результат PES1.6: 20% критично вільних сервісів, згідно з рамковою системою аналізу ризиків, отримують зобов'язання власників до кінця четвертого кварталу.‎
        • Чіткий код та право власності на сервіси мають вирішальне значення для забезпечення надійності, масштабованості та безпеки технічної інфраструктури Фонду Вікімедіа. Усунення поточних прогалин у власності покращить підзвітність, покращить співпрацю між командами, пришвидшить ефективне прийняття рішень та зменшить ризики для стабільності, безпеки та сталості платформи. Крім того, це забезпечить більшу ясність для афілійованих осіб та волонтерів Вікімедіа, допомагаючи їм зрозуміти, хто відповідає за підтримку та обслуговування ключових сервісів.
          • Ми оцінюємо, що існує ~20 критично важливих сервісів без власників.
          • Ми вважаємо, що зможемо призначити 4 власників протягом 4 місяців у третьому/четвертому кварталі. Перші 2 місяці або близько того будуть присвячені підготовчій роботі для успішного виконання.
          • Ми плануємо розробити систему аналізу ризиків для визначення критичності в рамках роботи над гіпотезами в рамках цього ключового завдання.
      • Ключовий результат PES1.7: До кінця 4-го кварталу для побажань, отриманих у 3-му та 4-му кварталах, коефіцієнт виконання побажань покращиться до 5%.‎
        • Having revamped Wishlist triage in the first half of the year, we want to consistently demonstrate that volunteers are getting responses to their Wishes plus a monthly update consisting of what’s coming, what’s pending or blocked, and what’s being scoped. We will judge the metric by measuring response time on a rolling average over a month, and aim to sustain that for at least a month.

Гіпотези

Перший квартал

Перший квартал (Q1) річного плану ФВМ охоплює липень-вересень.

Гіпотези Вікідосвіду (WE)

[ Ключові результати WE ]

Обговорення

Коротка назва гіпотези Текст першого кварталу Деталі і обговорення
WE1.1.1 Якщо ми попросимо нових (або новіших) волонтерів, які вставляють текст із зовнішнього сайту, підтвердити, що вони самі написали вміст, який намагаються додати, то ми побачимо зменшення на ≥10% частки нових редагувань вмісту, опублікованих новими (або новішими) волонтерами, які були скасовані на підставі ВП:КОПІВІО (та пов'язаних політик).
WE1.1.2 Якщо ми випустимо початкову бета-версію «Покращення тону» у Пропонованих редагуваннях, то зможемо дізнатися, чи є цей новий формат Пропонованих редагувань ефективним способом збільшити кількість конструктивних редагувань від нових дописувачів без збільшення навантаження на патрульних/рецензентів.
WE1.1.3 Якщо ми у візуальному редакторі (мобільному та настільниому) впровадимо новий режим пропозицій, орієнтований на старших за віком дописувачів, як бета-функцію з ≥ 3 новими пропозиціями редагування, ми з'ясуємо, які коригування (якщо такі є) потрібно внести перед оцінкою досвіду нових (новіших) волонтерів за допомогою контрольованого експерименту.
WE1.1.4 Якщо ми впровадимо перевірку посилань на en.wiki через контрольований експеримент, ми побачимо ≥10% збільшення конструктивних правок, опублікованих новими (новішими) волонтерами, і дізнаємося, чи є достатня підтримка серед патрульних і модераторів, щоб широко впровадити цю функцію.
WE1.1.5 Якщо ми протестуємо систему прогресу за допомогою прототипів дизайну з новачками, ми зможемо визначити, які типи етапів, настанов та визнання сприймаються як найбільш мотивуючі, і використати ці відомості для остаточного оформлення дизайну для майбутніх пілотних експериментів у вікі.
WE1.1.6 Якщо за допомогою дослідження користувачів та аналізу даних ми дослідимо основні технічні, соціальні та поведінкові бар'єри та чинники, що сприяють мобільному веб-редагуванню, ми отримаємо щонайменше 3 практичні висновки, які усунуть ключові прогалини в знаннях та зміцнять нашу здатність впевнено визначати пріоритети інвестицій у продукт на другу половину 2025/26 фінансового року та на подальший період.
WE1.2.1 Якщо ми створимо доказ концепції для відображення даних про спільний внесок на вікі, ми зможемо зібрати відгуки щонайменше від 30 дописувачів, в тому числі 70% респондентів визнають, що ця функція є корисною і може сприяти спільному зростанню.
WE1.3.1 Якщо ми врахуємо потреби, виявлені в попередніх дослідженнях, і спроєктуємо та поділимося ранніми макетами X найвпливовіших модулів модератора, ми зможемо з їх використанням модифікувати головну сторінку для дій модератора.
WE1.3.2 Якщо ми змінимо головну сторінку для новачків, щоб за певних умов відображати модулі модератора, ми зможемо підтвердити доцільність використання головної сторінки для модераторів.
WE1.4.1 Якщо ми внесемо ряд поліпшень, зазначених у T396489, ми у великих вікі зменшимо повільні запити останніх змін на X відсотків. Тоді інструменти модераторів зможуть розгортати модулі головної сторінки на цих вікі без особливих проблем із продуктивністю бази даних. T400696
WE2.1.1 Якщо ми запросимо носіїв мови невеликих вікі через банер CentralNotice на Вікіпедії в їхньому регіоні, що має високий трафік, долучитися до Пропонованих редагувань та інших функцій Зростання, ми зможемо оцінити, чи приваблює цей підхід нових носіїв мови та чи використовують вони ці інструменти редагування для поліпшення важливого вмісту.
WE2.1.2 Якщо ми розробимо та випустимо пропозиції перекладу, адаптовані для нових редакторів, ми зможемо перевірити, чи дає цей підхід кращі результати перекладу порівняно з нашим поточним підходом.

Це розв'язує відомі проблеми, з якими стикаються нові редактори, які мають вищу ймовірність видалення статей. Спрямовуючи їх на переклад більш зручного вмісту, ми прагнемо зробити ознайомлення з процесом перекладу менш складним і більш доступним. Хороші статті та розділи можуть сприйматися як не надто складні з точки зору форматування та загальної довжини.

WE2.1.3 Якщо ми вивчимо про досвід редакторів під час створення нових статей та розділів (включно з мотивацією, проблемами та їхньою реакцією на нові ідеї щодо покращення підтримки), ми виявимо потреби та поведінку користувачів, що дасть практичні ідеї та стратегії для відділів продукту, дизайну та інженерії з метою покращення зручності створення статей.
WE2.1.4 Якщо ми дослідимо, за допомогою спільних семінарів або інтерв'ю, як три середні за розміром Вікіпедії підходять до прогалин у знаннях та важливості знань, ми виявимо робочі визначення або рамкові концепції «життєво важливих знань», які є актуальними для кожної спільноти.
WE2.2.1 Якщо ми наслідуємо приклад розгортання Parsoid та інтегруємо Вікіфункції у більшість Вікісловників та деякі Вікіпедії з низьким трафіком, ми отримаємо необхідне тестування, щоб впевнено розгортати цю функцію у більших вікі.
WE2.2.2 Якщо ми надамо Вікіфункціям можливість виводити HTML-таблиці, стилі та посилання, ми продемонструємо за допомогою функції, що відображає таблицю відмінювання, її здатність генерувати нові знання у Вікісловниках, що виходять за межі простих перетворень.
WE2.2.3 Якщо ми додамо підтримку об'єктів Вікіданих у викликах вбудованих функцій, ми забезпечимо роботу понад 200 нових функцій, які зможуть генерувати повні речення з використанням об'єктів Вікіданих, що зробить функції більш зручними для використання у проєктах Вікімедіа.
WE2.2.4 Якщо ми розробимо архітектурний план розміщення Абстрактного вмісту та його взаємодії з Вікіпедією, ми будемо більш готові до впровадження платформи Абстрактної Вікіпедії для збільшення обсягу високоякісного енциклопедичного вмісту.
WE2.2.5 Якщо ми визначимо та обговоримо з командами Продукту і Технології питання потреб продукту в цитуваннях, необхідних для Абстрактного вмісту, ми зможемо стимулювати в рамках Вікімедіа роботу з метою надання інформації про походження, що додається до Абстрактного вмісту, яка є вирішальною для успішного впровадження у всіх вікі.
WE2.2.6 Якщо ми зробимо формат внутрішніх запитів до бекенду більш виразним і лаконічним, ми зможемо підвищити стабільність системи, тим самим підтримуючи ширше розгортання.
WE2.2.7 Якщо ми надамо фрагменти прототипів, використовуючи виклики Вікіданих та Вікіфункцій для генерації фрагментів природної мови, ми покажемо готовність до проєкту і зможемо використовувати його для навчання штучного інтелекту, щоб люди не мали занадто багато думати про функції.
WE2.2.8 Якщо ми забезпечимо імпорт тверджень Вікіданих з кваліфікаторами, можна буде генерувати багатоаспектні факти (факти, для вираження яких потрібно більше, ніж просто предмет/предикат/значення), що включає приблизно 50% енциклопедичного вмісту Вікіданих.
WE2.2.9 Якщо ми забезпечимо кешування отриманих об'єктів Вікіданих, ми скоротимо щонайменше на 50% середній час виконання функцій на основі вмісту Вікіданих, зменшивши час очікування та розчарування користувачів.
WE2.2.10 Якщо ми надамо компонент значення лексем Вікіданих в користувацький інтерфейс Вікіфункцій, то дописувачі зможуть ідентифікувати та вибирати відповідні лексеми, не залишаючи платформу/Вікіфункції, що зменшить перемикання контексту та дозволить швидше й успішніше створювати функції, пов'язані з мовою.
WE2.2.11 Якщо ми врахуємо висновки спільноти Дагбані щодо інтеграції Вікіфункцій у Вікіпедію, ми побачимо, що редактори стикаються з меншою кількістю або взагалі не стикаються з критичними проблемами зручності використання під час вставляння функції в статтю під час тестування.
WE3.1.1 Якщо ми проведемо A/B-тестування вдосконаленої версії функції перегляду вкладок у застосунку для iOS, ми побачимо 5% зростання багатоденного використання серед користувачів вкладок.
WE3.1.3 Якщо ми надамо користувачам новий спосіб перегляду відповідного зображення або відеовмісту на сторінках статей, ми побачимо щонайменше 3% клікабельність серед користувачів, яким буде представлена ця функція.
WE3.1.4 Якщо ми покажемо читачам кілька концепцій для переходів мережею знань на вікі, ми отримаємо пріоритетний список концепцій для подальшого розвитку.
WE3.1.5 Якщо ми надамо веб-читачам можливість переглядати перекладену машинним способом версію вмісту Вікіпедії, недоступного їхньою мовою, ми дізнаємося, чи збільшилася активність читання, виміряна як 3% збільшення взаємодій зі сторінками, що приверне читачів до вікі місцевою мовою з потенційним збільшенням активності редагування місцевою мовою. Це буде надано у вигляді контрольованого A/B-тестування протягом не більше 6 місяців у 13 вікіпедіях за попередньою згодою, з використанням відкритих сервісів машинного перекладу, які вже доступні редакторам Вікіпедії.
WE3.2.1 Якщо ми будемо співпрацювати з відділом збору коштів, то розробимо більш захопливі, інтегровані та персоналізовані слайди для донорів у Огляді року для iOS, що буде оцінено за допомогою тестування користувачами. Далі у другому кварталі буде висунуто гіпотезу, щоб оцінити, чи покращений річний огляд приніс на 5% більше пожертв, ніж Огляд року 2024.
WE3.2.2 Якщо ми запропонуємо читачам Android-застосунку на ринках, де не проводиться кампанія, налаштувати опціональне, яке можна налаштувати (за сумою та частотою) нагадування про пожертви, відповідно до використання цими читачами Вікіпедії, ми побачимо на цих ринках 5% зростання пожертв через меню застосунку.
WE3.2.3 Якщо ми проведемо A/B-тестування серед незалогінених користувачів, щоб показати їм малопомітні варіанти входу в систему для пожертв на мобільних пристроях і настільних комп'ютерах, ми побачимо на 2% більше пожертв через ці шляхи порівняно з контрольною групою.
WE3.3.1 Якщо ми додамо до Огляду року 2025 персоналізовані елементи, що вимагали від користувачів iOS 2024 року від низьких до середніх зусиль, ми побачимо 3% зростання задоволеності порівняно з минулим роком, виміряне за допомогою тестування зручності використання або бета-тестування.
WE3.3.2 Якщо ми розширимо наявну вкладку «Редагувати» в Android до персоналізованого хабу активності, що включатиме інформацію про читання та участь без редагування, ми побачимо 5% зростання багатоденної активності на цій вкладці порівняно з оригінальною версією.
WE3.3.3 Якщо ми введемо в застосунок для Android принаймні один аватар, який можна розблокувати власникам облікових записів за допомогою значущих дій читачів, таких як збереження певної кількості статей, ми збільшимо повторне залучення з відповідними діями залогінених користувачів на 10% протягом декількох днів.
WE3.3.4 Якщо ми надамо залогіненим читачам можливість зберігати статті в приватному списку для читання, ми очікуємо збільшення залучення на сайті, що вимірюється 5% збільшенням внутрішнього трафіку для читачів, які використовують цю функцію, та статистично значним збільшенням для всіх користувачів.
WE3.3.5 Якщо ми проведемо дослідження користувачів, яке дозволить веб-читачам збирати/курувати вміст з Вікіпедії, то принаймні 10% учасників збережуть у колекцію два або більше різних типів вмісту (наприклад, статті, витяги, медіа).
WE3.4.1 Якщо ми будемо працювати над гібридним розгортанням PoP/CDN, це дозволить нам за потреби запустити як повні PoP, так і міні-PoP (фізичні та хмарні), заклавши основу для розгортання прототипу міні-PoP у майбутньому.
WE3.6.1 Якщо ми проведемо A/A-тест на рівень утримання незалогінених користувачів, ми встановимо базовий рівень утримання, який можна буде використовувати в наступних кварталах.
WE3.6.2 Якщо ми створимо та опублікуємо визначення залогіненого, ми зможемо використовувати це визначення у всіх командах та гіпотезах, пов'язаних з КР WE 3.3.
WE3.6.3 Якщо ми залучимо спільноти до обговорення мінливих потреб читачів та змін у природі знань в Інтернеті, ми зможемо сформувати спільну позицію щодо того, як обслуговувати читачів, та спільно працювати над тим, чи варто тестувати наші різні ідеї (включно з ідеями щодо мультимедіа, пошуку та знаходження, а також машинного навчання) і як це робити.
WE3.6.4 Якщо ми дослідимо різні мотивації, поведінку та потреби, що стоять за тим, коли, чому та як читачі використовують Вікіпедію та інші платформи знань, ми отримаємо результати, які зможемо використовувати для обґрунтування та розвитку нашої стратегії щодо споживачів.
WE4.1.1 Якщо ми створимо прототип мінімально життєздатного неаварійного потоку та будемо підтримувати відкритим цикл зворотного зв'язку під час його розробки разом із користувачами з розширеними правами, ці групи підтримають розширене впровадження цього потоку. Project page
WE4.2.1 Якщо ми покажемо рівень ризику hCaptcha, пов'язаний зі створенням облікових записів, довіреним посадовим особам, ми скоротимо час, необхідний для виявлення зловмисників, і збільшимо кількість виявлених облікових записів зловмисників, створених на платформі. Ми можемо виміряти успішність гіпотези, дивлячись на частоту блокування облікових записів, відповідність рівнів ризику hCaptcha та блокування облікових записів загалом, а також якісний зворотний зв'язок від посадових осіб.
WE4.2.2 Якщо ми будемо генерувати пропозиції щодо розслідувань для подальшого опрацювання чек'юзерами, ми побачимо скорочення часу, необхідного для виявлення облікових записів зловмисників, та збільшення кількості виявлених облікових записів зловмисників. Ми будемо знати, що досягли успіху, коли побачимо регулярне використання функції «Пропозиції щодо розслідувань», збільшення кількості заходів зі зменшення негативного впливу щодо облікових записів, виявлених за допомогою пропозицій щодо розслідувань, а також якісні відгуки в опитуваннях.
WE4.2.3 Якщо ми проаналізуємо дані з пробного створення облікових записів hCaptcha, ми зрозуміємо процес створення облікових записів, ефективність головоломки та оцінок hCaptcha і отримаємо дані, необхідні для подальшого впровадження hCaptcha при створенні облікових записів.
WE4.2.4 Якщо ми розгорнемо UserInfoCard на всіх вікі, ми надамо посадовим особам та модераторам можливість ефективніше виявляти та блокувати облікові записи зловмисників. Project page
WE4.2.5 Якщо ми проведемо дослідження, порадимося зі спільнотами та вивчимо технічні рішення, ми зможемо визначити набір структурованих причин блокування, які можна використовувати у всіх вікі ФВМ.
WE4.2.6 Якщо ми розробимо можливість розгортання кластерів на базі OpenSearch на Платформі даних, то команди розробників функцій продукту отримають можливість розробляти системи, що інтегрують цю можливість, з великою автономністю, стійкістю та ізольованістю від інших систем на базі пошуку. Першим і основним користувачем цієї системи буде сервіс IPoid.
WE4.2.7 Якщо ми розгорнемо інтеграцію hCaptcha Enterprise на декількох виробничих Вікіпедіях як пілотний проєкт, ми зможемо зібрати дані про ефективність та цінність hCaptcha Enterprise у боротьбі зі зловживаннями, виявленні ботів, зручності використання та доступності.
WE4.3.1 Якщо ми інтегруємо підтримку нового кукі Edge Uniques у requestctl, наш механізм правил для SRE, що борються зі зловживаннями, ми зможемо краще захищатися від DDoS-атак та повторного використання вмісту.
WE4.4.1 Якщо ми зможемо внести поліпшення на основі відгуків про пілотні проєкти та розгорнути Тимчасові облікові записи в усіх проєктах, ми зможемо захистити особову інформацію (IP-адреси) незареєстрованих користувачів у всіх наших проєктах, щоб вона була доступна менше ніж 0,1% усіх (зареєстрованих) користувачів. Project page
WE4.4.2 Якщо ми будемо чітко і вчасно комунікувати з відповідними зацікавленими сторонами руху (включно з вікі-спільнотами та глобальними посадовими особами), ми зможемо розгорнути на всіх решті вікі, зменшити навантаження, виявлене в останній момент, та уникнути відкату розгортання.
WE4.4.3 Якщо ми спростимо патрульним фільтрування дій та перегляд активності тимчасових облікових записів на основі їх IP-адрес, ми зможемо успішно розгорнути тимчасові облікові записи на всіх вікі.
WE4.4.4 Якщо ми дозволимо скасовувати доступ до розкриття IP-адрес тимчасових облікових записів відповідно до політики доступу до розкриття IP-адрес, а також зробимо цю функцію доступною в більшій кількості місць, ми зможемо успішно розгорнути тимчасові облікові записи на всіх вікі.
WE4.5.1 Якщо ми проведемо якісне дослідження для виявлення прикладів зловживань з боку зловмисників, які використовують генеративну ШІ (таких як спам, переслідування, тривалі зловживання, приховане редагування за винагороду або кампанії з дезінформації), ми зможемо оцінити ризик для наших моделей спільноти та генерувати ідеї для зменшення різних типів зловживань, що здійснюються з допомогою генеративного ШІ.
WE4.6.1 Якщо ми автоматизуємо процес синхронізації облікових записів у Zendesk для перевстановлення паролів, це полегшить навантаження на команду Довіри і безпеки і дозволить їм обробляти більше вхідних запитів на перевстановлення 2ФА.
WE4.6.2 Якщо ми будемо підтримувати та заохочувати користувачів реєструвати кілька факторів автентифікації, користувачі з увімкненою 2ФА будуть рідше блокувати доступ до своїх облікових записів.
WE4.6.3 Якщо ми дозволимо всім користувачам із підтвердженою адресою електронної пошти увімкнути 2ФА для своїх облікових записів, але не будемо активно рекламувати цю зміну серед користувачів, навантаження на службу підтримки відновлення залишиться на прийнятному рівні.
WE5.1.1 Якщо ми використовуємо різні бекенди зберігання для автентифікованих та анонімних сесій, ми зможемо захистити Sessionstore від DDoS-атак та скреперів з великим обсягом даних, не перевантажуючи його анонімними сесіями, які створюються для запобігання CSRF на сторінках автентифікації. T398814
WE5.1.2 Якщо ми змінимо сеансові файли кукі MediaWiki на структурований формат із криптографічним підписом, ми зможемо використовувати наявність сеансу як фактор захисту від скреперів, увімкнувши надійну перевірку сеансів на периферії у продуктивний та високомасштабований спосіб. T398815
WE5.1.3 Якщо ми створимо рішення для обмеження швидкості для шлюзу API, використовуючи локальне середовище розробки на базі Kubernetes, ми зможемо визначити найкращий варіант для тестування з виробничим трафіком, порівнявши продуктивність і функціональність щонайменше трьох різних служб обмеження швидкості. T398913
WE5.2.1 Якщо ми перепроєктуємо інтерфейс REST API Sandbox, щоб краще задовольнити інформаційні потреби розробників, ми поліпшимо зрозумілість документації, що буде підтверджено тестуванням на зручність використання.
WE5.2.2 Якщо ми будемо маршрутизувати всі API під rest.php через центральний шлюз, ми отримаємо можливість централізованого управління API і зможемо почати послідовно вимірювати трафік REST API та моделі використання, щоб отримати інформацію, яка буде корисною для прийняття майбутніх рішень та дій.
WE5.2.3 Якщо ми впровадимо панелі моніторингу та сигналізації для REST API Медіавікі, ми зможемо продемонструвати стійкий, корисний та відтворюваний спосіб поліпшення видимості поведінки наших систем та швидшого виявлення проблем, особливо під час критичних модифікацій.
WE5.3.1 Якщо ми розширимо та оптимізуємо настанови щодо атрибуції UX, одночасно оновлюючи всі наявні настанови, ми створимо базовий набір вдосконалених настанов, готових до внутрішнього тестування та ітеративного вдосконалення з метою підготовки до ширшого публічного використання.
WE5.3.2 Якщо ми створимо презентацію, яка демонструє переваги атрибуції Вікіпедії для сторонніх користувачів, які повторно використовують вміст, та їх кінцевих користувачів, ми зможемо підтримати WME4.1 та WME4.2, надавши можливість принаймні одному додатковому партнеру з повторного використання погодитися на участь у прикладі атрибуції або демонстрації до кінця першого кварталу.
WE5.4.1 Якщо ми забезпечимо, щоб більшість веб-запитів отримували унікальний кукі, буде легше ідентифікувати ботів і підроблені запити.
WE5.4.2 Якщо ми створимо масштабований спосіб ідентифікації відомих клієнтів, ми зможемо для ботів перевіреного походження дозволити винятки із загальних обмежень швидкості, а також перейти до систематичного застосування наших правил.
WE5.4.3 Якщо ми реорганізуємо фільтрування текстових запитів у CDN на основі підходу «дозволений список/заборонений список», ми зможемо застосувати більш суворі загальні обмеження швидкості для ботів та оптимізувати фільтрування трафіку.
WE5.4.4 Якщо ми розробимо уніфіковану стратегію вимірювання, ми зможемо оцінити багаторічну стратегію «відповідального використання інфраструктури» та визначити дорожню карту для розробки метрик та можливостей звітності.
WE6.1.1 Якщо ми перенесемо щоденні збірки зображень на сервер розгортання та додамо оновлення зображень, що запускаються певними обраними діями розгортання, ми виявимо обмеження та встановимо базовий рівень часу, необхідного для більш безперервного розгортання.
WE6.1.3 Якщо ми додамо вікі-ферми до середовища тестування перед злиттям, це дозволить командам розробників, які працюють над виробництвом і потребують декількох вікі для тестування своїх патчів в ізольованому режимі, отримати більшу впевненість перед запуском у виробництво та зменшити кількість дефектів, що проникають у виробництво.
WE6.2.1 Якщо ми переглянемо та опублікуємо наш Контрольний список готовності до виробництва, який чітко визначає передумови для визнання послуги готовою до виробництва, а також завдання, які можна виконати самостійно, ми узгодимо очікування між SRE та командами розробників, покращивши загальну операційну ефективність та масштабованість.
WE6.2.2 Якщо ми оголосимо про створення бібліотеки Golang і nodejs, яка абстрагує багато трудомістких завдань для розробників, вони відреагують, надавши відгуки та висловивши зацікавленість.
WE6.2.3 Якщо ми створимо контрольний список/робочий аркуш, розробники зможуть заздалегідь повністю підготуватися до огляду дизайну Збереження даних.
WE6.3.1 Якщо ми розгорнемо щонайменше 70 Вікіпедій з низьким трафіком у першому кварталі, за винятком вікі з підтримкою мовних варіантів, ми підвищимо нашу впевненість у кінцевому розгортанні на 10 найпопулярніших вікі, що матиме більший вплив на кількість переглядів сторінок через Parsoid.
WE6.4.1 Якщо ми розгорнемо таблицю розділення посилань Вікісховища у власному кластері, ми збільшимо шанси на те, що зростання бази даних Commons залишиться стійким. T398709
WE6.4.2 Якщо ми (SRE) надамо допомогу інженерним командам Медіавікі — шляхом створення документації, підготовки необхідної інфраструктури (наприклад, пакетів PHP, образів контейнерів) та надання наставництва і огляду — вони зможуть впевнено розпочати оновлення PHP 8.3 до початку другого кварталу. T360995
WE6.4.3 Якщо ми будемо вимагати фізичний другий фактор (апаратний ключ безпеки) для входу в SSH користувачам з підвищеними системними правами, ми зменшимо ризик того, що зламаний ноутбук спричинить серйозне порушення безпеки.
WE6.4.4 Якщо ми уніфікуємо наші домени, обслуговуючи всі перегляди сторінок на сайтах Медіавікі через канонічний домен, ми зменшимо складність платформи та ризики пошукової оптимізації (SEO) шляхом усунення перенаправлення на мобільні піддомени. Завершення вимірюється зменшенням переадресацій для мобільних відвідувань на канонічних доменах зі 100% до 0%. T214998
WE6.4.5 Якщо команда інженерів MediaWiki активно відстежуватиме та виправлятиме проблеми в MediaWiki, пов'язані з оновленням PHP 8.3, команда SRE буде розблокована для продовження оновлення PHP 8.3 до початку другого кварталу. T360995
Гіпотези щодо сервісів сигналів і даних (SDS)

[ Ключові результати SDS ]

Обговорення

Коротка назва гіпотези Текст першого кварталу Деталі і обговорення
SDS1.1.1 Якщо ми проаналізуємо ефективність автоматизованих евристик виявлення трафіку в наших наборах даних переглядів сторінок, ми зможемо розробити метрики якості даних для опису їхньої ефективності та визначити необхідність подальших інвестицій у ці евристики.
SDS1.2.2 Якщо ми перенесемо процес XML-дампів з поточної інфраструктури «Dumps 1» до конвеєра даних, що використовує конвеєри вмісту Медіавікі, ми зможемо гарантувати SLO та вимкнути експорт XML на основі «Dumps 1».
SDS1.2.3 Якщо ми проведемо покроковий огляд і переглянемо SLO для MediaWiki Content History та Event Platform / Event Gate, ми зможемо перевірити клієнтів, метрики та залежні зацікавлені сторони, а також визначити поліпшення, які можуть бути необхідні для SLO, що допоможе нам усунути будь-які прогалини в наших щотижневих гарантіях доставки.
SDS2.1.1 Якщо ми будемо тісно співпрацювати з командами, які проводять експерименти, ми дізнаємося, як зробити систему більш самообслуговуваною в майбутньому та з якими концептуальними або технічними проблемами вони можуть зіткнутися.
SDS2.1.2 Якщо ми зможемо впровадити краще налагодження для реєстрації подій, то команди продукту будуть знати, що їх експеримент збирає дані про події відповідно до очікувань, що підвищить впевненість власників експериментів.
SDS2.1.3 Якщо ми покращимо реєстрацію та спостережуваність компонента системи A/B-тестування (xLab) експериментальної платформи та пов'язаних з ним частин Медіавікі, ми зможемо встановити базові показники продуктивності системи та реагувати на збої, пов'язані з експериментами.
SDS2.1.4 Якщо ми будемо щомісяця ділитися історіями та результатами експериментів в організації (через наради з операційної діяльності продукту, наради команди дизайнерів та презентації між командами), ми створимо органічне впровадження експериментальної платформи.
SDS2.1.5 Якщо ми повідомимо користувачам, що їхній інструмент, створений в xLab, містить набір атрибутів, які змінюють категорію ризику, ми уникнемо надмірного збору даних користувачами інструментів та підвищимо зрозумілість того, яка комбінація атрибутів вимагає перевірки приватності.
Гіпотези щодо майбутньої аудиторії (FA)

[ Ключові результати FA ]

Обговорення

Коротка назва гіпотези Текст першого кварталу Деталі і обговорення
FA1.1.1 Якщо ми 1) запропонуємо збирачам медіа на інших платформах (таких як Letterboxd, Goodreads та RateMyMusic) способи покращити свої колекції за допомогою ексклюзивних знань Вікіпедії, або 2) запропонуємо цим збирачам медіа цікаві матеріали для поширення в соціальних мережах, ми зможемо збільшити охоплення Вікіпедії поза платформою.
FA2.1.1 Якщо ми розбудуємо внутрішній потенціал для створення коротких відеоматеріалів (шляхом збільшення розміру команди та аудиту й виявлення можливостей для підвищення ефективності поточного виробничого процесу) у першому кварталі, ми зможемо застосувати знання, отримані під час створення вмісту у 2024–2025 фінансовому році, і досягти вищого охоплення вмісту, створеного у другому кварталі 2025–2026 фінансового року, порівняно з попереднім роком.
Ключові результати Продуктової та інженерної підтримки (PES)

[ Ключові результати PES ]

Обговорення

Коротка назва гіпотези Текст першого кварталу Деталі і обговорення
PES1.1.1 Якщо ми підтримаємо xLab, Charts та ToneCheck у визначенні метрик для SLI (Service Level Indicators) у Prometheus та впровадимо ці Service Level Objectives (SLO) у Pyrra, ми дізнаємося про обмеження та крайні випадки використання наших інструментів у багатьох складних сценаріях, а також з'ясуємо, які ітерації необхідні для шаблону SLO, що допоможе нам краще підтримувати 6 запланованих SLO для КР.
PES1.1.2 Якщо ми в пілотному режимі протестуємо два набори панелей сповіщень SLO, ми дізнаємося, наскільки складно буде впровадити відповідні інструменти, щоб власники послуг чітко розуміли свої зобов'язання, а також чи потрібно переходити на інший інструмент, який пропонує лише один вид конкретного SLO. Одна панель буде призначена для квартальних звітів (де встановлюється фактична Угода про рівень обслуговування для бюджету помилок), а менша динамічна панель (так звана «ролинг») буде призначена для повсякденних операцій та оповіщення.
PES1.1.3 Якщо ми продовжимо підтримувати групу Абстрактної Вікіпедії у розробці SLO (Service Level Objectives) для проєкту Вікіфункції, ми дізнаємося, як визначити перелік цілей SLO (разом із метриками Service Level Indicator) для складної функції, яка зараз додається до критичного робочого процесу користувачів: рендерингу статей Вікі. Ми також дізнаємося, як правильно візуалізувати відповідні бюджети помилок і сповіщати про них за допомогою панелей моніторингу та моніторів, наданих SRE.
PES1.1.4 Якщо ми підтримаємо групу Платформи даних у перегляді та ітерації Service Level Objectives (SLO) для проєкту Історія вмісту Медіавікі, ми дізнаємося, як використовувати SLO для підтримки власності послуг, коли комбінація послуг пакетної та потокової обробки координується для оновлення набору даних, зберігаючи його узгодженість та доступність для кінцевих користувачів.
PES1.2.1 Якщо ми створимо 3 цільові поліпшення до Списку побажань, то ми заохотимо на 30% більше унікальних учасників до цього списку
PES1.2.2 Якщо ми відсортуємо вхідні побажання та призначаємо відповідального (наприклад, менеджери продукту) протягом 72 годин (включаючи відхилення, уточнення, позначення непідтримуваних послуг тощо), шляхом зіставлення нових побажань з Таблицею відповідальних осіб та призначення «Категорії відповідального» найбільш відповідній команді продукту або окремій особі, відповідальні особи (наприклад, менеджери продукту) зможуть оцінити побажання та відповісти на них протягом 10 днів або менше.
PES1.2.3 Якщо ми проведемо пілотну роботу з виявлення сигналів спільноти в цілому, ми врахуємо більше думок волонтерів у наших зусиллях з визначення пріоритетів на основі інформації від спільноти.
PES1.2.4 Якщо ми проведемо пілотний процес щоквартального огляду побажань і сигналів спільноти з трьома командами в першому кварталі, ми залучимо менеджерів продукту до інтеграції сигналів спільноти в їхні квартальні та річні процеси планування.
PES1.3.1 Якщо до кінця першого кварталу ми скоординуємо три функціональні сесії планування з Відділом комунікацій та командами продукту, щоб узгодити повідомлення, творчі потреби та графіки кампаній для ініціатив WP25, то ми остаточно затвердимо творчі резюме для всіх трьох експериментів кампаній (25YiR, Easter Eggs, WikiRun).
PES1.3.2 Якщо ми створимо керівний комітет із представників підрозділів дизайну та розробки функцій, ми зможемо визначити базові метрики щодо внесків у Codex: обізнаність, використання, якість внесків та їх кількість. Ідеї, отримані в результаті оцінки за цими базовими метриками, допоможе нам визначити дорожню карту для об'єднання зростання та диверсифікації бази дописувачів Codex.

Другий квартал

Другий квартал (Q2) річного плану ФВМ охоплює період з жовтня по грудень.

Гіпотези Вікідосвіду (ВД)

[ Ключові результати ВД ]

Обговорення

Коротка назва гіпотези Текст другого кварталу Деталі та обговорення
WE1.1.1 Якщо ми проаналізуємо заздалегідь визначений набір ключових показників не раніше, як через 2 тижні після початку A/B-тестування функції Paste Check, ми зможемо визначити, які аспекти комплексного користувацького досвіду (якщо такі є) потрібно скоригувати або дослідити, перш ніж ми зможемо впевнено оцінити вплив цієї функції.
WE1.1.4 Якщо ми впровадимо перевірку посилань (Reference Check) на en.wiki шляхом контрольованого експерименту, ми побачимо зростання на ≥4% конструктивних редагувань, які публікують нові (або відносно нові) волонтери, і дізнаємося, чи є достатня підтримка серед патрульних і модераторів, щоб розширити використання функції.
WE1.1.7 Якщо ми проаналізуємо заздалегідь визначений набір ключових показників не раніше, як через 2 тижні після початку A/B-тестування функції Tone Check, ми зможемо визначити, які аспекти комплексного користувацького досвіду (якщо такі є) потрібно скоригувати або дослідити, перш ніж ми зможемо впевнено оцінити вплив цієї функції.
WE1.1.8 Якщо ми застосуємо модель Tone Check до опублікованих статей, ми дізнаємося, чи можемо ми виявити ≥10 000 випадків проблем з тоном (кожен з імовірністю 0,8 або вище), які необхідні для створення високоякісного (з точністю ≥ 70%) пулу пропозицій, щоб допомогти редакторам поліпшити тон статей.
WE1.1.10 Якщо ми опитаємо ~10 досвідчених волонтерів на en.wiki та fr.wiki, які створюють фільтри зловживань AbuseFilters (та інші гаджети/скрипти/шаблони/повідомлення про редагування) для автоматизації процесів патрулювання/модерації, ми визначимо не менше трьох патернів/потреб, які допоможуть оформити пропозицію цінності функції перевірок редагування (Edit Checks), що створюються спільнотою.
WE1.1.11 Якщо ми поширимо опитування серед ≥500 успішних новачків[i] і отримаємо високоякісні дані, які є репрезентативними для ширшої групи успішних новачків, ми зможемо визначити ≥4 практичні висновки, які ми можемо використовувати для визначення пріоритетності аспектів досвіду адаптації новачків, які потрібно поліпшити.
WE1.1.12 Якщо ≥3 волонтерів оцінить кожен ≥30 зразків редагувань для кожної з 10 нових мов, на які ми прагнемо масштабувати Tone Check, ми дізнаємося, як часто волонтери погоджуються з прогнозами моделі і зможемо вирішити, до яких нових вікі звернутися з пропозицією впровадження Tone Check.
WE1.1.13 Якщо ми масштабуємо функцію Додайте посилання (Add a Link) на 100% нових волонтерів в англійській Вікіпедії, то конструктивна активація та утримання новачків покращаться, що збільшить кількість конструктивних редагувань, зроблених новими волонтерами, на ≥4%.
WE1.2.3 Якщо ми скасуємо вимогу, що для використання Реєстрації події (Event Registration) на малих і середніх вікі потрібно мати права організатора подій, то ми побачимо щонайменше X додаткових подій*, створених на цих вікі до кінця фінансового року.
  • очікується розрахунок базового рівня / цільового показника.
WE1.2.4 Якщо ми доопрацюємо мінімально життєздатний продукт «Спільні внески» (Collaborative Contributions) щонайменше двома поліпшеннями, то через Реєстрацію подій буде створено більше спільних редагувань.
WE1.2.5 Якщо ми на початку другого кварталу визначимо одну стратегію впровадження Реєстрації подій на Вікісховищі, ми зможемо протестувати її з організаторами щонайменше однієї великої кампанії та надати можливість п'яти місцевим організаторам використовувати цю функцію.
WE1.3.3 Якщо ми започаткуємо експеримент з показом панелі модератора новим редакторам, 10% учасників, які її відвідали, будуть робити це два тижні поспіль.
WE1.4.1 Якщо ми реалізуємо поліпшення, визначені в T396489, ми зменшимо кількість повільних запитів останніх змін щонайменше на 30% на великих вікі, що дозволить команді Community Tech розгорнути функцію Watchlist Labels без перевантаження бази даних останніх змін.
WE1.4.3 Якщо ми впровадимо останні зміни та список спостереження, то зможемо визначити базовий рівень частоти переходів на сторінки.
WE1.5.1 Якщо ми впровадимо панель інструментів для вивчення семи показників учасників та стандартизуємо розрахунок принаймні одного показника за допомогою dbt, то зможемо надати продуктовим командам, що працюють з учасниками, можливість самостійно отримувати аналітику метрик та розробити стандарт для зберігання логіки розрахунку метрик.
WE1.5.2 Якщо ми визначимо в другому кварталі, які дії з модерації включити в визначення того, хто є модератором, то команда Movement Insights зможе у третьому/четвертому кварталі розробити метрику «Щомісячні активні модератори».
WE2.1.3 Якщо ми вивчимо досвід редакторів під час створення нових статей та розділів (включно з мотивацією, проблемами та їхньою реакцією на нові ідеї щодо покращення підтримки), ми виявимо потреби та поведінку користувачів, що дасть практичні ідеї та стратегії для відділів продукту, дизайну та інженерії з метою покращення зручності створення статей.
WE2.2.12 Якщо ми розгорнемо Вікіфункції у вікі, де увімкнено Parsoid, ми зможемо продовжувати тестувати, чи ця система залишається продуктивною та придатною для використання при все ширшому її розгортанні.
WE2.2.13 Якщо ми поширимо інформацію про доступність функції таблиці відмінювання серед спільноти Вікісловника, ми отримаємо цінні відгуки про використання функції та аналітику про наших користувачів, яку ми зможемо застосувати у майбутніх розгортаннях.
WE2.2.14 Якщо ми ознайомимося з роботою спільноти з Databox для заповнення інформаційних карток даними з Вікіданих і дослідимо, чи можуть Вікіфункції бути корисним, ми зможемо визначити перший експеримент для Вікіфункцій в інформаційних картках.
WE2.2.15 Якщо ми поінформуємо спільноту про можливість створювати та перекладати повідомлення про помилки на Вікіфункціях, ми побачимо збільшення кількості корисних повідомлень про помилки.
WE2.2.16 Якщо ми продемонструємо спільноті доступні семантичні функції, ми побачимо збільшення граматичних функцій на 50%.
WE2.2.17 Якщо ми надамо спеціально налаштований компонент для перегляду тверджень Вікіданих на Вікіфункціях, користувачі зможуть краще розуміти дані, отримані з Вікіданих, і почуватимуться менш перевантаженими.
WE2.2.18 Якщо ми зможемо запобігти пікам 10-кратного споживання пам'яті, оркестратор зможе краще обробляти об'єкти Вікіданих, підтримуючи корисність Вікіфункцій, як платформи для Абстрактної Вікіпедії.
WE2.2.19 Якщо ми надамо користувачам можливість ділитися прямими посиланнями на конкретні виклики функцій, включаючи їх вхідні дані, учасники зможуть легше відтворювати, перевіряти та обговорювати поведінку функцій, що, своєю чергою, прискорить налагодження, поліпшить робочі процеси тестування та сприятиме спільному розв'язанню проблем у всій спільноті Вікіфункцій.
WE2.3.1 Якщо ми остаточно ухвалимо рішення про створення нової вікі та визначимося з назвою разом зі спільнотою, ми зможемо ширше поінформувати зацікавлені сторони про створення цієї нової вікі та підготуватися до логістики потенційної зміни назви продукту.
WE2.3.2 Якщо ми визначимо мінімально життєздатний продукт для прототипу Абстрактної вікі, який включатиме найменший базовий досвід для тестування наших можливостей бек-енду та генерування природної мови (NLG) і дозволить нам розробляти ітеративно, ми зможемо спланувати та запустити робочий прототип у третьому кварталі.
WE2.3.3 Якщо ми почнемо спілкуватися зі спільнотою та досліджувати потенційні проєкти для зручності користування Абстрактною вікі, ми зможемо продовжувати роботу у третьому кварталі.
WE2.4.1 Якщо ми зберемо приклади використання Вікіданих та сервісу запитів Вікіданих (WDQS) від команд Вікімедіа Німеччина та ФВМ, ми зможемо визначити вимоги до продукту для вдосконалення інфраструктури.
WE2.4.2 Якщо ми створимо агрегований звіт про ключові показники ефективності (КПЕ) з існуючими цілями рівня обслуговування (ЦРО) для Вікіданих та WDQS, ми зможемо сформулювати та відстежувати критерії успіху для вдосконалення технічної інфраструктури, що підтримує критичний випадок використання Вікіданих.
WE2.4.3 Якщо ми зможемо оцінити та порівняти альтернативні сховища з Blazegraph, використовуючи реалістичні критерії виробництва протягом цього кварталу, ми зможемо прийняти рішення про міграцію на основі даних та сформулювати конкретний план дій із зазначенням термінів та вимог до ресурсів.
WE3.1.1 Якщо ми проведемо A/B-тестування вдосконаленої версії функції перегляду вкладок (Tabbed browsing), ми побачимо 5% зростання багатоденного використання серед користувачів вкладок.
WE3.1.3 Якщо ми надамо користувачам новий спосіб перегляду відповідного зображувального вмісту на сторінках статей і протестуємо його на підгрупі незалогінених читачів за допомогою A/B-тестування на кількох вікі, ми побачимо щонайменше 3% клікабельності серед користувачів, яким буде представлена ця функція.
WE3.1.4 Якщо ми покажемо читачам кілька концепцій для переходів мережею знань на вікі, ми отримаємо пріоритетний список концепцій для подальшого розвитку.
WE3.1.5 Якщо ми надамо веб-читачам можливість переглядати машинно перекладену версію вмісту Вікіпедії, недоступну їхньою мовою, ми дізнаємося, чи збільшиться активність читання, виміряна як 3% збільшення взаємодій зі сторінками, що приверне читачів до вікі місцевою мовою з потенційним збільшенням місцевої активності редагувння. Це буде проведено у вигляді контрольованого A/B-тестування протягом не більше шести місяців у 13 Вікіпедіях за попередньою згодою, з використанням відкритих сервісів машинного перекладу, які вже доступні редакторам Вікіпедії.
WE3.1.6 Якщо ми створимо прототип семантичного пошуку та питань і відповідей у статтях, який буде представлений у вигляді демонстраційного інтерфейсу, де можна буде порівняти поточний підхід з новими дослідницькими підходами, то команди, що працюють з читачами, зможуть якісно оцінити, як кожен підхід працює в різних сценаріях взаємодії користувачів, та виявити прогалини або можливості для подальшої ітерації.
WE3.1.7 Якщо ми проаналізуємо наявні дослідження про те, як читачі взаємодіють з інструментами пошуку та навігації у Вікіпедії, і як вони використовують зовнішній пошук для знаходження інформації у Вікіпедії, ми зможемо надати командам, що працюють з читачами, не менше трьох практичних рекомендацій та висновків, які допоможуть їм визначити MVP для пошуку та знаходження, щоб усунути прогалини в очікуваннях та потребах читачів.
WE3.1.8 Якщо ми оцінимо два прототипи семантичного пошуку (пошук природною мовою, питання та відповіді) із зовнішніми учасниками, ми зможемо дізнатися, чи бачать користувачі цінність у вдосконалених інструментах пошуку, а також надати командам, що працюють з читачами, рекомендації щодо того, як рухатися вперед із MVP пошуку та знаходження.
WE3.1.9 Якщо ми покажемо 10-20 випадковим читачам Вікіпедії високоякісні концепції дизайну для пошуку вмісту за допомогою семантичного пошуку в рамках якісного дослідження, ми побачимо позитивне ставлення до цієї функції та отримаємо впевненість, необхідну для продовження роботи над MVP пошуку та знаходження, який базується на коротких уривках, написаних людьми для пошукових запитів.
WE3.1.10 Якщо у немодерованому дослідженні користувачів ми покажемо 10 випадковим читачам прототип нової функції перегляду зображень, ми виявимо принаймні одне поліпшення UX для майбутніх ітерацій цієї функції.
WE3.1.11 Якщо ми послабимо відповідність ключових слів у пошуку, то зможемо краще підтримувати запити природною мовою та дозволимо Відділу продукту оцінити цю можливість, включити її в те, як вони проєктують, пріоритезують та виконують роботу в просторі семантичного пошуку.
WE3.1.14 Якщо ми запустимо A/B-тестування версії мобільного сайту, яка запроваджує навігацію, що відкриває всі розділи за замовчуванням, ми побачимо ранні показники, які сигналізують про збільшення тривалості сеансу (повні результати A/B-тестування будуть представлені у третьому кварталі). T409163
WE3.2.5 Якщо ми впровадимо функцію Підсумок року (Year in Review) на Андроїді, яка висвітлює вплив користувача і включає інтегровані повідомлення від донорів, ми стимулюємо нову донорську поведінку — і побачимо 5% зростання в меню застосунку порівняно з 2024 роком.
WE3.2.6 Якщо в Підсумку року на iOS ми зробимо слайди для донорів більш інтегрованими та персоналізованими, ми побачимо 5% зростання пожертв у порівнянні з 2024 роком.
WE3.3.3 Якщо ми запровадимо для власників облікових записів у застосунку для Андроїда принаймні один аватар для розблокування — зароблений завдяки значущим діям читача, таким як збереження певної кількості статей — ми збільшимо повторну взаємодію з пов'язаними діями залогінених користувачів на 10% протягом декількох днів.
WE3.3.4 Якщо ми дамо залогіненим читачам можливість зберігати статті в приватному списку для читання, ми очікуємо, що взаємодія на сайті збільшиться, що вимірюється 5% зростанням внутрішнього реферального трафіку для читачів, які використовують цю функцію, та статистично значущим зростанням для всіх користувачів.
WE3.3.6 Якщо ми зробимо дані з висновком про тему статті доступними через сервіс, який відповідає узгодженим вимогам щодо масштабованості та доступності, а також будь-яким необхідним доповненням даних, то ми створимо технічну основу, необхідну для підтримки майбутніх персоналізованих читацьких вражень, які залежать від цих даних.
WE3.3.7 Якщо ми використаємо можливості обробки даних платформи для агрегації індивідуальних метрик редактора та даних про вплив і надамо агреговані дані через відповідні сервіси з визначеними рівнями SLO, ми зможемо покращити майбутні версії Підсумку року (WE3.3.1) та Картки активності (Activity Tab, WE3.3.2).
WE3.3.9 Якщо ми випустимо Підсумок року на Андроїді і проведемо A/B-тестування, пропонуючи зацікавленим користувачам винагороду за збереження індивідуального списку читання, ми побачимо 1% зростання загального рівня утримання користувачів серед читачів, яким було запропоновано винагороду, порівняно з тими, кому її не пропонували.
WE3.3.10 Якщо ми проведемо A/B-тестування, вимагаючи наявність облікового запису для перегляду персоналізованих статистичних даних про читання в «Підсумку року», ми побачимо 1% зростання загального рівня утримання користувачів, яким було потрібно мати обліковий запис, порівняно з тими, яким це не було потрібно.
WE3.3.11 Якщо ми проведемо A/B-тестування вдосконаленої версії вкладки «Активність» на iOS, яка виділяє читання, редагування та інші види активності, ми побачимо 5% зростання кількості багатоденних відвідувань вкладки залогіненими читачами порівняно з прототипною версією.
WE3.4.1 Якщо ми будемо працювати над розгортанням гібридної точки присутності (PoP/CDN), це дозволить нам за необхідності створити як повні PoP, так і міні-PoP (фізичні та хмарні), заклавши основу для розгортання прототипу міні-PoP у майбутньому.
WE3.5.1 Якщо відділи Продукту і технології та Збору коштів спільно оцінять і задокументують технічні підходи до ідентифікації донорів на наших платформах, ми зможемо рекомендувати коротко- і довгострокове рішення, яке збалансує приватність, здійсненність і вплив. Це спільне розуміння допоможе узгодити прийняття рішень, забезпечить постійне визнання донорів на всіх платформах, а також більш цілеспрямоване експериментування з майбутніми функціями, пов'язаними зі збором коштів.
WE3.6.3 Якщо ми залучимо спільноти до обговорення еволюціонуючих потреб читачів та еволюціонуючої природи знань в Інтернеті, ми зможемо сформувати спільну позицію щодо того, як обслуговувати читачів, та спільно працювати над тим, чи і як тестувати наші різні ідеї (включаючи ті, що стосуються мультимедіа, пошуку та знаходження, а також машинного навчання).
WE3.6.4 Якщо ми дослідимо різні мотивації, поведінку та потреби, що стоять за тим, коли, чому і як читачі використовують Вікіпедію та інші платформи знань, ми зможемо запропонувати пріоритетні напрямки та конкретні ініціативи для споживацької стратегії.
WE3.6.5 Якщо відділи Продукту і технології та Збору коштів співпрацюватимуть над спільною стратегією диверсифікації можливостей пожертв на платформі, а також управління та визнання читачів, які роблять пожертви, ми встановимо чіткі, узгоджені цілі та показники, пов'язані з нашими стратегіями щодо споживачів та збору коштів.
WE3.6.6 Якщо ми розробимо єдину стратегію вимірювання, ми зможемо оцінити багаторічну стратегію споживачів і визначити дорожню карту для розробки метрик та можливостей звітності.
WE4.1.1 Якщо ми створимо прототип мінімально життєздатного неаварійного потоку та будемо підтримувати відкритим цикл зворотного зв'язку під час його розробки разом із користувачами з розширеними правами, ці групи підтримають розширене впровадження цього потоку.
WE4.1.3 Якщо ми оновимо сім Вікіпедій (французьку, німецьку, іспанську, угорську, італійську, польську, португальську) до кінця жовтня, ми завершимо першу фазу розгортання нового юридичного нижнього колонтитула (Legal Footer) у відповідь на вимоги DSA.
WE4.1.4 Якщо ми розгорнемо MVP Системи повідомлення про інциденти щонайменше на 15 вікі, зосередившись на більших складних спільнотах, ми спостерігатимемо, як вона використовується спільнотою за призначенням, і продемонструємо робочу модель для повідомлення про ненадзвичайні інциденти.
WE4.1.5 Якщо ми розробимо блок-схему для процесу повідомлення про випадки зловживання на вікі, де не встановлено процесів обробки зловживань, це сприятиме впровадженню системи повідомлення про інциденти на таких вікі та надасть користувачам цих вікі чіткий і дієвий шлях підтримки.
WE4.2.3 Якщо ми проаналізуємо дані з випробування створення облікових записів hCaptcha, ми зрозуміємо процес створення облікових записів, ефективність головоломок та оцінок hCaptcha і отримаємо дані, необхідні для подальшого впровадження hCaptcha при створенні облікових записів.
WE4.2.5 Якщо ми проведемо дослідження, обговоримо зі спільнотами та вивчимо технічні рішення, ми зможемо визначити набір структурованих причин блокування, які можна використовувати на всіх вікі ФВМ.
WE4.2.6 Якщо ми розробимо можливість розгортання кластерів на базі OpenSearch на платформі даних, команди інженерів з розробки функцій продукту отримають можливість розробляти системи, що інтегрують цю функцію, з великою автономністю, стійкістю та ізольованістю від інших систем на базі пошуку. Першим і головним користувачем цієї системи буде служба IPoid.
WE4.2.7 Якщо ми розгорнемо інтеграцію hCaptcha Enterprise на декількох виробничих Вікіпедіях як пілотний проєкт, ми зможемо зібрати дані про ефективність і цінність hCaptcha Enterprise у боротьбі зі зловживаннями, виявленні ботів, зручності використання та доступності.
WE4.2.8 Якщо ми зробимо проксі hCaptcha готовим до виробництва, поліпшивши його доступність та спостережуваність, ми будемо надавати більш стабільний та надійний сервіс для виробничих Вікіпедій у першому кварталі.
WE4.2.9 Якщо ми інтегруємо SDK hCaptcha в нативні мобільні застосунки, оцінимо користувацький досвід нативних застосунків та оцінимо можливість використання перевірок hCaptcha як частини API для створення облікових записів, ми отримаємо достатнє розуміння для подальшого розгортання hCaptcha для API для створення облікових записів.
WE4.2.11 Якщо ми увімкнемо hCaptcha для виявлення ботів у сценаріях редагування з підвищеним ризиком, ми побачимо, що hCaptcha може зменшити автоматизовані зловживання.
WE4.2.16 Якщо ми проконсультуємося з відповідними командами ФВМ, ми зможемо розробити узгоджений план для управління більш деталізованим доступом користувачів до непублічних даних та підтримати впровадження непублічних правил захисного програмного забезпечення.
WE4.2.17 Якщо ми проаналізуємо реальні приклади та опитаємо чек'юзерів, щоб виявити принаймні два сигнали потенційного зловживання на підставі прототипу історії редагування, команда з безпеки та цілісності продукту зможе пізніше включити ці сигнали в функцію Пропоновані розслідування (Suggested Investigations) з більшою впевненістю, що ці сигнали будуть корисними.
WE4.3.2 Якщо ми розгорнемо відбитки пальців JA4H, які підсумовують поведінку клієнтів HTTP, ми зможемо краще ідентифікувати та класифікувати трафік ботів.
WE4.4.1 Якщо ми зможемо внести поліпшення на основі відгуків пілотних проєктів і розгорнути тимчасові облікові записи для всіх проєктів, ми зможемо захистити особову інформацію (IP-адреси) незареєстрованих користувачів у всіх наших проєктах, щоб вона була доступна для менше ніж 0,1% всіх (зареєстрованих) користувачів.
WE4.4.2 Якщо ми будемо чітко і вчасно комунікувати з відповідними зацікавленими сторонами руху (включно з вікі-спільнотами та глобальними посадовими особами), ми зможемо розгорнути на всіх решті вікі, зменшити навантаження, виявлене в останній момент, та уникнути відкоту розгортання.
WE4.4.5 Якщо ми зменшимо труднощі для патрульних у виявленні зловмисників, які використовують тимчасові облікові записи для вандалізму, ми зможемо запобігти збільшенню вандалізму, вимірявши відсутність збільшення рівня відкоту на всіх вікі з тимчасовими обліковими записами.
WE4.4.6 Якщо ми припинимо використання розширення LiquidThreads, ми розблокуємо тимчасові облікові записи, впроваджені на всіх проєктах, які зараз використовують це розширення.
WE4.6.1 Якщо ми автоматизуємо процес синхронізації облікових записів у Zendesk для перевстановлення паролів, це полегшить навантаження на команду Довіри і безпеки і дозволить їм обробляти більше вхідних запитів на перевстановлення 2ФА.
WE4.6.3 Якщо ми дозволимо всім користувачам із підтвердженою адресою електронної пошти вмикати 2ФА для своїх облікових записів, але не будемо активно рекламувати цю зміну серед користувачів, навантаження на нашу службу підтримки відновлення залишиться на прийнятному рівні.
WE4.6.4 Якщо ми продовжимо оновлення системи 2ФА з погляду користувацького досвіду та додамо підтримку парольних ключів, більше користувачів зареєструють кілька факторів автентифікації та будуть краще захищені від втрати доступу до облікового запису.
WE4.6.5 Якщо ми розробимо та створимо загальні рамки для визначення вимог, яким повинні відповідати члени локальної або глобальної групи, ми будемо використовувати ці рамки для забезпечення того, щоб члени групи temporary-account-ip-viewer відповідали існуючим вимогам політики.
WE4.6.6 Якщо ми дослідимо, як користувачі з розширеними правами (UWER) покладаються на скрипти користувачів, ми зможемо запропонувати план, який спільнота UWER могла б підтримати, щоб здійснити одне або кілька істотних технічних змін, які б суттєво захистили систему скриптів користувачів.
WE4.6.7 Якщо ми оцінимо користувацький досвід та технічні зміни, необхідні для нативних мобільних застосунків, щоб узгодити досвід входу в мобільні застосунки з веб-платформою, шляхом вивчення альтернативних механізмів, таких як OAuth, ми зможемо визначити доцільність інтеграції з метою забезпечення для користувачів більш безпечного та узгодженого досвіду.
WE4.6.8 Якщо ми будемо моніторити вплив форм Zendesk і Медіавікі, які ми створили в першому кварталі, то зможемо запропонувати технічні зміни на наступні квартали, які дозволять краще автоматизувати позосталу частину процесу відновлення облікового запису.
WE5.1.2b Якщо ми інтегруємо кілька методів ідентифікації та автентифікації розробників в API-шлюз, ми зможемо призначити відповідний ліміт швидкості для кожного запиту, правильно ідентифікуючи запити, що надходять від різних груп користувачів.
WE5.1.3b Якщо ми проведемо пробне обмеження швидкості щонайменше на трьох маршрутах шлюзу REST, це дозволить нам перевірити доцільність обмеження швидкості з огляду на споживання ресурсів і визначити початковий набір обмежень, які можна застосувати з мінімальним впливом на користувачів.
WE5.1.4b Якщо ми перевіримо запропоновані механізми сегментації користувачів API за допомогою ширших наборів даних та ручного перегляду ідентифікованих груп, ми зможемо остаточно визначити групи користувачів, удосконалити методики, що використовуються для розрахунків, та краще зрозуміти їх ефективність.
WE5.1.5 Якщо ми будемо співпрацювати з командою платформи Медіавікі щодо ідентифікації трафіку та обмеження швидкості, ми зможемо впровадити обмеження швидкості для пробного запуску в виробничому середовищі, підтримуючи команду платформи у створенні та впровадженні цієї функції.
WE5.2.1b Якщо ми будемо взаємодіяти з потенційними користувачами нового REST API Explorer, це допоможе нам визначити ключові аспекти зручності використання, які вказують на те, чи є новий дизайн простим у використанні та чи відповідає він ментальній моделі розробників.
WE5.2.2b Якщо ми скеруємо Action API через центральний шлюз API, ми зможемо почати послідовно вимірювати трафік і моделі використання, щоб отримати інформацію, яка допоможе у прийнятті майбутніх рішень і дій.
WE5.2.4 Якщо ми впровадимо стандартні шаблони документації для двох API, ми зможемо вдосконалити настанови щодо вмісту, зрозуміти, що потрібно власникам API для прийняття цих настанов, і кількісно оцінити зусилля, необхідні для впровадження цих настанов у решті документації API Вікімедіа.
WE5.2.5 Якщо ми проведемо експеримент з визначення і застосування правил лінтингу специфікацій OpenAPI (OpenAPI spec linting rules) до REST API Медіавікі, ми продемонструємо спосіб програмного впровадження настанов щодо стилю API для поліпшення якості та узгодженості API, опублікованих у Вікімедіа та наших спільнотах.
WE5.3.1 Якщо ми розширимо та оптимізуємо настанови щодо атрибуції UX, одночасно оновлюючи існуючі настанови, ми створимо базовий набір вдосконалених настанов, готових до внутрішнього тестування та ітеративного вдосконалення, щоб підготуватися до ширшого публічного використання.
WE5.3.1b Якщо ми опублікуємо та ітеративно вдосконалимо проєкт настанов та демонстрацій UX, ми створимо базову структуру, готову до внутрішнього тестування та ітеративного вдосконалення, щоб підготуватися до ширшого публічного використання.
WE5.3.2 Якщо ми створимо презентацію, яка демонструє переваги атрибуції Вікіпедії для сторонніх користувачів, які повторно використовують вміст, та їх кінцевих користувачів, ми зможемо підтримати WME4.1 та WME4.2, залучивши принаймні одного додаткового партнера з повторного використання вмісту, який до кінця першого кварталу погодиться взяти участь у тематичному дослідженні або демонстрації атрибуції.
WE5.4.2b Якщо ми створимо масштабований спосіб ідентифікації відомих клієнтів, ми зможемо дозволити винятки із загальних обмежень швидкості для ботів перевіреного походження та перейти до систематичного застосування наших правил.
WE5.4.5 Якщо ми почнемо застосовувати обмеження швидкості, адаптовані до різних класів індивідуальних клієнтів, ми зменшимо навантаження на нашу інфраструктуру, пов'язане з масовим скануванням.
WE5.4.6 Якщо до кінця другого кварталу ми класифікуємо основних N пошукових роботів (павуків) як відомих ботів, ми зможемо обмежити кількість ресурсів, які вони використовують.
WE5.4.7 Якщо ми визначимося зі стандартизованим набором дозволених розмірів мініатюр на нашій медіа-інфраструктурі і заздалегідь згенеруємо технічно найдорожчі з них, одночасно обмежуючи швидкість генерації різних розмірів зображень, ми зменшимо навантаження на інфраструктуру обслуговування медіа.
WE6.1.2 Якщо ми додамо вікі-ферми до середовища тестування перед злиттям (pre-merge testing environment), це дозволить командам розробників, які працюють над виробництвом і потребують декількох вікі для тестування своїх поправок в ізоляції, отримати більшу впевненість перед виробництвом і зменшити кількість невловлених дефектів.
WE6.2.1 Якщо ми переглянемо та опублікуємо наш контрольний список готовності до виробництва (Production Readiness Checklist), який чітко визначає передумови для того, щоб послуга вважалася готовою до виробництва, разом із завданнями, які можна виконати самостійно, ми узгодимо очікування між інженерами надійності сайтів (SRE) та командами розробників, покращивши нашу загальну операційну ефективність та масштабованість.
WE6.2.2 Якщо ми оголосимо про створення бібліотеки Golang і nodejs, яка абстрагує багато трудомістких завдань для розробників, вони відреагують, надавши відгуки та висловивши зацікавленість.
WE6.2.4 Якщо ми застосуємо та активно підтримаємо Огляд дизайну збереження даних (Data Persistence design review), ми зможемо визначити шляхи до виробництва.
WE6.3.2 Якщо ми розробимо нові метрики, покращимо інфраструктуру кешу Parsoid та розгорнемо її на двох із «топ-десяти» вікіпедій, ми розробимо критерії продуктивності для рамок довіри, що допоможе підтвердити нашу готовність до розгортання на інших великих вікі та продемонструвати нашу здатність обробляти великі обсяги трафіку в значному масштабі.
WE6.3.3 Якщо ми впровадимо критичні поліпшення підтримки мовних варіантів і у другому кварталі успішно розгорнемо Parsoid щонайменше на трьох вікі з мовними варіантами, ми визначимо та розв'яжемо ключові технічні задачі, необхідні для впевненого розгортання на всіх інших вікі з мовними варіантами.
WE6.4.6 Якщо SRE надасть підтримку інженерним командам Медіавікі — через управління потужністю та трафіком, підготовку та перегляд конфігураційних змін, а також співпрацю з метою дослідження та усунення проблем — ми разом завершимо оновлення PHP 8.3 у другому кварталі та задокументуємо набір рекомендацій для мінімізації критичних залежностей від SRE при майбутніх оновленнях. T360995
WE6.4.7 Якщо ми переведемо щонайменше 90 % усіх користувачів із глобальним root доступом на використання апаратного SSH-ключа для доступу до виробничих серверів Вікімедіа, ми зменшимо ризик того, що скомпрометований ноутбук спричинить серйозне порушення безпеки.
WE6.4.8 Якщо команда інженерів Медіавікі активно стежитиме за проблемами в Медіавікі, пов'язаними з оновленням PHP, і виправлятиме їх, це дозволить команді SRE завершити оновлення PHP 8.3 до листопада 2025 року. T360995
Гіпотези щодо сервісів сигналів і даних (SDS)

[ Ключові результати SDS ]

Обговорення

Коротка назва гіпотези Текст другого кварталу Деталі і обговорення
SDS1.2.1 Якщо ми перенесемо процес XML-дампів з поточної інфраструктури «Dumps 1» до конвеєра даних, що використовує конвеєри вмісту Медіавікі (MediaWiki Content Pipelines), ми зможемо гарантувати SLO та вимкнути експорт XML на основі «Dumps 1».
SDS1.2.2 Якщо ми проведемо огляд і проаналізуємо SLO для історії вмісту Медіавікі (MediaWiki Content History) та платформи подій (Event Platform) / брами подій (Event Gate), ми зможемо перевірити клієнтів, метрики та залежні зацікавлені сторони, а також визначити поліпшення, які можуть бути необхідні для SLO, що допоможе нам уточнити будь-які прогалини в наших щотижневих гарантіях доставки.
SDS1.3.1 Якщо ми впровадимо сигнали з боку клієнта та перевіримо їх у порівнянні з журналами вебзапитів з боку сервера (server-side webrequest logs), ми знайдемо додаткові патерни ботів, які можна охарактеризувати.
SDS1.3.2 Якщо ми візьмемо за основу поточний розподіл ботів і людей та створимо автоматичні сповіщення про зміни в цьому розподілі, ми скоротимо час виявлення наступного непередбаченого патерну автоматизованого трафіку з тижнів до хвилин.
SDS1.3.3 Якщо ми автоматизуємо механізм зворотного заповнення (backfill) вебзапитів і застосуємо його до журналів за травень, ми скоротимо час виправлення майбутніх інцидентів з місяців до днів і вирішимо інцидент «зростання переглядів сторінок у травні».
SDS1.3.4 Якщо ми створимо регулярний, здійснюваний процес внутрішнього аудиту для результатів класифікації ботів, ми зміцнимо довіру до наших рішень і зможемо передбачити зміни в патернах трафіку, які не виявляються автоматично.
SDS1.3.5 Якщо ми проаналізуємо базовий сигнал на стороні клієнта та включимо його в нашу евристику, ми виявлятимемо додаткові патерни ботів у платформі даних.
SDS1.3.6 Якщо ми імпортуємо, проаналізуємо та включимо в нашу евристику репутацію IP-адреси Spur.us, ми виявлятимемо додаткові патерни ботів у платформі даних.
SDS1.3.7 Якщо ми імпортуємо, проаналізуємо та включимо в нашу евристику один сигнал з периферії, ми виявлятимемо додаткові патерни ботів у платформі даних.
SDS1.4.1 Якщо ми підтвердимо існуючий аналіз тенденцій в екосистемі Вікімедіа — перегляди сторінок, метрики авторів і читачів, трафік тощо — ми зможемо впевнено підтримати найважливіші тези для наших найважливіших висновків щодо руху.
SDS1.4.2 кщо ми підтвердимо існуючий аналіз тенденцій в екосистемі Вікімедіа — перегляди сторінок, метрики авторів і читачів, трафік тощо — ми зможемо впевнено підтримати найважливіші тези для наших найважливіших висновків щодо руху.
SDS2.1.1 Якщо ми будемо тісно співпрацювати з командами, які проводять експерименти, ми дізнаємося, як зробити систему більш самообслуговуваною в майбутньому і з якими концептуальними або технічними проблемами вони можуть зіткнутися.
SDS2.1.2 Якщо ми зможемо впровадити краще налагодження для реєстрації подій, то продуктові команди будуть знати, що їх експеримент збирає дані про події, як і очікувалося, що підвищить впевненість власників експериментів.
SDS2.1.3 Якщо ми покращимо реєстрацію та спостережуваність для компонента системи A/B-тестування (xLab) експериментальної платформи та пов'язаних з нею частин Медіавікі, ми зможемо встановити базові показники продуктивності системи та реагувати на збої, пов'язані з експериментами.
SDS2.1.4 Якщо ми щомісяця будемо ділитися історіями та результатами експериментів у всій організації (через зустрічі з питань експлуатації продуктів, зустрічі команди дизайнерів та презентації між командами), то ми створимо органічне застосування платформи для експериментів.
SDS2.1.5 Якщо ми повідомимо користувачам, що їхній інструмент, створений в xLab, містить набір атрибутів, які змінюють категорію ризику, ми відвернемо користувачів інструментів від надмірного збору даних і підвищимо ясність щодо того, яка комбінація атрибутів вимагає перевірки приватності.
SDS2.1.6 Якщо команда зростання займеться впровадженням двох випадків використання (один з A/B-тестом для отримання інформації про можливості групування, а другий з довгостроковою інструменталізацією для вивчення підтримки метрик, подібних до KPI) з Experiment Lab, то ми зможемо оцінити, чи достатньо виконуються вимоги, щоб замінити наше індивідуальне налаштування експериментів у GrowthExperiments.
Гіпотези щодо майбутньої аудиторії (FA)

[ Ключові результати FA ]

Обговорення

Коротка назва гіпотези Текст другого кварталу Деталі і обговорення
FA1.1.4 [Продовження з минулого фінансового року] Якщо ми створимо новий досвід взаємодії з Вікіпедією на платформі Roblox, ми дізнаємося, чи може це бути ефективним способом представити наш бренд молодшій аудиторії (поколінню Альфа).
FA1.1.2 Якщо ми створимо центральний хаб для нових досвідів, пов'язаних з Вікіпедією на itch.io, то зможемо збільшити аудиторію до понад 50 зацікавлених невікепедистів, які надаватимуть нам відгуки, що допоможе нам дізнатися, що працює в іграх, а що ні.
FA2.2.1 Якщо ми інвестуємо в управління спільнотою на платформах коротких відео, то до кінця другого кварталу (грудень 2025 року) ми побачимо 30% квартальне зростання відсотка переглядів від нових глядачів на TikTok — і на всіх платформах для коротких відео (SFV) ми отримаємо разом 50 000 взаємодій (вподобайок і коментарів-відповідей) на коментарі бренду, залишені на зовнішньому вмісті, що допоможе нам підвищити видимість і стимулювати взаємодію з аудиторією, яку ми зараз не охоплюємо.
FA2.2.2 Якщо ми розробимо та отримаємо схвалення внутрішньої стратегії програми Вікіпедії партнерства з творцями (Wikipedia Creator Partnerships Program) та матеріалів для поширення назовні (включно з описом нашої цінності для творців, критеріями партнерства, процесом укладення договорів та тим, як вміст творців буде відображатися на власних каналах та каналах творців), ми зможемо створити потужну стратегію для творців, яка допоможе нам охопити нашим вмістом знань нову аудиторію в соціальних мережах.
Гіпотези Продуктової та інженерної підтримки (PES)

[ Ключові результати PES ]

Обговорення

Коротка назва гіпотези Текст другого кварталу Деталі і обговорення
PES1.1.5 Якщо ми впровадимо цілі рівня обслуговування (SLO) для історії вмісту Вікімедіа (MediaWiki Content History) та Вікіфункцій у Sloth/Pyrra, ми введемо у виробництво ще дві SLO.
PES1.1.6 Якщо ми протестуємо Sloth із ретроактивними даними з існуючих SLO, ми зрозуміємо, чи є Pyrra або Sloth (або щось інше) відповідним інструментом для нашого підходу, що опирається на фіксовані вікна бюджету помилок. Ми довідаємося, як підтримувати власників послуг за допомогою підходу самообслуговування до метрик SLO та використовувати їх у процесі прийняття рішень.
PES1.2.4 Якщо в першому кварталі ми започаткуємо пілотний проєкт щоквартального перегляду побажань та сигналів спільноти за участі трьох команд, ми залучимо продуктових менеджерів до інтеграції сигналів спільноти в їхні квартальні та річні процеси планування.
PES1.2.5 Якщо ми додамо можливість фільтрувати та сортувати побажання в розширенні Wishlist до вже наявних покращень, що дозволяють категоризувати за допомогою тегів та голосування, ці три покращення збільшать кількість унікальних учасників Wishlist щонайменше на 30%.
PES1.3.3 Якщо ми створимо щонайменше 5 цікавих інтервенцій на платформі, які будуть з'являтися на основі взаємодії користувача, ми визначимо, якими будуть тригери для портальної сторінки та гаджета Birthday Mode. Тестування зручності використання покаже нам, які інтервенції створюють позитивні асоціації з нашим брендом. Ця гіпотеза має бути перевірена до вікіконференції Північної Америки (WikiCon North America) в кінці жовтня.
PES1.3.4 Якщо ми створимо захопливий вебсайт, присвячений історії, сьогоденню та майбутньому Вікіпедії, у співпраці з членами відділу комунікацій, спрямований на залучення онлайн-аудиторії віком 18-34 років у цільових областях кампанії, це приведе до більшого зв'язку з Вікіпедією через соціальні мережі та іншу онлайн-діяльність. Це сприятиме досягненню КР відділу комунікацій щодо збільшення присутності бренду на 10 процентних пунктів, а також покаже нам, чи динамічні підходи до вмісту покращують привабливість бренду.

Третій квартал

Третій квартал (Q3) річного плану WMF охоплює січень-березень 2026 року.

Гіпотези Вікідосвіду (ВД)

[ Ключові результати ВД ]

Обговорення

Коротка назва гіпотези Текст третього кварталу Деталі і обговорення
WE1.1.3 Якщо команда редагування зробить початковий набір пропозицій щодо редагування доступним у VE через параметр URL-адреси та запросить ≥10 новачків та патрульних надати відгуки про нього, ми дізнаємося, які покращення потрібно буде внести, перш ніж проводити контрольований експеримент для оцінки впливу втручання.
WE1.1.4 Якщо ми впровадимо перевірку посилань (Reference Check) на en.wiki шляхом контрольованого експерименту, ми побачимо зростання на ≥4% конструктивних редагувань, які публікують нові (або відносно нові) волонтери, і дізнаємося, чи є достатня підтримка серед патрульних і модераторів, щоб розширити використання функції.
WE1.1.12 Якщо ми дозволимо ≥3 волонтерам оцінити ≥30 зразків редагувань для кожної з 10 нових мов, на які ми прагнемо масштабувати Tone Check, ми дізнаємося, як часто волонтери погоджуються з прогнозами моделі, і зможемо вирішити, до яких нових вікі звернутися щодо розгортання Tone Check.
WE1.1.14 Якщо ми запропонуємо новим волонтерам враховувати тон, в якому вони пишуть, коли модель штучного інтелекту виявляє, що вони використовують ненейтральну мову, то ми побачимо зниження на ≥4% відсотка нових редагувань контенту, опублікованих новими волонтерами, які скасовуються на підставі WP:NPOV (та пов'язаних політик).
WE1.1.17 Якщо ми розробимо механізм генерації завдань для структурованого завдання Revise Tone, інтегруємо наші нещодавні знання про те, який контент включати або фільтрувати, та надамо конвеєри, які автоматично оновлюють список завдань, ми зможемо провести якісну оцінку згенерованих завдань та A/B-експеримент, який перевірить, чи допомагає цей тип завдання редакторам-початківцям робити більш конструктивні редагування.
WE1.1.18 Якщо ми проаналізуємо заздалегідь визначений набір провідних індикаторів приблизно через 2 тижні після початку A/B-тестування структурованого завдання Revise Tone, Ми зможемо визначити, які – якщо такі є – аспекти комплексного досвіду потребують коригування або дослідження, перш ніж ми зможемо впевнено оцінити вплив цієї функції.
WE1.1.19 Якщо ми дозволимо користувачам мобільного веб-сайту редагувати будь-який розділ статті, незалежно від того, яку іконку редагування вони спочатку натиснуть, тоді рівень відмови від редагування на мобільних пристроях для новачків знизиться на #%, оскільки вони зможуть легше знаходити контент, який вони натиснули та відредагували, щоб змінити.
WE1.1.20 Якщо команда Growth масштабує завдання «Додати посилання» щонайменше на 10 додаткових Вікіпедій, тоді ми зможемо завершити аналіз провідних індикаторів, щоб підтвердити, що завдання виконується належним чином, та визначити будь-які вікі, які можуть потребувати подальшого перегляду.
WE1.1.21 Якщо ми розгорнемо нову версію моделі Додати посилання як для нещодавно підключених вікі, так і для вікі, які зараз використовують Додати посилання, тоді команда Growth зможе розгорнути Додати посилання як структуроване завдання для вікі, де його раніше не існувало, а вікі, які вже мали це завдання, отримають оновлену модель зі свіжішими даними навчання та покращеною продуктивністю офлайн.
WE1.1.22 Якщо ми Якщо покращити початковий електронний лист із підтвердженням «Ласкаво просимо до Вікіпедії», відсоток нових облікових записів, які підтверджують свою адресу електронної пошти, зросте. Це дозволить Growth повторно залучити ці облікові записи за допомогою подальших електронних листів та забезпечити отримання ними сповіщень на сторінках обговорення.
WE1.1.23 Якщо ми запропонуємо легкодоступним моделям GenAI генерувати та ранжувати набір пропозицій редагування для диверсифікованої вибірки зі 150 статей англійської Вікіпедії, то ми дізнаємося, які типи завдань редагування можуть створювати ці загальні моделі в великих масштабах, і отримаємо приблизне, анекдотичне розуміння корисності цих пропозицій. Цей ранній сигнал допоможе нам оцінити, чи можна генерувати деякі типи завдань у великих масштабах за допомогою універсальних моделей (з тонким налаштуванням або без нього), чи вони вимагатимуть більш спеціалізованих підходів – зрештою, це допоможе нам перевірити, чи варто рухатися в цьому напрямку «єдина модель – багато пропозицій».
WE1.1.24 Якщо ми попросимо нових (або новіших) волонтерів, які вставляють текст із зовнішнього сайту, підтвердити, що вони самі написали вміст, який намагаються додати, то ми побачимо зменшення на ≥10% частки нових редагувань вмісту, опублікованих новими (або новішими) волонтерами, які були скасовані на підставі ВП:КОПІВІО (та пов'язаних політик).
WE1.2.6 Якщо ми розробимо функцію встановлення цілей через реєстрацію подій, то через реєстрацію подій буде створено більше співпраці.
WE1.3.3 Якщо ми започаткуємо експеримент з показом панелі модератора новим редакторам, 10% учасників, які її відвідали, будуть робити це два тижні поспіль.
WE1.3.4 Якщо ми розгорнемо фільтр «Ризик повернення» на понад 150 додаткових Вікіпедіях, яким наразі бракує моделей шкідливості/добросовісності, то ми побачимо збільшення кількості патрулів модераторів для учасників, які використовують особисту панель модераторів, порівняно з тими, хто не має доступу до панелі.
WE1.5.1 Якщо ми впровадимо панель інструментів для вивчення семи показників учасників та стандартизуємо розрахунок принаймні одного показника за допомогою dbt, то зможемо надати продуктовим командам, що працюють з учасниками, можливість самостійно отримувати аналітику метрик та розробити стандарт для зберігання логіки розрахунку метрик.
WE1.5.3 Якщо Data Engineering створить продукт даних типів редагування до кінця третього кварталу, то 6 дій модераторів, які є «складними» для вимірювання, стануть «простими», що дозволить Movement Insights визначити щомісячну метрику активного модератора як наступний крок.
WE1.5.4 Якщо ми створимо прототип панелі з метриками активного модератора, які доступні наразі, то ми зможемо створити повну панель до кінця четвертого кварталу.
WE1.6.1 Якщо ми впровадимо користувацьку панель мітки списку спостереження, ми очікуємо, що 5% користувачів, які мають понад 100 сторінок у своєму списку спостереження, використовуватимуть ці мітки протягом першого місяця.
WE2.2.13 Якщо ми поширимо інформацію про доступність функції таблиці спряження у спільноті Wiktionary, ми зберемо ранні сигнали про розуміння та зручність використання редактором, які можуть допомогти у майбутніх покращеннях.
WE2.2.20 Якщо ми розгорнемо Вікіфункції у вікі, де увімкнено Parsoid, ми зможемо продовжувати тестувати, чи ця система залишається продуктивною та придатною для використання при все ширшому її розгортанні.
WE2.2.21 Якщо ми дозволимо обмежений набір реентерантних функцій в оцінювачі, можна буде збільшити залежність від оцінюваних реалізацій, тим самим використовуючи найпродуктивнішу частину серверної частини.
WE2.2.22 Якщо ми напишемо явний інтерпретатор для мови композиції, оркестратор буде продуктивнішим, а подальші функції покращення продуктивності буде легше реалізувати.
WE2.2.23 Якщо ми дозволимо учасникам повторно використовувати цілі блоки композиції в різних функціях, ми зменшимо повторювану роботу та значно пришвидшимо створення нових реалізацій, особливо для подібних лінгвістичних функцій.
WE2.2.24 Якщо ми визначимо чітку структуру документації та точки входу, розробникам функцій буде легше знаходити відповідні інструкції та менше тертя під час їх створення.
WE2.2.25 Якщо ми систематично визначимо найбільші точки тертя у процесі створення функцій, ми зможемо виявити невеликий набір високоефективних покращень, які зроблять створення та ітерацію функцій ефективнішими.
WE2.2.26 Якщо ми впровадимо легке локальне довідкове рішення (через спливаючі вікна) для абстрактної Вікіпедії, ми зможемо створити початковий механізм цитування, щоб повідомити, чи потрібні складніші рішення.
WE2.3.4 Якщо ми створимо та випустимо початкову версію платформи абстрактної Вікіпедії, ми зможемо продемонструвати технічну можливість роботи екосистеми кількома мовами.
WE2.3.5 Якщо ми взаємодіятимемо з невеликою кількістю мовних спільнот Вікіпедії з обмеженими ресурсами на конкретному прикладі абстрактного контенту, ми зможемо перевірити, чи є контент, створений поза їхньою локальною вікі, прийнятним, та визначити умови, необхідні для прийняття.
WE2.3.6 Якщо ми розробимо, як контент абстрактної Вікіпедії відображається та презентується в локальних Вікіпедіях, а також як місцеві спільноти приймають рішення щодо інтеграції, ми зможемо соціалізувати пропозицію, досягти угоди та впевнено планувати роботу з розробки на четвертий квартал.
WE2.5.1 Якщо ми розгорнемо кандидата-замінника Blazegraph в eqiad та доповнимо існуючу роботу з оцінювання за допомогою виробничого WDQS. аналіз трафіку та відтворення, тоді ми підтвердимо, що новий бекенд працює порівняно добре, підтримує реальні запити SPARQL та готовий до обмеженого впливу живого трафіку, як тільки навколишня екосистема (інтерфейс користувача, моніторинг, адаптація та конвеєр оновлення індексу в реальному часі) буде підготовлена.
WE2.5.2 Якщо ми визначимо правила доступу для платформи Wikidata, ми зможемо краще контролювати навантаження на сервери WDQS під час нашої міграції бекенду.
WE2.5.3 Якщо ми визначимо когорту персон користувачів для тестування нашої нової бекенд-системи, ми будемо готові до пілотного та наступних фаз переходу на Blazegraph.
WE2.5.4 Якщо ми створимо план міграції в одному документі, ми зможемо узгодити та керувати виконанням усіх аспектів міграції.
WE2.5.5 Якщо ми оптимізуємо модель ризику повернення Wikidata для виведення з низькою затримкою та розгорнемо її стабільним, масштабованим способом на LiftWing, тоді команда Wikimedia Enterprise зможе інтегрувати сигнали ризику повернення у свій конвеєр продукту, що дозволить клієнтам отримувати своєчасні, високоякісні результати моделі.
WE3.1.8 Якщо ми оцінимо 2 семантичні пошуки прототипи (пошук природною мовою, питання та відповіді) із зовнішніми учасниками, ми можемо дізнатися, чи бачать користувачі цінність у покращених інструментах пошуку, та надати командам читачів рекомендації щодо того, як рухатися далі з MVP для пошуку та виявлення.
WE3.1.12 Якщо ми зберемо набір даних для еталонного аналізу, що складається з набору репрезентативних запитів та анотацій відповідних результатів пошуку, ми зможемо виконувати офлайн (тобто без досліджень користувачів) оцінку якості результатів пошуку різних моделей пошуку.
WE3.1.15 Якщо ми протестуємо гібридні MVP для пошуку, які поєднують запити на основі ключових слів, природної мови та значення, у додатку для Android, ми швидко визначимо підхід та шаблони проєктування, які збільшують загальну залученість до пошуку на 10% без негативного впливу на задоволення, затримку або утримання.
WE3.1.16 Якщо ми визначимо вимоги до моделі питань та відповідей, ми створимо результати моделі, щоб поділитися ними зі спільнотою для отримання зворотного зв'язку, який ми можемо включити у виробничий експеримент.
WE3.1.17 Якщо Пошук надасть готову до виробництва (стабільну, продуктивну) інфраструктуру векторного пошуку, яка підтримує обробку семантичних запитів, включаючи кінцеву точку MediaWiki, тоді машинне навчання та дослідження зможуть генерувати вбудовування та інтегрувати. їхні моделі з системою, що дозволяє MVP отримувати дані на основі вбудовування.
WE3.1.18 Якщо ми розгорнемо сервіс виведення вбудовування Qwen3, сумісний з нашим існуючим стеком OpenSearch, то мобільні додатки зможуть експериментувати з генерацією фрагментів статей та вбудовування запитів через Qwen3, що має перевершити вбудовування, створені вбудованими моделями OpenSearch.
WE3.3.6 Якщо ми зробимо дані виведення тем статей доступними через сервіс, який відповідає узгодженим вимогам масштабованості та доступності, а також будь-які необхідні заповнення даними, то ми створимо технічну основу, необхідну для підтримки майбутнього персоналізованого досвіду читачів, який залежить від цих даних.
WE3.4.1 Якщо ми будемо працювати над розгортанням гібридної точки присутності (PoP/CDN), це дозволить нам за необхідності створити як повні PoP, так і міні-PoP (фізичні та хмарні), заклавши основу для розгортання прототипу міні-PoP у майбутньому.
WE3.5.2 Якщо ми запропонуємо донорам значок, що підтверджує їхній статус, щонайменше 70% донорів, які погодяться, повідомлять про позитивний настрій у пов'язаному опитуванні.
WE3.6.5 Якщо відділи продуктів і технологій та фандрейзингу співпрацюватимуть над спільною стратегією диверсифікації можливостей для пожертвувань на платформі та управління та визнання читачів, які жертвують кошти, ми встановимо чіткі, узгоджені цілі та показники, пов'язані з нашими стратегіями споживачів та фандрейзингу.
WE3.6.6 Якщо ми розробимо єдину стратегію вимірювання, ми дозволимо оцінити багаторічну стратегію споживачів та визначити дорожню карту для розробки показників та можливостей звітності.
WE3.6.7 Якщо ми проведемо вторинне A/A-тестування рівня утримання для користувачів, які не вийшли з системи, ми почнемо встановлювати сезонні тенденції рівня утримання, які ми зможемо використовувати для майбутніх кварталів.
WE3.6.8 Якщо ми систематично порівнюватимемо потреби та поведінку в пошуку інформації 1) нових та нечастих читачів англійської Вікіпедії та тих, хто її не читає, з потребами 2) поточних читачів англійської Вікіпедії, одночасно опитуючи обидві групи населення, ми зможемо визначити ключові дані про демографічні характеристики, потреби в онлайн-інформації та онлайн-платформи, що використовуються цією аудиторією, визначаючи потенційні можливості для розширення нашої читацької аудиторії, а також потенційні загрози для нашої існуючої читацької аудиторії.
WE3.8.1 Якщо ми додамо додаткові модулі до вкладки активності та масштабуємо її для всіх користувачів, ми побачимо 5% збільшення загальної кількості створених облікових записів додатків iOS порівняно з показниками до випуску.
WE3.9.1 Якщо ми оновимо візуальні основи додатка Вікіпедія для iOS, налаштування компонентів за замовчуванням та поведінку навігації, щоб вони відповідали мові дизайну Apple Liquid Glass, чітко визначаючи дизайн та поведінку для високопріоритетних резервних варіантів у різних версіях ОС, тоді реалізація подальшої розробки буде чіткішою, менш ризикованою, а додаток буде більш адаптованим до платформи, коли Apple примусово переключить користувачів.
WE3.10.1 Якщо ми протестуємо прототип дизайну стрічки Explore, побудований з легкою персоналізацією, чіткими сигналами свіжості та повторюваністю. Завдяки шаблонам, властивим Вікіпедії (наприклад, тематичним кролячим норам, обмеженим у часі основним темам та інтерактивним елементам), випадкові читачі повідомлятимуть про розуміння мети запропонованої стрічки, швидше досягатимуть моменту «ага» та демонструватимуть сильніший намір щодо щоденного використання. Візуальний дизайн, який ми рекомендуємо для подальшого розвитку, буде описано як зручний для використання та узгоджений з рухом Вікімедіа.
WE4.1.3 Якщо ми оновимо 6 Вікіпедій (англійську, французьку, німецьку, іспанську, італійську, польську) до кінця другого кварталу, ми завершимо перший етап впровадження нового Legal Footer у відповідь на вимоги DSA.
WE4.2.5 Якщо ми проведемо дослідження, проконсультуємося зі спільнотами та дослідимо технічні рішення, ми зможемо визначити набір структурованих причин блокування, які можна використовувати у всіх вікі WMF.
WE4.6.8 Якщо ми будемо моніторити вплив форм Zendesk і Медіавікі, які ми створили в першому кварталі, то зможемо запропонувати технічні зміни на наступні квартали, які дозволять краще автоматизувати позосталу частину процесу відновлення облікового запису.
WE5.1.3c Якщо ми впровадимо обмеження швидкості для всіх API, що проходять через шлюз, ми зможемо зменшити кількість анонімних запитів API, які досягають нашої бекенд-інфраструктури, обмеживши запити на основі класів користувачів, що дає вищі ліміти для автентифікованих користувачів та користувачів спільноти.
WE5.1.5 Якщо ми покращимо стійкість та надійність нашої реалізації OAuth 2.0, ми зможемо переконати більше розробників використовувати OAuth та підтримати міграцію мобільних додатків Вікіпедії, підвищивши впевненість у тому, що на нього можна покластися для високопрофільних додатків.
WE5.1.5b Якщо ми покращимо досвід розробників для створення та управління З клієнтами OAuth 2.0 ми зможемо збільшити кількість програм, що використовують OAuth 2.0, відмовившись від OAuth 1.0 для нових програм та просуваючи OAuth 2.0 як бажаний варіант для автентифікації API.
WE5.2.2c Якщо ми перенаправимо всі API, які зараз проходять через API Gateway, через спільний шлюз, ми зможемо повністю відмовитися від історичного API Gateway та забезпечити узгодженість для всіх HTTP/веб API Wikimedia, що працюють зі спільнотою.
WE5.2.6 Якщо ми введемо елементи керування доступом до API карти сайту, щоб дозволити доступ лише довіреним ботам, ми зможемо покращити стратегічне узгодження та зменшити ризик зловмисного парсингу.
WE5.2.8 Якщо ми створимо спеціальні модулі API для всіх розширень API та автономну функціональність у MediaWiki Core, ми забезпечимо забезпечення вищої якості документації з незалежним управлінням та версійним керуванням.
WE5.2.9 Якщо у нас буде краще розділення питань щодо реєстрації API та процесів визначення специфікацій, ми спростимо складність управління API та створимо кращий досвід розробників для авторів API.
WE5.2.10 Якщо ми проведемо екскурсію, спеціально зосереджену на консолідації API v2 та прогалинах у функціях, ми зможемо рухатися швидше з впровадженням версії 2.‎
WE5.2.11 Якщо ми експериментуватимемо та впровадимо процеси стандартизації документації, яка зараз знаходиться на порталі API, ми зможемо консолідувати джерела інформації та покращити узгодженість документації.‎
WE5.3.1b Якщо ми опублікуємо та ітеративно вдосконалимо проєкт настанов та демонстрацій UX, ми створимо базову структуру, готову до внутрішнього тестування та ітеративного вдосконалення, щоб підготуватися до ширшого публічного використання.
WE5.3.2b Якщо ми створимо партнерську пілотну програму для експериментів з атрибуцією Вікімедіа, ми зможемо продемонструвати взаємовигідний вплив атрибуції повторними користувачами для стимулювання залучення та внеску до Вікімедіа.‎
WE5.4.6 Якщо до кінця другого кварталу ми класифікуємо основних N пошукових роботів (павуків) як відомих ботів, ми зможемо обмежити кількість ресурсів, які вони використовують.
WE5.4.8 Якщо ми почнемо запроваджувати обмеження швидкості, адаптовані до різних класів окремих клієнтів для медіафайлів, ми зменшимо навантаження на нашу інфраструктуру, пов'язане зі скануванням.‎
WE5.4.9 Якщо ми додамо дані про репутацію IP-адрес на резидентних проксі-серверах до нашого виявлення ботів, це покращить нашу здатність блокувати скрепери.‎
WE5.4.10 Якщо ми припинимо дозволяти генерацію нестандартних розмірів мініатюр, це зменшить навантаження на нашу інфраструктуру обслуговування медіа.‎
WE5.4.11 Якщо ми визначимо два сигнали з високою достовірністю з інцидентів скрепінгу/DDoS у грудні 2025 року та передамо їх до SRE, тоді SRE зможе розробити ефективніші автоматизовані правила пом'якшення наслідків для майбутніх подібних інцидентів.‎
WE5.4.12 Якщо ми зможемо підтвердити, звідки і від кого надходить запит на зображення, ми зможемо приймати більш обґрунтовані рішення щодо обмеження їхньої частоти.
WE6.1.2 Якщо ми додамо вікі-ферми до середовища тестування перед злиттям, це дозволить командам розробників, які працюють над виробництвом і потребують декількох вікі для тестування своїх патчів в ізольованому режимі, отримати більшу впевненість перед запуском у виробництво та зменшити кількість дефектів, що проникають у виробництво.
WE6.1.3 Якщо ми вирішимо 5 найнестабільніших тестів Selenium протягом наступних 90 днів, ми підвищимо довіру розробників до автоматизованого тестування браузерів як цінної частини робочого процесу перед розгортанням.
WE6.2.4 Якщо ми застосуємо та активно підтримаємо Огляд дизайну збереження даних (Data Persistence design review), ми зможемо визначити шляхи до виробництва.
WE6.2.5 Співпраця з групою SLO та збір відгуків від команд, які зараз з ними працюють, допоможе нам не лише виявити прогалини та покращення для контрольного списку готовності до виробництва, але й адаптувати його таким чином, щоб безпосередньо сприяти впровадженню та адаптації SLO.
WE6.2.6 Пілотно випробувавши контрольний список готовності до виробництва на проксі-сервісі hCaptcha на етапах запуску та високої важливості, ми виявимо невідстежуваний технічний борг та створимо видимий журнал робіт, який продемонструє цінність фреймворку, одночасно формуючи повторюваний процес для послідовного впровадження в усіх сервісах.
WE6.2.7 Спільно вдосконалюючи контрольний список готовності до виробництва з урахуванням внесків та внесків SRE, ми гарантуємо, що він відповідає реальним операційним потребам, створимо спільну відповідальність та створимо практичний інструмент, який команди вважають цінним у впровадженні.
WE6.2.8 Аналізуючи відгуки про нашу співпрацю з групою SLO, пілотний проєкт проксі-сервера hCaptcha та співпрацю SRE, ми визначимо, які елементи контрольного списку та кроки процесу потребують чіткіших інструкцій або допоміжних ресурсів, та визначимо наступні кроки для оптимізації фреймворку, щоб зробити впровадження можливим до грудневих канікул.
WE6.2.9 Якщо ми впровадимо node.js service-utils, ми зможемо випустити, у тестовому режимі, будь-який з наступних варіантів: маршрутизація service-mesh або OpenTelemetry. публікація.‎
WE6.3.2 Якщо ми розробимо нові метрики, покращимо інфраструктуру кешу Parsoid та розгорнемо її на двох вікіпедіях з «десятки найкращих», ми розробимо критерії ефективності для рамки довіри, що допоможе перевірити нашу готовність до розгортання на інших великих вікі та продемонструє нашу здатність обробляти великі обсяги трафіку в масштабі.‎
WE6.3.3 Якщо ми впровадимо критичні покращення підтримки мовних варіантів та успішно розгорнемо Parsoid щонайменше на 3 вікі з мовними варіантами у другому кварталі, ми визначимо та вирішимо ключові технічні проблеми, необхідні для впевненого розгортання на всіх решті вікі з мовними варіантами.‎
WE6.3.4 Якщо ми перевіримо якість, виявимо, сортуватимемо та виправимо помилки в процесі читання на різних платформах для переглядів читання Parsoid, ми збережемо якість процесу читання та розблокуємо подальше масштабування на вікі.‎
WE6.3.5 Якщо ми прагнемо до метрики часу до першого байта (TTFB) <= 110% від застарілого для звернень до кешу парсера та <= 150% від застарілого для промахів у кеші парсера, ми зможемо розгорнути її на всіх Вікіпедіях, окрім китайської та англійської, до кінця третього кварталу без жодних показників ефективності. скарги. Це допоможе перевірити нашу готовність до розгортання в англомовній Вікіпедії, підготувавши нас до обробки великих обсягів трафіку в масштабі, розуміючи можливості нашого кешу.
WE6.4.4 Якщо ми об'єднаємо наші домени, обслуговуючи всі перегляди сторінок на сайтах MediaWiki через канонічний домен, то ми зменшимо складність платформи та ризики SEO, усунувши перенаправлення на мобільний піддомен. Завершення вимірюється зменшенням переадресацій для мобільних відвідувань на канонічних доменах зі 100% до 0%.
WE6.4.7 Якщо ми переведемо щонайменше 90 % усіх користувачів із глобальним root доступом на використання апаратного SSH-ключа для доступу до виробничих серверів Вікімедіа, ми зменшимо ризик того, що скомпрометований ноутбук спричинить серйозне порушення безпеки.
WE6.4.8 Якщо команда інженерів MediaWiki активно відстежуватиме та виправлятиме проблеми в MediaWiki, пов'язані з оновленням PHP, це дозволить команді SRE завершити оновлення PHP 8.3 до листопада 2025 року.
Гіпотези щодо сервісів сигналів і даних (SDS)

[ Ключові результати SDS‎ ]

Обговорення

Коротка назва гіпотези Текст третього кварталу Деталі і обговорення
SDS1.5.1 Якщо ми створимо регулярний, здійснюваний процес внутрішнього аудиту для результатів класифікації ботів, ми зміцнимо довіру до наших рішень і зможемо передбачити зміни в патернах трафіку, які не виявляються автоматично.
SDS1.5.2 Якщо ми розгорнемо інструмент Test Kitchen зі 100% вибіркою та ідентифікатором запиту, ми зможемо фіксувати всі запити незалежно від того, чи надсилали вони події на стороні клієнта, та аналізувати їх на предмет поведінки ботів.
SDS1.5.3 Якщо ми проаналізуємо базовий сигнал на стороні клієнта та включимо його в нашу евристику, ми виявлятимемо додаткові патерни ботів у платформі даних.
SDS2.2.4 Якщо відділ безпеки та цілісності продукту перевірить GrowthBook та FerretDB, ми зможемо виявити, а потім пом'якшити та/або усунути будь-які суттєві ризики перед запуском у виробництво.
SDS2.2.5 Якщо ми оновимо Test Kitchen JS та PHP SDK методами реєстрації впливу експерименту, нам не потрібно буде розглядати всі події як події впливу, що покращить продуктивність запитів призначення експерименту в GrowthBook та дасть точніші результати експерименту.
SDS2.4.2 Якщо ми безпечно розширимо реєстрацію трафіку за допомогою контрольованого стрес-тестування, ми збільшимо статистичну потужність для експериментів команди Reader, скоротивши терміни експерименту та покращивши прийняття рішень. впевненість.‎
Гіпотези щодо майбутньої аудиторії (FA)

[ Ключові результати FA ]

Обговорення

Коротка назва гіпотези Текст третього кварталу Деталі і обговорення
FA1.1.1 Якщо ми створимо центральний центр для нових вражень від Вікіпедії на [1], то ми зможемо розширити аудиторію з >50 зацікавлених користувачів, які не є вікіпедистами, і які нададуть нам відгуки, що допоможе нам дізнатися, що працює, а що ні в іграх.‎
FA1.1.2 Якщо ми створимо та протестуємо 3 різні функції пошуку контенту на основі додатків як короткі експерименти, ми зможемо поділитися рекомендаціями з командою Apps щодо того, як ефективно взаємодіяти з новим поколінням користувачів додатків та утримувати їх.‎
FA1.1.3 Якщо ми створимо 4 фільтри TikTok та опублікуємо їх у нашому обліковому записі TikTok, ми зможемо дізнатися, наскільки добре ми можемо стимулювати створення контенту Вікіпедії поза платформою.‎
FA1.1.6 Якщо ми створимо 3 різні потенційні попередні перегляди посилань на Вікіпедію, якими ділимося в Discord, ми зможемо внутрішньо узгодити нашу стратегію вимірювання та виконання та співпрацювати з командою ProdEng Discord.‎
FA2.2.1 Якщо ми інвестуватимемо в управління спільнотою на платформах коротких відео, то до кінця другого кварталу (грудень 2025 року) ми побачимо 30% квартальне зростання відсотка переглядів від нових глядачів на TikTok, а на всіх платформах коротких відео ми отримаємо 50 000 взаємодій (лайків та відповідей на коментарі) на коментарях брендів, залишених до зовнішнього контенту, що допоможе нам підвищити видимість та залучити аудиторію, до якої ми зараз не охоплюємо увагу.
FA2.2.2 Якщо ми розробимо та отримаємо схвалення внутрішньої стратегії Програми партнерства творців Вікіпедії та зовнішніх матеріалів для поширення (включаючи виклад нашої цінності для творців, критерії партнерства, процес укладання контрактів та те, як контент творців відображатиметься на власних каналах та каналах творців), ми зможемо створити надійну стратегію творців, яка допоможе нам охопити нову аудиторію в соціальних мережах за допомогою нашого інформаційного контенту.
Гіпотези Продуктової та інженерної підтримки (PES)

[ Ключові результати PES ]

Обговорення

Коротка назва гіпотези Текст третього кварталу Деталі і обговорення
PES1.3.5 Якщо ми створимо конфігурацію спільноти для пасхалок та використовуватимемо Reader Experience на повний робочий день для перевірки коду, ми зможемо запустити проєкт 15 лютого та відстежувати його вплив.
PES1.3.6 Якщо ми створимо індивідуальні публікації в соціальних мережах для 25 років Вікіпедії (25YoW), ми зможемо досягти такого ж успіху з соціальними враженнями, як і існуючі шаблони Comms, та довести, що ми можемо підтримувати Comms, збільшуючи їхні можливості. Бенчмаркінг буде проводитися на основі публікацій Truth Collective про той самий проєкт.
PES1.4.1 Якщо ми зустрінемося з 4-5 командами, які в основному не використовують Codex (включаючи, але не обмежуючись, команди, які в основному використовують OOUI), ми зможемо задокументувати блокування для тих команд, які впроваджують Codex для поточних та майбутніх проєктів.
PES1.4.2 Якщо ми зробимо Codex PHP простішим у використанні та достатньо стабільним для випуску версії 1.0, тоді команди впровадять Codex PHP для інтерфейсів, що генеруються сервером. Це збільшить використання Codex PHP з 3 проєктів до 5.
PES1.5.1 Якщо ми оновимо Sloth з прототипу до заміни Pyrra, шляхом інтеграції існуючих сервісів, ми зможемо об'єднатися в єдиний набір інформаційних панелей SLO, удосконалити наші сповіщення та оптимізувати процес інтеграції SLO.
PES1.5.2 Якщо ми продовжимо інтегрувати метрики SLI для Wikifunctions та MediaWiki Content History, а також перевіряти метрики для WikiData Query Service та EditCheck, ми налагодимо проблеми як зі звітністю інформаційних панелей, так і зі взаємодією власників сервісів щодо гучних, але неврахованих звітів SLO.

Q4

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

Wiki Experiences (WE) Hypotheses

[ WE Key Results ]

Обговорення

Hypothesis shortname Q4 text Details & Discussion
WE1.3.3 If we launch an experiment to surface a moderator dashboard to newer editors, 10% of contributors who visit it do so two weeks in a row.
WE1.5.1a If we add new metrics to the Contributors dashboard using DBT we will enable contributor product teams to get more actionable insights into editing trends
WE1.5.5 If we automate updates of DBT models with Airflow on a fixed schedule, we will allow Movement Insights to build analyses and reports on those models using up-to-date information.
WE1.5.6 If we document workflows and establish per-team default output locations and access controls for dbt models, we will allow dbt usage to scale across team members in Movement Insights and other teams.
WE1.5.7 If we extend the MAM dashboard as specified, then we will have a more complete picture of moderator pipeline health that can inform decisions in the Contributor strategy.
WE1.6.1 If we introduce custom watchlist labels, we expect the labels to be used by 5% of users with more than 100 pages on their watchlist in the first month.
WE1.7.2 By testing a design prototype of the in-app webview editing flow with newcomers on the mobile apps, we will identify the highest-risk friction points that could cause abandonment before publishing - specifically around context shift, editor comprehension, and edit attribution - so that we can prioritize what must be resolved before this approach can successfully onboard new editors at scale.
WE1.7.4 If we prompt readily available GenAI models to generate and rank a set of edit suggestions for a diversified sample of 150 English Wikipedia articles, then we will learn what types of editing tasks these generic models can produce at scale and gain a rough, anecdotal understanding of the usefulness of these suggestions. This early signal will help us assess whether some task types could plausibly be generated at scale with generic models (with or without fine-tuning), or whether they would require more specialized approaches - ultimately helping us validate whether pursuing this "single model many suggestions" direction is worthwhile.
WE1.7.5 If we replace the unstructured Copyedit task with the Revise Tone structured task in a controlled experiment, then the task completion rate for Revise Tone edits made by junior editors will be higher than the completion rate for edits made through the Copyedit task.
WE1.7.6 If we test 2 structured workflows via design prototypes that align contribution opportunities with what readers arrive motivated to learn, and frame contributions as ways to act on curiosity or share knowledge they already possess, then concept testing will help us identify approaches that inspire readers to imagine themselves as contributors.
WE1.7.7 If we present an exit survey to users with ≤100 cumulative edits who abandon mobile editing sessions after spending ≥2 seconds in either the mobile visual or source editor, we will discover patterns in the reasons behind this behavior and be able to decide what interventions we will prioritize to increase the mobile web edit completion rate.
WE1.7.8 If we present junior contributors who enter the mobile VisualEditor with immediately actionable edit suggestions, then the proportion of edit sessions that result in someone publishing a constructive edit will increase by ≥10%.
WE1.7.9 If we publish a proposal on-wiki to enable VisualEditor by default for newcomers on mobile web at en.wiki, we will define the steps needed to make this happen.
WE1.8.2 If we improve the logged out edit warning, the account creation rate among newcomers on mobile exposed to the warning will increase by at least 2% relative to the control group.
WE1.8.3 If we improve the account creation form, the registration completion rate among mobile users who land on the form will increase by at least 2% relative to the control group.
WE1.8.4 If we add a user account button to the header on mobile web, then the number of new accounts created on mobile will increase by at least 2% relative to the control group.
WE1.8.5 If we surface Reading Lists to logged-out readers on mobile web, the registration rate will increase by at least 2% relative to the control group.
WE1.9.2

If we introduce key questions about factors that impact editor motivations [i] into the 2026 Community Insights survey, by the end of Q4 we will be able to provide ≥5 research insights which can inform our Contributors strategy implementation, with a focus on editor progression and recognition.

[i] Defined through the lens of competence (ability to use tools and resources), autonomy (ability to navigate the platform and make informed decisions), and relatedness (ability to join the community, feel supported and valued).

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

[ SDS Key Results ]

Обговорення

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

[ PES Key Results ]

Обговорення

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

[ FA Key Results ]

Обговорення

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

Плануємо разом

Оновлення від січня 2025.

Portrait of Selena

У річному плані Фонд Вікімедіа описує те, чого ми сподіваємося досягти у прийдешньому році. Ми наполегливо працюємо над тим, щоб зробити план відкритим для участі, амбітним і досяжним. Щороку під час формування плану ми просимо дописувачів ділитися своїми поглядами, сподіваннями та конкретними побажаннями. Деякими зі способів, якими ми намагаємося отримати таку інформацію, є спілкування команди розробників зі спільнотами, Список побажань спільноти, обговорення у спільнотах, такі як низка обговорень на Вікісховищі, на конференціях та вікі-сторінках, таких як ця.

Для нашого наступного річного плану, на період від липня 2025 по червень 2026 року, ми міркуємо про те, як ми можемо найкраще служити баченню на багато поколінь, враховуючи швидкі зміни у світі та інтернеті, а також їх вплив на нашу місію вільних знань.

Як я вже казала минулого року, нам потрібно зосередитися на тому, що нас відрізняє: на нашій здатності надавати достовірний вміст, навіть в умовах поширення дезінформації та хибної інформації в інтернеті та на платформах, що конкурують за увагу нових поколінь. Це включає забезпечення виконання нашої місії зі збору й донесення до світу суми всіх людських знань, розширюючи наше охоплення відсутньої інформації, яке може бути спричинене нерівністю, дискримінацією та упередженістю. Наш вміст також повинен залишатися життєво важливим у мінливому інтернеті, рушійною силою якого є штучний інтелект та інший збагачений досвід. Врешті решт, нам потрібно знайти способи сталого фінансування нашого руху, розробивши спільну стратегію для наших продуктів і збору коштів, щоб ми могли підтримувати цю роботу в довгостроковій перспективі.

Щоб зробити вибір і знайти компроміси щодо того, на чому зосередити наші зусилля в наступному році, ми зібрали разом питання і подумали про те, як розподілити наші обмежені ресурси для досягнення найбільшого впливу.

Якщо вас цікавить, які саме функції або послуги буде створювати Відділ продукту і технології на основі визначених тут пріоритетів, у березні буде час прокоментувати конкретні цілі та ключові результати (для довідки, ось цілі та ключові результати поточного річного плану).

Якщо ви хочете поміркувати про виклики та можливості в нашому технічному середовищі, а також про те, в якому напрямку нам слід рухатися в наступному річному плані, будь ласка, обговоріть з нами наведені нижче питання.

Ми постійно отримуємо інформацію щодо цих питань різними способами — з обговорень у спільноті, з даних, які ми збираємо, із дослідницьких інтерв'ю, які ми проводимо тощо. Ми не вперше ставимо ці запитання і дізнаємося про багато з них — і ми вже працюємо над багатьма з них! Зараз ми хочемо поставити їх знову і продовжувати дізнаватися, оскільки на цьому етапі планування вони є для нас першочерговими.

Запитання:

  • Метрики й дані
    • Яким чином дані та метрики могли б краще підтримувати вашу роботу як редакторів? Чи можете ви пригадати дані про редагування, читання чи організаційну роботу, які допомогли б вам вибрати, як витрачати свій час, або коли саме щось потребує уваги? Це можуть бути дані про вашу власну діяльність або діяльність інших.
  • Редагування
    • Коли редагування приносять вам найбільшу втіху й задоволення? Коли ви відчуваєте найбільші розчарування і труднощі?
    • Ми хочемо, щоб дописувачі отримували більше відгуків і визнання за свою роботу, щоб у них не виникало відчуття, що ніхто не помічає зусиль, які вони докладають до вікі. Які форми відгуків та визнання мотивують вас? Що підштовхує вас до продовження редагування?
    • Оскільки вікі дуже великі, редакторам може бути важко вирішити, яка робота у вікі є найбільш важливою для них, щоб щоденно витрачати на неї свій час. Яка інформація чи інструменти могли б допомогти вам вибрати, як витрачати свій час? Чи було б корисно мати центральне, персоналізоване місце, яке дозволяло б знаходити нові можливості, керувати своїми завданнями й розуміти свій вплив?
    • Ми хочемо покращити зручність співпраці у вікі, щоб дописувачам було легше знаходити один одного і працювати над проєктами разом, чи то через вирішення накопичених поточних завдань, місячники редагувань, Вікіпроєкти, чи навіть спільне редагування удвох. Як, на Вашу думку, ми могли б допомогти більшій кількості дописувачів знаходити один одного, налагоджувати зв'язки та працювати разом?
  • Читання/навчання
    • Вікі завантажуються швидше чи повільніше залежно від того, де люди живуть. Чи є якісь частини світу, де, на вашу думку, покращення продуктивності є найнеобхіднішим?
    • Як ми можемо допомогти новим поколінням читачів захопитися та зацікавитися вмістом Вікіпедії? В минулому ми вже обговорювали ідеї щодо інтерактивного вмісту та відео, а цього року зосередилися на діаграмах та експериментах з новими способами висвітлення наявного вмісту Вікіпедії. Як ми можемо розвивати цей напрям, щоб використовувати наш наявний вміст новими, унікальними для Вікімедіа способами?
  • Модератори
    • Що потрібно змінити у Вікіпедії, щоб більше людей захотіли долучатися до просунутих волонтерських ролей, таких як патрульні чи адміністратори?
    • Яка інформація чи контекст про редагування або про користувачів може допомогти вам швидше або легше приймати рішення з патрулювання чи адміністрування?
  • Зовнішні тенденції
    • Які найважливіші зміни ви помічаєте у світі поза межами Вікімедіа? Це можуть бути тенденції в технологіях, освіті чи тому, як люди навчаються.
    • У яких інших онлайн-спільнотах, окрім руху Вікімедіа, ви берете участь? Які уроки ми можемо винести з інструментів і процесів на інших платформах спільнот?
    • Як ви використовуєте у своїй роботі у Вікімедіа та поза нею інструменти штучного інтелекту? У чому ШІ може бути корисним?
  • Вікісховище
    • Які рішення ми можемо прийняти разом зі спільнотою Вікісховища для стійкого розвитку проєкта, який підтримує створення енциклопедичних знань?
  • Вікідані
    • Яким би ви хотіли бачити розвиток Вікіданих у майбутньому? Яким чином Вікідані можуть бути найкориснішими для створення достовірного енциклопедичного вмісту?

–– Selena Deckelmann

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Wikimedia_Foundation_Annual_Plan/2025-2026/Product_%26_Technology_OKRs/uk&oldid=30518744"