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

Фонд Вікімедіа
Річний план 2025-2026

Річний план Фонду Вікімедіа на 2025-2026 роки

• Стисло
• Глобальні тенденції
• Прогрес
• Цілі
  • Інфраструктура
  • Підтримка волонтерів
  • Ефективність
• Фінансова модель
• Огляд бюджету
• Співпраця

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вікідосвід (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. Надання внескові значущості, показуючи волонтерам їхній вплив та інвестуючи у розвиток міжособистісних зв'язків і створюючи середовище, засноване на позитивному зворотному зв'язку.
  • Проєкт стратегії вимірювання потім склав розгалужену мережу показників для відстеження цієї теорії змін. Зроблений висновок, що основним показником успіху («ключовою метрикою») має бути кількість утриманих редакторів, доповнена вужчими індикаторними метриками, такими як конструктивна активація та намір учасників повернутися, а також ширшими «подальшими» показниками, такими як активні редактори та якісний вміст. Ми повинні забезпечити, щоб ці метрики були введені в дію та відображалися на інформаційній панелі, щоб ми могли відстежувати наш прогрес у реалізації цієї стратегії.

---

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

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

---

Безпека і захищеність (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ФА, пропонуючи користувачам більше можливостей для захисту своїх облікових записів та уникнення випадкового блокування.

---

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

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

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

• • • Ключовий результат WE5.2: До кінця 4 кварталу 70% кінцевих точок мережевих API Вікімедіа будуть підтримуватися спільною інфраструктурою.
      • Ми прагнемо покращити досвід і стабільність наших шляхів для розробників, пропонуючи більш узгоджені, стабільні та доступні мережеві API для всіх розробників Вікімедіа. Ми спростимо наші пропозиції API, запровадивши більш централізовану інфраструктуру для основних можливостей API, що дозволить нам мати узгоджені шляхи та управління ними: специфікацій та документації OpenAPI, ідентифікації розробників та контролю доступу, впровадження політики 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, мову програмування, на якій працює Медіавікі та пов'язані з нею сервіси, до більш сучасної версії. Інші виявлені ризики, ймовірно, вимагатимуть впровадження додаткових заходів безпеки для захисту і зміцнення нашої інфраструктури.

---

Сервіси сигналів і даних (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: До кінця другого кварталу особи, які приймають рішення, матимуть чітке уявлення про поточний стан аналітики, наданої нашими організаційними метриками. Ми будемо вважати, що досягли успіху, якщо надамо презентацію для засідання Ради, яка міститиме аналіз наших метрик як в екосистемі Вікімедіа, так і в ширших інтернет-тенденціях та викликах на ринку.
      • Інформація, отримана з наших організаційних метрик, використовується для прийняття безлічі рішень у фонді, включаючи рішення про те, як ми створюємо наш продукт, як розподіляємо ресурси інфраструктури та як збираємо кошти. Водночас ландшафт Інтернету еволюціонує, а автоматизований трафік, зокрема, впливає на наші показники. Мета полягає в тому, щоб керівництво Фонду прийшло на засідання Ради в грудні з чітким описом загроз для екосистеми Вікімедіа та можливостей в ній, підкріпленим безсумнівним аналізом внутрішніх метрик та зовнішніх тенденцій. Ми зможемо розповісти цю історію, зібравши аналітику, метрики та дані, які дають нам впевненість щодо:
        • Тенденцій у наших внутрішніх показниках читацької аудиторії (переглядів сторінок)
        • Тенденцій у нашій екосистемі авторів
        • Тенденцій із зовнішніх даних та порівняльних показників конкурентів
        • Аналітики з внутрішніх та зовнішніх досліджень і надійних наукових досліджень

---

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

• Ціль: Менеджери продукту можуть швидко, легко і впевнено оцінювати вплив змін функцій продукту у Вікіпедії. Обговорити
  • Контекст мети: Щоб уможливити і прискорити прийняття рішень, на основі даних, про розробку функцій продукту, менеджери продукту потребують платформи для експериментів, на якій вони можуть визначати функції, вибирати цільові аудиторії користувачів і вимірювати вплив. Прискорення часу від запуску до аналізу є критично важливим, оскільки скорочення часу для дослідження прискорить експерименти і, зрештою, інновації. Ручні завдання та індивідуальні підходи до вимірювання були визначені як бар'єри на шляху до швидкості. Ідеальний сценарій полягає в тому, що менеджери продуктів можуть пройти шлях від запуску експерименту до виявлення результатів з мінімальним ручним втручанням інженерів та аналітиків або взагалі без нього.
  • У наступному фінансовому році ми зосередилися на Вікіпедії, тому що саме там команда Ключового досвіду зацікавлена в експериментах (організаційна стратегія передбачає, що ми подвоюємо зусилля у Вікіпедії), а також тому, що це дозволяє нам сфокусуватися і чіткіше сигналізувати, з якими командами та проєктами ми працюємо. Інші команди використовували компоненти експериментальної платформи і можуть продовжувати це робити, але це використання не буде в центрі уваги цієї цілі.
    • Ключовий результат SDS2.1: До кінця другого кварталу забезпечити завершення щонайменше двох повних циклів експериментів з використанням експериментальної платформи.
      • Оскільки організація все більше наголошує на прийнятті рішень щодо продукту на основі даних, ми повинні зробити експерименти доступними для всіх команд продукту, а не тільки для тих, хто має спеціальні навички. Команди продукту потребують спільних стандартів, інструментів та інфраструктури, які дозволяють їм:
        • Швидко тестувати ідеї серед наших користувачів по всьому світу
        • Вимірювати вплив змін у продукті за допомогою стандартизованих метрик
        • Прозоро ділитися результатами з зацікавленими сторонами нашого Руху
      • Чому ми переходимо від зосередження на кількості «задіяних команд» до «завершених експериментів»
      1. Стратегічна узгодженість: це основна метрика успіху платформи
      2. Підхід на основі даних: наше дослідження користувачів (у процесі) показує, що готовність команд в організації є різною, тоді як веб-команда підтвердила зацікавленість у двох конкретних експериментах.
      3. Оптимізація ресурсів: розгортання нашої платформи, як мінімально життєздатного продукту (MVP), вимагатиме інтенсивного навчання, тому в найближчій перспективі ефективніше буде зосередитися на можливостях для експериментів, а не розкидати сили на кілька команд. Ми плануємо просуватися до загального випуску і не хочемо знову інвестувати в навчання команд, якщо цього можна уникнути.
      4. Орієнтованість на майбутнє: відгуки про завершені цикли експериментів будуть більш ефективними для вдосконалення нашої платформи, ніж висновки з часткового або неповного впровадження. У міру просування до загального випуску, зосередження уваги на завершенні експериментів дозволяє уникнути інвестицій у тимчасові підходи, які потрібно буде переробляти.
      • Ми проводимо дослідження користувачів, щоб визначити потреби та вимоги різних команд: опитування та інтерв'ю заплановані на другу половину травня 2025 року, щоб уточнити потреби команди продукту. Після завершення дослідження ми складемо календар експериментів, який можна буде використовувати для встановлення наступних цілей КР та визначення пріоритетів.

---

Майбутні аудиторії (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-річчя Вікіпедії.

Гіпотези

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

Перший квартал (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.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 процентних пунктів, а також покаже нам, чи динамічні підходи до вмісту покращують привабливість бренду.

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

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

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

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

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

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

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

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

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

Запитання:

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

Обговорення

–– Selena Deckelmann