Річний план Фонду Вікімедіа/2024-2025/ЦКР Продукту і технології
Цей документ представляє першу частину процесу планування на 2024-25 роки для відділів Продукту і Технології Фонду Вікімедіа. Він описує «цілі та ключові результати» (ЦКР) цих відділів. Це є продовженням структури робочих портфелів (названих «кошиками»), яка була започаткована минулого року.
.jpg)
У листопаді я говорила з вами про те, що, на мою думку, є найнагальнішим питанням, яке стоїть перед рухом Вікімедіа: як ми можемо зробити так, щоб Вікіпедія та всі проєкти Вікімедіа були доступними для багатьох поколінь? Я хотіла б подякувати всім, хто знайшов час, щоб по-справжньому поміркувати над цим питанням і відповісти мені безпосередньо, і тепер, коли я мала нагоду поміркувати над вашими відповідями, поділюся тим, про що я дізналася.
По-перше, не існує єдиної причини, чому волонтери роблять свій внесок. Для того, щоб виховати кілька поколінь волонтерів, ми повинні краще розуміти багато причин, чому люди присвячують свій час нашим проєктам. Далі, ми повинні зосередитися на тому, що відрізняє нас від інших: на нашій здатності надавати вартий довіри контент в умовах поширення дезінформації та мізінформації в інтернеті та на платформах, які змагаються за увагу нових поколінь. Це містить у собі забезпечення виконання нашої місії зібрати й донести до світу суму всіх людських знань, розширюючи наше охоплення відсутньої інформації, яка може бути спричинена нерівністю, дискримінацією або упередженістю. Наш контент також повинен служити й залишатися життєво важливим у мінливому інтернеті, керованому штучним інтелектом і багатим досвідом. Нарешті, нам потрібно знайти шляхи сталого фінансування нашого руху, розробивши спільну стратегію для наших продуктів і доходів, щоб ми могли фінансувати цю роботу в довгостроковій перспективі.
Ці ідеї будуть відображені у річному плані Фонду Вікімедіа на 2024–2025 роки, першою частиною якого я ділюся з вами сьогодні у вигляді проєкту цілей для нашої роботи над продуктом і технологією. Як і минулого року, весь наш річний план буде зосереджений на технологічних потребах наших аудиторій і платформ, і ми хотіли б отримати від вас зворотний зв'язок, щоб знати, чи ми зосереджуємося на правильних проблемах. Ці цілі ґрунтуються на ідеях, які ми отримували від членів спільноти протягом останніх кількох місяців через Розмови:2024, списки розсилки та сторінки обговорення, а також на заходах спільноти щодо нашої продуктової та технологічної стратегії на наступний рік. Ви можете переглянути повний список проєктів цілей нижче.
«Ціль» — це напрямок високого рівня, який визначатиме продуктові та технологічні проєкти на наступний фінансовий рік, за які ми візьмемося. Вони навмисно широкі, представляють напрямок нашої стратегії і, що важливо, показують, які виклики ми пропонуємо визначити пріоритетними серед багатьох можливих сфер діяльності на наступний рік. Ми ділимося цим зараз, щоб члени спільноти могли допомогти сформувати наше мислення на ранній стадії, ще до того, як будуть затверджені бюджети та вимірні цілі на рік.
Зворотний зв'язок
Однією зі сфер, в якій ми особливо хотіли б отримати зворотний зв'язок, є наша робота, що згрупована під назвою «Вікідосвід». «Вікідосвід» стосується того, як ми ефективно надаємо, покращуємо та інноваційно вдосконалюємо те, як люди безпосередньо користуються вікі, як дописувачі, так і користувачі (споживачі вмісту) чи донори. Це передбачає роботу над підтримкою наших основних технологій і можливостей, а також над покращенням досвіду редакторів-волонтерів — зокрема, редакторів з розширеними правами — за допомогою кращих функцій та інструментів, послуг перекладу та оновлення платформи.
Ось деякі думки з наших нещодавніх обговорень стосовно планування, а також кілька запитань до всіх вас, щоб допомогти нам покращити наші ідеї:
- Волонтерство у проєктах Вікімедіа має приносити задоволення. Ми також вважаємо, що досвід співпраці онлайн має бути основною частиною того, що змушує волонтерів повертатися. Що потрібно для того, щоб редагування приносило волонтерам задоволення і щоб вони краще працювали разом над створенням вартого довіри вмісту?
- Надійність нашого вмісту — це частина унікального внеску Вікімедіа у світ і те, що змушує людей приходити на нашу платформу і користуватися нашим вмістом. Що ми можемо створити, щоб допомогти зростанню вартого довіри вмісту швидше, але все ще в межах стандартів якості, встановлених спільнотами в кожному проєкті?
- Щоб залишатися актуальною і конкурувати з іншими великими онлайн-платформами, Вікімедіа потребує нового покоління користувачів, які б відчували зв'язок з нашим вмістом. Як ми можемо зробити так, щоб наш вміст було легше знаходити та взаємодіяти з ним читачам і донорам?
- В епоху, коли процвітає зловживання в інтернеті, ми повинні переконатися, що наші спільноти, платформа і система обслуговування захищені. Ми також стикаємося з такими, що еволюціонують, зобов'язаннями щодо дотримання відповідності законодавству, коли глобальні політики прагнуть формувати конфіденційність, ідентичність та обмін інформацією в Інтернеті. Які покращання наших можливостей боротьби зі зловживаннями допоможуть нам подолати ці проблеми?
- МедіаВікі, програмна платформа та інтерфейси, які дозволяють Вікіпедії функціонувати, потребує протягом наступного десятиліття постійної підтримки, щоб забезпечити створення, модерацію, зберігання, пошук і споживання відкритого багатомовного вмісту в широких масштабах. Які рішення та вдосконалення платформи ми можемо зробити цього року, щоб забезпечити стабільність МедіаВікі?
Цілі
На цей момент опубліковано найвищий рівень планування — «Цілі».
Наступний рівень — «Ключові результати» (КР) для кожної фіналізованої цілі подається нижче.
«Гіпотези» для кожного КР також опубліковані нижче і будуть оновлюватися на вікісторінках відповідного проєкту/команди впродовж року, щоб оновлюватися в міру засвоєння уроків.
| Цілі для Вікідосвіду (WE) | ||||
|---|---|---|---|---|
| Ціль | Область цілі | Ціль | Контекст цілі | Власник |
| WE1 | Досвід дописувачів | Як досвідчені, так і нові дописувачі об'єднуються онлайн, щоб створювати варту довіри енциклопедію, з більшою легкістю і меншим незадоволенням. | Для того, щоб Вікіпедія залишалася динамічною в наступні роки, ми повинні робити роботу, яка б живила кілька поколінь волонтерів і робила дописування чимось таким, що люди хотіли б робити. Різні покоління волонтерів потребують різних інвестицій — більш досвідчені дописувачі потребують, щоб їхні потужні робочі процеси буди оптимізованими і справними, тоді як нові дописувачі потребують нових способів редагування, які мають сенс для них. І для цих поколінь всі дописувачі повинні мати можливість зв'язуватися і співпрацювати один з одним, щоб робити свою роботу найбільш ефективно. З цією метою ми будемо робити покращення критичних робочих процесів для досвідчених дописувачів, знижувати бар'єри для конструктивних внесків новачками і інвестуватимемо в те, щоб волонтери могли знаходити один одного і спілкуватися за спільними інтересами. | Marshall Miller |
| WE2 | Енциклопедичний вміст | Спільноти отримують підтримку для ефективного заповнення прогалин у знаннях за допомогою інструментів і систем підтримки, які легше отримати, адаптувати та вдосконалювати, забезпечуючи збільшення достовірного енциклопедичного вмісту. | Енциклопедичний вміст, насамперед у Вікіпедії, може бути збільшений і покращений завдяки постійній участі та інноваціям. Інструменти та ресурси (як технічні, так і нетехнічні), які доступні для використання дописувачами для своїх потреб, можна зробити більш явними та надійними. Ці інструменти повинні краще підтримуватися ФВМ через поліпшення їхніх функцій, що може бути досягнуто за короткі цикли. Зважаючи на останні тенденції щодо створення вмісту за допомогою штучного інтелекту та зміни поведінки користувачів, ми також дослідимо підґрунтя для суттєвих змін (наприклад, Вікіфункції), які можуть сприяти масштабному зростанню створення та повторного використання вмісту. Механізми виявлення прогалин у вмісті мають бути простішими для виявлення та планування. Ресурси, які підтримують зростання енциклопедичного вмісту, включно з вмістом у сестринських проєктах, таких як Бібліотека Вікіпедії, та кампаніях, можуть бути краще інтегровані з робочими процесами дописування. Водночас методи, що використовуються для зростання, повинні проти зростаючих загроз мати запобіжники, які можуть забезпечити постійну довіру до процесу, залишаючись вірними основним принципам енциклопедичного вмісту, визнаним у всіх проєктах Вікімедіа.
Аудиторія: редактори, перекладачі |
Runa Bhattacharjee |
| WE3 | Досвід споживачів (читання та медіа) | До Вікіпедії приходить нове покоління споживачів, щоб знайти найкраще місце для відкриття, залученості та побудови тривалого зв'язку з енциклопедичним вмістом. | Цілі:
Утримати існуючі та нові покоління споживачів і донорів. Підвищити актуальність для існуючих і нових поколінь споживачів, зробивши наш вміст простішим для пошуку та взаємодії. Працювати на різних платформах для адаптації нашого досвіду та існуючого вмісту, щоб енциклопедичний вміст міг досліджуватися та куруватися новим поколінням споживачів та донорів. |
Olga Vasileva |
| WE4 | Довіра і безпека | Покращувати нашу інфраструктуру, інструменти та процеси, щоб ми були добре оснащені для захисту спільнот, платформи та наших сервісних систем від різних видів масштабних і цілеспрямованих зловживань, зберігаючи при цьому відповідність регуляторному середовищу, що постійно змінюється. | Деякі аспекти наших можливостей боротьби зі зловживаннями потребують вдосконалення. Протидія зловживанням на основі IP-адрес стає все менш ефективною, деякі інструменти адміністрування потребують підвищення ефективності, і нам потрібно розробити єдину стратегію, яка допоможе нам боротися з масштабними зловживаннями, використовуючи в узгодженому поєднанні різні сигнали та механізми протидії (капчі, блокування тощо). Цього року ми почнемо працювати над розв'язанням найбільших проблем у цій сфері. Крім того, ці інвестиції в захист від зловживань повинні бути збалансовані з інвестиціями в розуміння і поліпшення стану спільноти, деякі аспекти якого включені в різні регуляторні вимоги | Suman Cherukuwada |
| WE5 | Платформа знань I (Еволюція платформи) | Розвивати платформу МедіаВікі та її інтерфейси, щоб краще відповідати основним потребам Вікіпедії. | МедіаВікі побудована для створення, модерації, зберігання, знаходження та споживання відкритого багатомовного вмісту в широких масштабах. У цей другий рік роботи Платформи знань ми подивимося на систему як куратор і почнемо працювати над вдосконаленням платформи, щоб ефективно підтримувати основні потреби проєктів Вікімедіа протягом наступного десятиліття, починаючи з Вікіпедії. Це включає продовження роботи над визначенням нашої платформи виробництва знань, посилення стійкості платформи, фокус на системі розширень/куків, щоб прояснити і впорядкувати розробку функцій, а також продовження інвестування в обмін знаннями і надання людям можливості робити внесок у МедіаВікі. | Birgit Müller |
| WE6 | Платформа знань II (Сервіси для розробників) | Технічний персонал і розробники-волонтери мають інструменти, необхідні для ефективної підтримки проєктів Вікімедіа. | Ми продовжимо розпочату роботу над покращенням (і масштабуванням) робочих процесів розробки, тестування та розгортання у Вікімедіа продакшн і розширимо визначення, включивши до нього послуги для розробників інструментів. Ми також прагнемо покращити нашу здатність відповідати на поширені запитання щодо робочих процесів та аудиторій розробників/інженерів, а також зробити відповідні дані доступними для прийняття поінформованих рішень. Частиною цієї роботи є розгляд практик (або їх відсутності), які наразі становлять виклик для нашої екосистеми. | Birgit Müller |
| Цілі для Сервісів сигналів і даних (ССД) | ||||
|---|---|---|---|---|
| Ціль | Область цілі | Ціль | Контекст цілі | Власник |
| SDS1 | Спільні погляди | Наші рішення про те, як підтримувати місію та рух Вікімедіа, ґрунтуються на метриках високого рівня та нових ідеях. | Для того, щоб ми могли ефективно та результативно розвивати технології, підтримувати волонтерів та відстоювати політику, яка захищає та розширює доступ до знань, нам потрібно розуміти екосистему Вікімедіа та узгоджувати свої погляди на те, як виглядає успіх. Це означає своєчасне відстеження загального набору показників, які є надійними, зрозумілими та доступними. Це також означає появу досліджень та ідей, які допоможуть нам зрозуміти, чому і як ми вимірюємо. | Kate Zimmerman |
| SDS2 | Платформа для експериментів | Менеджери продуктів можуть швидко, легко і впевнено оцінювати вплив функцій продукту. | Щоб уможливити та прискорити прийняття рішень про розробку функцій продукту на основі даних, менеджерам продуктів потрібна платформа для експериментів, за допомогою якої вони можуть визначати функції, обирати цільові аудиторії користувачів та бачити результати вимірювань впливу. Прискорення часу між запуском і аналізом є критично важливим, оскільки скорочення часу для навчання прискорить експерименти і, врешті решт, інновації. Ручні завдання та індивідуальні підходи до вимірювання були визначені як бар'єри на шляху до швидкості. Ідеальний сценарій полягає в тому, що менеджери продуктів можуть пройти шлях від запуску експерименту до виявлення результату з мінімальним ручним втручанням інженерів та аналітиків або взагалі без нього. | Tajh Taylor |
| Ціль Майбутніх аудиторій (FA) | ||||
|---|---|---|---|---|
| Ціль | Область цілі | Ціль | Контекст цілі | Власник |
| FA1 | Перевірка гіпотез | Надати рекомендації щодо стратегічних інвестицій для Фонду Вікімедіа — на основі результатів експериментів, які поглиблюють наше розуміння того, як знання поширюються і споживаються в онлайні, — які допоможуть нашому руху служити новим аудиторіям в умовах мінливого Інтернету. | Через постійні зміни в технологіях і поведінці користувачів в онлайні (наприклад, зростаюча перевага отримання інформації через соціальні додатки, популярність короткометражних відеороликів, розвиток генеративного штучного інтелекту) рух Вікімедіа стикається з проблемами залучення й утримання читачів і дописувачів. Ці зміни також приносять можливості служити новим аудиторіям, створюючи й доставляючи інформацію новими способами. Однак ми, як рух, не маємо чіткої, заснованої на даних картини переваг і компромісів різних потенційних стратегій, які ми могли б застосувати для подолання викликів або використання нових можливостей. Наприклад, чи варто нам ...
Щоб Вікімедіа стала проєктом для багатьох поколінь, ми перевіримо гіпотези, щоб краще зрозуміти і порекомендувати перспективні стратегії — для Фонду Вікімедіа та руху Вікімедіа, — яких слід дотримуватися, щоб залучати й утримувати майбутні аудиторії. |
Maryana Pinchuk |
| Ціль для Продуктової та інженерної підтримки (ПІП) | ||||
|---|---|---|---|---|
| Ціль | Область цілі | Ціль | Контекст цілі | Власник |
| PES1 | Ефективність операцій | Зробити роботу Фонду швидшою, дешевшою та більш впливовою. | Працівники Фонду у своїй повсякденній роботі роблять багато для того, щоб наша діяльність була швидшою, дешевшою та більш впливовою. Ця ціль висвітлює конкретні ініціативи, які: а) дозволять досягти значних успіхів у напрямку підвищення швидкості, дешевизни та результативності; б) приведуть до скоординованих зусиль та зміни формальних і неформальних практик у Фонді. По суті, КР, включені до цієї цілі, є найскладнішими та найкращими поліпшеннями, які ми можемо зробити цього року для підвищення операційної ефективності роботи, що стосується наших продуктів і технології. | Amanda Bittaker |
Ключові результати
Тут для кожної фіналізованої цілі приведені «Ключові результати» (КР). Вони відповідають кожній з цілей, наведених вище.
«Гіпотези», щодо уточнюють кожне з планованих досягнень, у міру накопичення досвіду, будуть публікуватись нижче на цій сторінці та оновлюватися на вікісторінках відповідного проєкту або команди.
| Ключових результати Вікідосвіду (ВД)
[ Цілі ] | |||
|---|---|---|---|
| Скорочення ключового результату | Текст ключового результату | Контекст ключового результату | Власник |
| WE1.1 | Розробити або вдосконалити один робочий процес, який допомагає дописувачам зі спільними інтересами зв'язуватися один з одним і робити спільні внески. | Ми вважаємо, що простори спільнот і взаємодія у вікі роблять людей задоволенішими і, як дописувачів, продуктивнішими. Крім того, простори спільнот допомагають залучати і наставляти новачків, моделюють найкращі практики дописувачів і допомагають заповнювати прогалини в знаннях. Однак існуючі ресурси, інструменти та простори, які підтримують людський зв'язок у вікі, є неякісними і сьогодні не відповідають викликам і потребам більшості редакторів. Тим часом робота команди Кампаній продемонструвала, що багато організаторів прагнуть впроваджувати та експериментувати з новими інструментами зі структурованими робочими процесами, які допомагають їм у роботі зі спільнотою. З цих причин ми хочемо зосередитися на заохоченні та просуванні почуття приналежності серед дописувачів вікі. | Ilana Fried |
| WE1.2 | Конструктивна активізація: Широке застосування дій, які в підсумку покажуть зростання відсотка новачків порівняно з попереднім роком, які опублікували ≥1 конструктивне редагування на 25% в основному просторі та на 10% на мобільних пристроях, згідно з показниками контрольних експериментів.
Примітка: цей КР буде вимірюватись по кожній з платформ. |
Поточний досвід повноекранного редагування для багатьох новачків, щоб робити конструктивний внесок, вимагає занадто багато контексту, терпіння та спроб і помилок. Щоб підтримати нове покоління волонтерів, ми збільшимо кількість і доступність менших, структурованих і більш орієнтованих на конкретні завдання робочих процесів редагування (наприклад, Перевірка редагування і Структуровані завдання).
Примітка: Базові показники будуть встановлені лише наприкінці 4 кварталу поточного фінансового року, після чого буде встановлено наш цільовий відсотковий показник КР. |
Peter Pelberg |
| WE1.3 | Підвищити задоволення користувачів від кожного з 4-х модераційних інструментів на 5 пунктів. | Редактори з розширеними правами використовують широкий спектр наявних функцій, розширень, інструментів та скриптів для виконання завдань модерації у проєктах Вікімедіа. Цього року ми хочемо зосередитися на вдосконаленні цього інструментарію, а не на проєктах зі створення нової функціональності у цій сфері. Ми плануємо протягом року взятися до низки продуктів і хочемо внести значні вдосконалення до кожного з них. Таким чином ми сподіваємося покращити досвід модерації вмісту в цілому.
Ми визначимо напрямні для поширених інструментів модерування, які будуть охоплені цією програмою, щоб визначити збільшення задоволення від роботи з кожним інструментом. Список побажань спільноти матиме істотний вплив на вибір пріоритетів для цього КР. |
Sam Walton |
| WE1.4 | Впровадити щонайменше 2 заходи для диверсифікації бази користувачів розширення CampaignEvents з метою використання інструментів розширення 3 новими спільнотами або типами діяльності до кінця 2024/25 фінансового року. | Розширення CampaignEvents надає інструменти для керування та просування подій у вікі, щоб люди могли легше спілкуватися та співпрацювати разом. Ми хочемо, щоб більше людей могли використовувати ці інструменти, щоб більше людей також могли організовувати/брати участь у подіях або знаходити нові способи зв'язку з іншими. Для цього ми хочемо узагальнити деякі з наших існуючих інструментів (таких як Реєстрація на події та Список співпраці), щоб їх можна було використовувати по-різному у вікі та налаштовувати відповідно до потреб різних людей. Ми також хочемо випустити розширення для більшої кількості вікі-сайтів, щоб більше людей могли використовувати його інструменти з метою сприяння більшій спільноті та співпраці. | Ilana Fried |
| WE1.5 | Створіть стратегію для взаємодії з учасниками до кінця третього кварталу, включаючи показники та цілі, щоб керувати нашою роботою до 2030 року. | Цей ключовий звіт відображає роботу, яку ми виконуємо для створення довгострокової стратегії для простору волонтерів загалом, включаючи такі команди (станом на січень 2025 року): Редагування, Розвиток, Кампанії та Інструменти модератора. За допомогою нашої стратегії ми прагнемо забезпечити більше ясності для учасників протягом наступних 5 років, щоб стимулювати зростання волонтерів та створити більш змістовний досвід для учасників. | Sonja Perry |
| WE1.6 | 200 користувачів додали до улюблених 5+ шаблонів до кінця четвертого кварталу. | Цей ключовий звіт відображає роботу, яку ми виконуємо для створення довгострокової стратегії для простору волонтерів загалом, включаючи такі команди (станом на січень 2025 року): Редагування, Розвиток, Кампанії та Інструменти модератора. За допомогою нашої стратегії ми прагнемо забезпечити більше ясності для учасників протягом наступних 5 років, щоб стимулювати зростання волонтерів та створити більш змістовний досвід для учасників. | Jack Wheeler |
| WE2.1 | До кінця 2-го кварталу організатори, дописувачі та установи отримають 3 практичні і суттєві підстави для збільшення наповнення в ключових тематичних галузях, як ґендер (жіноче здоров'я, біографії жінок) та географія (біорозмаїття). | Цей КР стосується покращення висвітлення окремих тем, щоб зменшити наявні прогалини у знаннях. Ми встановили, що спільноти отримують користь від ефективних інструментів у поєднанні з кампаніями, спрямованими на підвищення якості вмісту в наших проєктах. Цього року ми хочемо зосередитися на вдосконаленні наявних інструментів та експериментуванні з новими способами вибору пріоритетності ключових тем, щоб подолати прогалини в знаннях. | Purity Waigi & Fiona Romeo |
| WE2.2 | До кінця 2-го кварталу впровадити та протестувати дві рекомендації, як соціальні, так і технічні, для підтримки мовної адаптації малих мовних спільнот, з оцінкою для аналізу відгуків спільноти. | Існують версії Вікіпедії приблизно 300 мовами. І все ж є набагато більше мов, якими розмовляють мільйони людей, якими немає Вікіпедії та взагалі Вікісайтів. Це перешкода на шляху до реалізації нашого бачення: щоб кожна людина могла вільно створювати інформацію і знання, обмінюватися ними і мати доступ до суми всіх знань. Інкубатор Вікімедіа — це місце, де потенційні вікіпроєкти Вікімедіа у нових мовних версіях можуть бути організовані, написані, протестовані й доведені до того, що вони гідні бути розміщеними на ресурсах Фонду Вікімедіа. Інкубатор був започаткований у 2006 році з припущенням, що його користувачі матимуть попередні знання з редагування вікі. Ця проблема загострюється тим, що цей процес здебільшого мають виконувати люди, які є найновішими і найменш досвідченими в нашому русі. Хоча редагування у вікіпроєктах Вікімедіа з того часу значно покращилося, Інкубатор не отримував цих оновлень через технічні обмеження. Наразі випуск вікі з Інкубатора займає кілька тижнів, а щороку створюється лише близько 12 вікі, що свідчить про значне вузьке місце.
Наявні дослідження та матеріали свідчать про технічні проблеми на кожному етапі впровадження мови: додавання нових мов до Інкубатора, складнощі в розробці та перевірці вмісту, а також повільний процес створення вікісайту після того, як мова вийде з Інкубатора. Кожна фаза є повільною, ручною та складною, що вказує на необхідність вдосконалення. Розв'язання цієї проблеми дозволить створювати вікі новими мовами швидше і простіше, а також дасть змогу більшій кількості людей ділитися знаннями. Різні зацікавлені сторони, наявні дослідження та ресурси виявили запропоновані рекомендації як соціального, так і технічного характеру. Цей ключовий результат пропонує протестувати дві рекомендації, як соціальні, так і технічні, та оцінити відгуки спільноти. |
Satdeep Gill & Mary Munyoki |
| WE2.3 | На кінець другого кварталу дві нові функції допомагають дописувачам додавати джерельні матеріали, які відповідають настановам проєкту, а 3-5 партнерів надали джерельні матеріали, які заповнюють мовні та географічні прогалини. | Щоб розширювати доступ до якісних джерельних матеріалів, необхідних для заповнення стратегічних прогалин у вмісті, ми будемо:
|
Fiona Romeo & Alexandra Ugolnikova |
| WE2.4 | До кінця другого кварталу увімкнути виклик Вікіфункцій на test2wiki, щоб забезпечити більш масштабований спосіб додавання нового вмісту. | Щоб ефективно зменшити наші прогалини в знаннях, нам потрібно вдосконалити робочі процеси, які підтримують масштабоване зростання якісного вмісту, особливо в менших мовних спільнотах. | Amy Tsay |
| WE2.5 | До кінця четвертого кварталу сприяти організаторам, учасникам та інституціям задля збільшення охоплення якісного контенту в ключових тематичних галузях, як-от ґендер (жіноче здоров'я, біографії жінок) та географія (біорозмаїття) на 138 статей протягом експерименту. | Як пряме продовження WE2.1, цей КР стосується покращення висвітлення окремих тем, щоб зменшити наявні прогалини у знаннях. Ми встановили, що спільноти отримують користь від ефективних інструментів у поєднанні з кампаніями, спрямованими на підвищення якості вмісту в наших проєктах. Цього року ми хочемо зосередитися на вдосконаленні наявних інструментів та експериментуванні з новими способами вибору пріоритетності ключових тем, щоб подолати прогалини в знаннях. | Purity Waigi & Satdeep Gill |
| WE2.6 | До кінця четвертого кварталу Wikifunctions використовуватиметься щонайменше у 5 проєктах Вікімедіа. | Щоб підтвердити нашу ідею про те, що Wikifunctions може підтримувати масштабоване зростання якісного контенту, нам потрібно розгорнути інтеграцію на більшу кількість вікі-сайтів та повторити, щоб підвищити її цінність для багатомовних спільнот. Ці знання додадуть нам більше впевненості в міру нашого масштабування. | Amy Tsay |
| WE2.7 | До кінця четвертого кварталу одна функція допоможе учасникам додавати вихідні матеріали, що відповідають інструкціям проєкту щодо Commons, а одна спільнота зі стратегічним партнером буде завершена з теми впливу. | Щоб розширити доступ до якісних вихідних матеріалів, необхідних для усунення прогалин у стратегічному контенті, ми:
|
Alexandra Ugolnikova |
| WE3.1 | Створити два куровані, доступні та керовані спільнотою досвіди перегляду та навчання у репрезентативних вікі з метою збільшення на 5% утримання читачів, що вийшли з системи, серед користувачів, які отримали досвід. | Цей КР фокусується на збільшенні утримання нового покоління читачів на нашому сайті, дозволяючи новому поколінню побудувати тривалий зв'язок з Вікіпедією, досліджуючи можливості для читачів легше відкривати й вивчати вміст, який їх цікавить. Це включатиме дослідження та розробку нових курованих, персоналізованих і керованих спільнотою можливостей для перегляду та навчання (наприклад, стрічки з відповідним вмістом, рекомендації та пропозиції щодо тематичного вмісту, можливості для вивчення вмісту, куровані спільнотою тощо).
Ми плануємо розпочати фінансовий рік із серії експериментів з досвіду перегляду вебсторінок, щоб визначити, які з них ми хотіли б масштабувати для робочого використання і на якій платформі (веб, застосунки, або і те й інше). Потім ми зосередимося на масштабуванні цих експериментів і перевірці їхньої ефективності в підвищенні утримання користувачів у робочих середовищах. Наша мета до кінця року - запустити принаймні два експерименти на репрезентативних вікі й точно виміряти 5% збільшення утримання читачів, які беруть участь у цих експериментах. Щоб оптимально ефективно досягти цього КР, нам знадобиться можливість «A/B» тестування з користувачами, які вийшли з системи, а також інструменти, здатні вимірювати утримання читачів. Нам також можуть знадобитися нові API або сервіси, необхідні для представлення рекомендацій та інших механізмів кураторства. |
Olga Vasileva |
| WE3.2 | Збільшити на 50% на кожну платформу кількість пожертв через контактні точки, окрім щорічних банерів та звернень через електронну пошту. | Наша мета — забезпечити різноманітність джерел надходжень, визнаючи при цьому наших наявних донорів. Спираючись на відгуки та дані, ми зосереджуємось на збільшенні кількості пожертв поза межами методів, на які Фонд покладався в минулому, зокрема, щорічних банерних закликів. Ми хочемо показати, що, інвестуючи в більш інтегрований донорський досвід, ми можемо підтримувати нашу роботу і розширювати наш вплив, надаючи альтернативу донорам і потенційним донорам, які не реагують на банерні заклики. 50% — це початкова оцінка, що базується на зменшенні видимості кнопки «Пожертвувати» в Інтернеті внаслідок впровадження Вектора 2022, а також на збільшенні кількості пожертв завдяки пілотному проєкту 2023-2024 фінансового року в застосунках Вікіпедії, спрямованому на покращення досвіду донорів (збільшення кількості пожертв на 50,1%). Оцінка цієї метрики за платформами допоможе нам зрозуміти тенденції на платформах і те, чи слід застосовувати різні тактики в майбутньому, виходячи з різниці в поведінці залежно від аудиторії платформи. | Jazmin Tanner |
| WE3.3 | До кінця другого кварталу 2024-25 волонтери розпочнуть конвертувати старі графіки в нові графічні розширення при створенні статей Вікіпедії. | Графічні розширення було відключено з міркувань безпеки з квітня 2023 року, і читачі не змогли побачити багатьох діаграм, у які члени спільноти вклали час і енергію протягом останніх 10 років.
Візуалізація даних відіграє важливу роль у створенні привабливого енциклопедичного контенту, тому в 2024-25 фінансовому році ми побудуємо нову безпечну послугу, яка замінить розширення Graph, і яка буде обробляти більшість простих випадків візуалізації даних у статтях Вікіпедії. Цей новий інструмент передбачатиме можливість розширеного варіанту для підтримки більш складних випадків використання, якщо ФВМ або розробники спільноти вирішать це зробити в майбутньому. Ми дізнаємося, що досягли успіху, коли члени спільноти успішно конвертують старі графіки і опублікують нові графіки за допомогою нового інструменту. Ми визначимо, яку бібліотеку візуалізації вихідних даних використовувати і які типи графіків підтримувати на початковому етапі проєкту. |
Christopher Ciufo |
| WE3.4 | Розробити модель можливостей для поліпшення продуктивності вебсайту за допомогою розміщення кешу сайтів у меншому масштабі, що займе один місяць для реалізації, зберігаючи технічні можливості, безпеку та приватність. |
Команда трафіку відповідає за підтримання мережі надання контенту (МНК). Цей шар зберігає часто доступний контент, сторінки і т.ін. в пам'яті і на диску. Це зменшує час, потрібний для обробки запитів користувачів. Другий частина - це зберігання контенту ближче до користувача в фізичному сенсі. Це зменшує час, необхідний, щоб дані досягли користувача (запізнення). Минулого року ми включили один сайт в Бразилії, який мав на меті скоротити затримку в Південноамериканському регіоні. Було б чудово постворювати нові центри обробки даних, але це дорого в грошах, у часі і в кількості роботи - наприклад, минулорічна робота тривала цілий рік. Ми хотіли б мати центри в Африці та Південно-Східній Азії, і було б чудово мати їх по всьому світу. Наша гіпотеза полягає в тому, щоб розгорнути невеликі центри в інших місцях по всьому світу, де є менший трафік. Для цього потрібно було б менше серверів, не більше чотирьох або п'яти. Це знижує наші витрати. Це все ще допоможе нам зменшити затримку для користувачів у цих регіонах, але буде меншим за часом і зусиллями на їх підтримку. |
Kwaku Ofori |
| WE3.5 | До кінця четвертого кварталу 2024-25 років зацікавлені волонтери з будь-якої Вікіпедії зможуть створювати діаграми, а робоча група успішно передасть технічне обслуговування групі Reader Experiences. |
Розширення Chart знаходиться в режимі виробництва і введене для обраного списку пілотних вікі (itwiki, svwiki, hewiki). Мета пілоту - заздалегідь виявити помилки і проблеми з використанням, перш ніж розширити масштаби розгортання на більше число вікі. До мандату проєкту входить надання оновленої версії розширення графів на всіх вікі, і треба ще постаратись, щоб це зробити можливим. Ця робоча група також є тимчасовою, тобто обслуговування та будь-яка майбутня розробка функцій мають бути передані після завершення проекту. |
Chris Ciufo |
| WE4.1 | До кінця четвертого кварталу надати пропозицію щодо трьох контрзаходів проти переслідувань і шкідливого вмісту на основі даних і відповідно до змін у регуляторному середовищі, що розвивається. | Забезпечення безпеки та гаразду користувачів є основним обов'язком онлайн-платформ. У багатьох юрисдикціях діють закони та нормативні акти, які вимагають від онлайн-платформ вживати заходів проти домагань, кібербулінгу та іншого шкідливого вмісту. Невиконання цих вимог може призвести до юридичної відповідальності платформи та регуляторних санкцій.
Наразі ми не дуже добре уявляємо собі, наскільки великими є ці проблеми або причини, що їх породжують. Ми значною мірою покладаємося на окремі свідчення та ручні процеси, що залишає нас вразливими як до юридичних ризиків, так і до інших далекосяжних наслідків: недооцінки проблеми, ескалації шкоди, репутаційних збитків та підриву довіри користувачів. Нам потрібно створити сильну культуру вимірювання частоти випадків домагань і шкідливого вмісту та проактивно впроваджувати контрзаходи. |
Madalina Ana |
| WE4.2 | Розробити щонайменше два сигнали для використання в робочих процесах боротьби зі зловживаннями, щоб підвищити точність дій щодо зловмисників до кінця четвертого кварталу. | Вікі значною мірою покладаються на блокування IP-адрес як на механізм блокування вандалізму, спаму та зловживань. Але IP-адреси стають все менш корисними як стабільні ідентифікатори окремих учасників, а блокування IP-адрес має непередбачувані негативні наслідки для добросовісних користувачів, які випадково мають одну IP-адресу зі зловмисниками. Поєднання зниження стабільності IP-адрес і нашої значної залежності від блокування IP-адрес призводить до зниження точності та ефективності націлювання на зловмисників, а також до зростання рівня супутньої шкоди для добросовісних користувачів. Ми хочемо бачити протилежну ситуацію: зниження рівня супутньої шкоди та підвищення точності заходів, спрямованих на зловмисників.
Щоб краще підтримати роботу функціонерів у боротьбі зі зловживаннями та надати будівельні блоки для повторного використання в наявних (наприклад, CheckUser, Special:Block) і нових інструментах, в цьому КР ми пропонуємо дослідити способи надійно пов'язати особу з її діями (нівелювання використання кількох облікових записів), а також об'єднати наявні сигнали (наприклад, IP-адреси, історію облікових записів, атрибути запитів), щоб забезпечити більш точне націлювання дій на зловмисників. |
Kosta Harlan |
| WE4.3 | Зменшити ефективність великомасштабної розподіленої атаки на 50%, що вимірюється часом, необхідним для адаптації наших заходів, та обсягом трафіку, який ми можемо витримати при симулюванні. | Еволюція ландшафту Інтернету, включаючи зростання масштабних бот-мереж і почастішання атак, зробила наші традиційні методи обмеження масштабних зловживань застарілими. Такі атаки можуть зробити наші сайти недоступними, переповнивши нашу інфраструктуру запитами, або перевантажити здатність нашої спільноти боротися з масштабним вандалізмом. Це також створює невиправдане навантаження на наших редакторів з високими привілеями та технічну спільноту.
Нам терміново потрібно покращити нашу здатність автоматично виявляти, протистояти і нівелювати або зупиняти такі атаки. Для того, щоб виміряти наші покращення, ми не можемо покладатися виключно на частоту/інтенсивність реальних атак, оскільки ми будемо залежати від зовнішніх дій, і нам буде важко отримати чітку кількісну картину нашого прогресу. Налаштувавши кілька симульованих атак різної природи/складності/тривалості, які можна безпечно запустити проти нашої інфраструктури, і запускаючи їх щоквартально, ми зможемо як тестувати наші нові контрзаходи, не бувши атакованими, так і об'єктивно звітувати про наші вдосконалення. |
Giuseppe Lavagetto |
| WE4.4 | Запустити тимчасові облікові записи для 30 вікі. | Тимчасові облікові записи – це рішення для дотримання різних регуляторних вимог щодо розкриття інтелектуальних власності на нашій платформі на різних поверхнях.
Ця робота включає оновлення багатьох продуктів, конвеєрів даних, інструментів для функціонерів та різних робочих процесів для волонтерів, щоб впоратися з існуванням додаткового типу облікового запису. |
Niharika Kohli |
| WE5.1 | До кінця четвертого кварталу завершити щонайменше 5 заходів, спрямованих на підвищення сталості платформи. | Стійкість платформи МедіаВікі — це постійна робота, важлива для нашої здатності масштабувати, підвищувати або уникати погіршення задоволеності розробників і розвивати нашу технічну спільноту. Це важко виміряти і залежить від технічних та соціальних факторів. Однак ми володіємо неявними знаннями про конкретні сфери вдосконалення, які є стратегічно важливими для стійкості. Заплановані втручання можуть допомогти підвищити стійкість і зручність супроводу платформи або уникнути її деградації. Ми плануємо оцінити вплив цієї роботи в четвертому кварталі та надати рекомендації щодо подальшого досягнення цілей стійкості. Приклади заходів зі стійкості: спрощення складних областей коду, які є основними для МедіаВікі, але лише кілька людей знають, як вони працюють; збільшення використання інструментів для аналізу коду, щоб інформувати про якість нашої кодової бази; оптимізація таких процесів, як формування пакетів та випуски версій. | Mateus Santos |
| WE5.2 | Визначити до кінця другого кварталу і завершити до кінця четвертого кварталу одне або кілька втручань для розвитку програмних інтерфейсів екосистеми МедіаВікі, щоб надати можливість відокремленої, простішої і стійкішої розробки функцій. | Основна мета КР 5.2 — покращити та прояснити взаємодію між основною платформою МедіаВікі та її розширеннями, оформленнями та іншими частинами. Ми прагнемо забезпечити функціональні покращення архітектури МедіаВікі, які уможливлять практичну модульність та зручність супроводу, що полегшить розробку розширень, а також розширить можливості для виконання вимог ширшого бачення продукту МедіаВікі. Ця робота також має на меті проінформувати, що має бути (чи не бути) в ядрі, розширеннях чи інтерфейсах між ними. Рік буде розділений на дві фази: 5-місячна фаза досліджень та експериментів, яка дасть інформацію для другої фази, де будуть реалізовані конкретні втручання. | Jonathan Tweed |
| WE5.3 | До кінця другого кварталу завершити одну ініціативу зі збору даних та один експеримент з покращення продуктивності, щоб інформувати про подальші втручання щодо продукту та платформи для використання можливостей, розблокованих завдяки моделюванню сторінки у МедіаВікі як композиції структурованих фрагментів. | Основна мета полягає в тому, щоб дати можливість розробникам і менеджерам продуктів використовувати нові можливості платформи МедіаВікі для задоволення поточних і майбутніх потреб в енциклопедичному вмісті, уможливлюючи нові пропозиції продуктів, які наразі важко реалізувати, а також підвищити продуктивність і стійкість платформи.
Зокрема, на рівні платформи МедіаВікі ми хочемо змінити модель обробки МедіаВікі, яка не розглядає сторінку як монолітну одиницю, а розглядає її як композицію структурованих одиниць вмісту. Парсоїдні перегляди прочитаного, інтеграція Вікіданих та інтеграція Вікіфункцій у вікі — все це неявні кроки до цього. В рамках цього КР ми хочемо більш цілеспрямовано експериментувати з цими новими можливостями і збирати дані для майбутніх втручань на основі цих нових можливостей, щоб гарантувати, що ми зможемо досягти запланованого впливу на інфраструктуру і продукт. |
Subramanya Sastry |
| WE5.4 | Виконати випуск MediaWiki з новим процесом, який синхронізується з оновленнями PHP в четвертому кварталі. | Платформа програмного забезпечення MediaWiki спирається на регулярні оновлення наступної версії PHP, щоб залишатися безпечною і стабільною, що є проблемним моментом у нашому процесі і важливою для модернізації нашої інфраструктури. У той же час ми регулярно випускаємо нові версії програмного забезпечення MediaWiki, від яких, зокрема, залежить translatewiki.net, платформа, яка використовується для перекладу програмних повідомлень для проектів Вікімедіа. Синхронізуючи PHP-оновлення з процесом випуску, ми не залишаємося позаду на давніших версіях PHP. Це покращить обслуговування та безпеку платформи MediaWiki та досвіду розробників. | Mateus Santos |
| WE5.5 | До кінця четвертого кварталу визначити дієву стратегію розвитку нашої пропозиції API-продуктів, щоб краще задовольнити потреби персоналу, волонтерів та повторних користувачів контенту шляхом спрощення процесу розробки завдяки узгодженому досвіду, централізованому доступу та варіантам інтеграції вищої якості. | Головна мета KR 5.5 — визначити та глибоко зрозуміти всі існуючі публічні шляхи розробників для повторного використання контенту та інтеграції платформи, щоб ми могли створити більш оптимізовану та стійку пропозицію. Ми зробимо це шляхом 1) збору додаткових показників, щоб висвітлити поточне використання каналів доступу до даних, 2) проведення одного або кількох експериментів, які спростять шлях розробника Вікімедіа, 3) надання комплексного 6-сторінкового документа зі стратегією API та 4) створення тактичної дорожньої карти додаткових можливостей, що сприятимуть впровадженню підтримуваних каналів споживання даних.
Розуміння того, чому різні групи розробників віддають перевагу певним точкам входу або моделям даних, дозволить нам використовувати наші існуючі важелі впливу як надійне джерело даних високої цінності та, зрештою, спрямовувати подальшу поведінку через наші бажані механізми. Крім того, оптимізуючи наші пропозиції інтеграції та шлях розробника Вікімедіа, ми підвищимо загальну стійкість, зменшивши витрати на обслуговування та складність адаптації розробників, щоб забезпечити багатопоколіннєве майбутнє місії. |
Halley Coplin |
| WE6.1 | Вирішити 5 питань для забезпечення ефективності та прийняття обґрунтованих рішень щодо робочих процесів і послуг розробників та інженерів, а також зробити відповідні дані доступними до кінця четвертого кварталу. | «Це складно» — часта відповідь на питання на кшталт «які сховища використовуються у виробництві Вікімедіа». У цьому КР ми розглянемо деякі з наших «вічнозелених» питань у сфері інженерної продуктивності та досвіду — повторювані питання, які здаються простими, але на які важко відповісти; питання, на які ми можемо відповісти, але дані недоступні і потребують спеціальних запитів від експертів у певній галузі; питання, на які важко отримати відповідь через прогалини у процесах або з інших причин. Ми визначимо, що означає «вирішити» для кожного з цих питань: для деяких це може означати просто зробити доступними наявні точні дані. Інші питання потребуватимуть більше часу на дослідження та інженерні розробки для їх вирішення. Основна мета цієї роботи — скоротити час, обхідні шляхи і зусилля, необхідні для отримання інформації про ключові аспекти досвіду розробників, і дозволити нам поліпшити робочі процеси і послуги для інженерів і розробників. | [TBD] |
| WE6.2 | До кінця четвертого кварталу вдосконалити теперішній проєкт і провести щонайменше два експерименти, спрямовані на створення зручних у супроводі цільових середовищ, що наближають нас до безпечної, напівбезперервної підтримки функціонування. | Розробники і користувачі покладаються на бета-кластер Вікімедіа (бета), щоб виловлювати помилки до того, як вони вплинуть на користувачів у їхній діяльності. З часом використання бета-версій розширилося і вступило в конфлікт — вони надто різноманітні, щоб вміститися в одному середовищі. Ми покращимо одне з наявних альтернативних середовищ і проведемо експерименти, спрямовані на заміну однієї високопріоритетної потреби в тестуванні, яку наразі задовольняє бета-кластер, на підтримуване альтернативне середовище, яке краще відповідає потребам кожного варіанту використання. | Tyler Cipriani |
| WE6.3 | До 4-го кварталу створити та впровадити систему оцінювання сталого розвитку Toolforge, розроблену для легкого додавання нових категорій та елементів з часом. Застосувати її для покращення принаймні одного критичного аспекту платформи до 4-го кварталу та формування довгострокової стратегії. | Toolforge, ключова платформа для інструментів Вікімедіа, створених волонтерами, відіграє вирішальну роль у всіх сферах, від редагування до захисту від вандалізму. Наша мета — покращити зручність використання Toolforge, знизити бар'єри для внеску, покращити практику спільноти та сприяти дотриманню встановлених правил. З цією метою ми запровадимо систему оцінювання до кінця третього кварталу для оцінки сталості платформи Toolforge, зосереджуючись на технічних та соціальних аспектах. Використовуючи цю систему як орієнтир, ми прагнемо покращити один з ключових технічних факторів на 50%. | Joanna Borun |
| Ключові результати щодо сигнальних служб та збереження даних (SDS)
[ Цілі ] | |||
|---|---|---|---|
| Скорочення ключового результату | Текст ключового результату | Контекст ключового результату | Власник |
| SDS1.1 | До кінця третього кварталу 2 програми або ініціативи, спрямовані на КР, оцінили прямий вплив їхньої роботи на один або кілька основних показників. | Наші основні організаційні показники слугують основою для оцінки прогресу Фонду в досягненні його цілей. Коли ми розподіляємо ресурси на програми та розробляємо робочі потоки, орієнтовані на ключові результати (КР), ці показники високого рівня мають визначати, як ми пов'язуємо ці інвестиції з основними цілями Фонду, визначеними в річному плані.
Робота над цим ключовим результатом підтверджує, що Фонд в цілому перебуває на ранній стадії своєї здатності кількісно пов'язувати вплив усіх запланованих втручань із високорівневими або основними показниками. Для досягнення цієї кінцевої мети цей КР спрямований на розробку процесу, за допомогою якого ми ділимося логічними та теоретичними зв'язками між нашими ініціативами та нашими показниками високого рівня. На практиці це означає співпрацю з власниками ініціатив у всьому Фонді, щоб зрозуміти, як результати їхньої роботи на рівні проєкту пов’язані з нашими основними показниками на рівні Фонду та впливають на них. В даний час Фонд перебуває на ранній стадії своєї мети, щоб бути здатним виконувати програми або інструментальні ініціативи і пов'язувати вплив цих заходів на показники рівня основ Фонду. Для досягнення цієї мети цей КР має на меті зробити наступне: визначити принаймні дві програми-кандидати або ініціативи, спрямовані на продукт, розробити стратегію оцінки щоб виміряти основні метричні наслідки та виконати цю стратегію оцінювання. Починаючи з двох ініціатив, ми швидко зрозуміємо виклики проведення аналізів, які дозволять пов'язати вплив нашої роботи на осяжні зміни в наших основних показниках. Висновки з цього КР будуть втілюватись у більш широку стратегію застосування цієї методики вимірювання до більш широкого кола і кількості ініціатив Фонду. |
Omari Sefu |
| SDS1.2 | Дати відповідь на три стратегічні відкриті дослідницькі питання до грудня 2024 року, щоб надати рекомендації або інформацію для річного планування на 26 фінансовий рік. | В екосистемі Вікімедіа є багато відкритих дослідницьких питань, і відповіді на деякі з них мають стратегічне значення для ФВМ чи афілітатів. Відповіді на ці питання можуть допомогти у майбутньому розвитку продукту чи технології або підтримати прийняття рішень чи адвокацію у політичному просторі. Хоча на деякі з цих питань можна відповісти, використовуючи суто дослідницький або дослідницько-інженерний досвід, з огляду на соціально-технічну природу проєктів Вікімедіа, отримання достовірної інформації часто вимагає міжкомандної співпраці для збору даних, створення вмісту, взаємодії з користувачами, ретельного планування експериментів тощо. За допомогою цього КР ми прагнемо визначити пріоритетність деяких наших ресурсів для відповіді на одне або кілька таких питань.
Робота в рамках цього КР включає визначення пріоритетності списку стратегічних відкритих питань, а також проведення експериментальної роботи для пошуку відповіді на X (наразі оцінюється в 2) з них. Ідеальним типом питань, які ми розглядаємо в цьому КР, є питання, відповідь на які може мати ефект розблокування, дозволяючи багатьом іншим командам або групам працювати (краще? поінформованіше) над продуктом, технологією або політикою. Ми маємо намір, щоб робота в цьому КР доповнювала такі КР:
|
Leila Zia |
| SDS1.3 | Досягти щонайменше 50% скорочення середнього часу, необхідного зацікавленим сторонам у сфері даних для розуміння та відстеження потоків даних для трьох основних та важливих показників. | Необхідно для дотримання стандартів Врядування даними.
Відстеження трансформації та джерел наборів даних є складним і вимагає знання різних сховищ і систем. Ми повинні спростити розуміння того, як потоки даних рухаються в наших системах, щоб зацікавлені у сфері даних сторони могли працювати в режимі самообслуговування. Ця робота підтримуватиме робочі процеси, де дані трансформуються і використовуються для аналітики, функцій, API і завдань з якості даних. Буде продовжена робота над КР щодо документування показників. |
Luke Bowmaker |
| SDS1.4 | До кінця четвертого кварталу три конвеєри даних, що залежать від набору даних історії вікітексту, матимуть щотижневі гарантії доставки (SLO) для джерел вхідних даних історії вікітексту. | Наразі 6 відомих внутрішніх конвеєрів даних покладаються на щомісячні дампи даних Dumps 1. Деякі з них блокуються або спричиняють збої системи нижче за течією, якщо дампи даних Dumps 1 не надаються вчасно. Міграція до нових таблиць забезпечить гарантії доставки, тобто підвищить надійність. Навіть у разі перебоїв у роботі конвеєра на кілька днів можна гарантувати своєчасне щотижневе оновлення.
Ця робота: Покращує надійність доставки даних Скорочує час доставки критично важливих даних, що використовуються для звітності про основні показники, з 1 місяця до 1 дня, що ще більше зменшує вплив короткострокових інцидентів з даними Зменшує ризик щомісячного запуску дампів, що триває більше місяця через зростання обсягу даних та обмеження поточної реалізації Видаляє блокувальник для оновлення PHP 8, яке зрештою ризикує не працювати на останній підтримуваній версії Linux Запобігає розщепленню внутрішніх систем розгортання Mediawiki, оскільки Dumps 1.0 не можна мігрувати на MW на k8s Переводить систему Dumps у стійкий стан, використовуючи встановлені стандартні технології, тим самим знижуючи загальну вартість володіння та усуваючи ізоляцію знань |
Andreas Hoelzl |
| SDS2.1 | До кінця другого кварталу ми зможемо підтримувати одну продуктову команду для оцінки функції або продукту за допомогою базового A/B тестування, що скоротить час на отримання даних про взаємодію з користувачем на 50%. | Ми вважаємо, що використання спільних інструментів підвищить впевненість продуктових команд у прийнятті рішень на основі даних, підвищить ефективність та продуктивність, а також покращить продуктову стратегію та інновації.
Створення UX та технічних систем для зареєстрованих користувачів дозволяє нам рухатися вперед до довгострокової мети підтримки тестів A/B на розлогінених користувачах, поки ведеться робота над реалізацією SDS 2.3. Ми розглянемо прийняття індивідуального часу команди до базових ліній даних взаємодії користувачів і поліпшити його на 50%. Ми також дослідимо, як можна контекстуалізувати ці досягнення в ширшому контексті всіх продуктових команд. Ми сподіваємося дізнатися, як ми можемо покращити сприйняття та визначити пріоритети для покращення можливостей на основі відгуків від команди впровадження та результатів SDS 2.2. |
Virginia Poundstone |
| SDS2.2 | До кінця другого кварталу ми матимемо три основні метрики для аналізу експериментів (A/B-тести) для підтримки перевірки гіпотез щодо продукту/функцій, пов'язаних з КР 2024-2025 фінансового року. | Коли менеджер продукту (або проєктувальник) має гіпотези, що продукт/функція розв'яже проблему/потребу користувачів або організації, то експеримент — це спосіб перевірити ці гіпотези і дізнатися про потенційний вплив їхньої ідеї на показник. Результати експерименту надають інформацію менеджеру продукту і допомагають йому прийняти рішення про те, що робити далі (відмовитися від цієї ідеї і спробувати інші гіпотези, продовжити розробку, якщо експеримент був проведений на початку життєвого циклу розробки, або випустити продукт/функцію для більшої кількості користувачів). Менеджери продукту повинні бути здатними приймати таке рішення з упевненістю, спираючись на докази, яким вони довіряють і які вони розуміють.
Основною перешкодою на цьому шляху є те, що продуктові команди наразі формулюють свої гіпотези за допомогою спеціальних показників для конкретних проєктів, які потребують спеціальної аналітичної підтримки для їх визначення, вимірювання, аналізу та звітування про них. Перехід на набір основних метрик для формулювання всіх гіпотез щодо продукту/функції, які можна перевірити, зробить це:
Ми думаємо, що набір основних метрик, які широко зрозумілі і послідовно використовуються — і які засновані і є під впливом стандартних галузевих метрик — також покращить організаційну грамотність щодо даних і сприятиме культурі оцінювання, експериментування і навчання. Ми зосереджуємося на основних метриках, які: (1) необхідні для найкращого вимірювання та оцінки успіху/впливу продуктів/функцій, пов'язаних з двома ключовими критеріями Вікідосвіду – WE3.1 і WE1.2; (2) відображають або зіставляються зі стандартними галузевими метриками, що використовуються у вебаналітиці. |
Mikhail Popov |
| SDS2.3 | Запровадити унікальний механізм відстеження агентів у нашій CDN, який дозволяє тестування функцій продукту A/B з анонімними читачами. | Без такого механізму відстеження не є розумним проводити тестування A/B характеристик продукту з анонімними читачами.
Це, загалом, результат, що базується на етапі створення нової технічної можливості, на якій інші зможуть побудувати вимірювані речі. Ключовим пріоритетним прикладом використання буде тестування функцій A/B з анонімними читачами, але ця робота також дозволить зробити інші важливі майбутні речі, які можуть створити наступні гіпотези пізніше в WE4.x (для рейтингу ризику запитів і зменшення масштабних атак) та для метрики/дослідження щодо розрахунку унікальних пристроїв, наскільки це дозволять їхнє забезпечення ресурсами і пріоритети. |
Brandon Black |
| SDS2.4 | До кінця четвертого кварталу 2024/25 фінансового року успішно забезпечити проведення одній команді розробників A/B-тестування на анонімних користувачах для функції першого малювання, зберігаючи при цьому дотримання конфіденційності та цілісність даних. | Для централізації роботи ми об'єднаємо невиконану роботу SDS 2.3 KR за 2024-25 фінансові роки в цю нову SDS 2.4 KR. Цей випуск представляє можливості експериментування з анонімними користувачами, зосереджуючись на забезпеченні A/B-тестування для «функцій першого малювання», які відображаються під час завантаження сторінки. Це нова можливість A/B-тестування, яка розкриє нашу здатність покращувати дизайн для анонімних читачів та дізнаватися більше про відмінності та подібності між користувачами, які одночасно вийшли з системи або увійшли в систему. Успіх залежить від завершення розгортання Edge Uniques та передбачає тісну співпрацю між командами Traffic, Experimental Platform Team, Legal, Security, SRE, Product, Data Engineering, Data Platform SRE та Movement Communications. Хоча система матиме відомі обмеження як MVP, вона надає важливі знання про наші спільні компоненти та потреби масштабованості. | Virginia Poundstone |
| Ключові результати Майбутніх цільових груп (МЦГ)
[ Цілі ] | |||
|---|---|---|---|
| Скорочення ключового результату | Текст ключового результату | Контекст ключового результату | Власник |
| FA1.1 | Завдяки експериментальним висновкам та рекомендаціям щодо Майбутніх цільових груп, до кінця третього кварталу у проєкті річного плану на наступний рік буде присутня принаймні одна ціль або ключовий результат, що належить команді, яка не є учасницею Майбутніх цільових груп. | З 2020 року Фонд Вікімедіа відстежує зовнішні тенденції, які можуть вплинути на нашу здатність служити майбутнім поколінням споживачів і дописувачів знань і залишатися квітучим рухом вільних знань для наступних поколінь. Майбутні цільові групи, невелика команда дослідників, будуть:
|
Maryana Pinchuk |
| Ключові результати Продуктової та інженерної підтримки (ПІП)
[ Цілі ] | |||
|---|---|---|---|
| Скорочення ключового результату | Текст ключового результату | Контекст ключового результату | Власник |
| PES1.1 | Культура оцінювання: в рамках щоквартального опитування поступово покращувати оцінки настрою персоналу відділів Продукту і Технології, що стосується наших результатів, напрямків, лідерства та стану команди. | Культура оцінювання — це культура розробки продукту, що базується на коротших циклах ітерацій, навчання та адаптації. Це означає, що наша організація може встановлювати річні цілі, але те, що ми робимо для досягнення цих цілей, буде змінюватися і адаптуватися протягом року в міру того, як ми вчимося. Побудова культури оцінювання має два компоненти: процеси та поведінка. Цей КР фокусується на останній. Зміни в поведінці можуть розвивати і зміцнювати нашу культуру оцінювання. Це передбачає зміни в індивідуальних звичках і традиціях, коли ми переходимо до більш ітеративної розробки продукту. Цей КР базуватиметься на змінах в індивідуальній поведінці згідно з самозвітами, а також на вимірюванні змін у настроях персоналу, якщо такі є. | Amy Tsay |
| PES1.2 | На кінець другого кварталу новий Список побажань краще пов'язує ідеї та запити руху з діяльністю Фонду в сфері Продукту і Технології: пункти зі Списку побажань вирішуються через КР 2024-2025 років, Фонд виконав 10 менших побажань, і Фонд у партнерстві з волонтерами визначив три чи більше областей можливостей на 2025-2026 фінансовий рік. | Список побажань спільноти представляє вузький зріз руху; у ньому беруть участь приблизно 1 тис. людей, більшість з яких є дописувачами або адміністраторами. Люди часто оминають Список побажань, пишучи запити щодо функцій та повідомлення про помилки через Phabricator, де важко відрізнити — чи запити від ФВМ, чи від спільноти. Для учасників Cписок побажань — це дорога інвестиція часу з мінімальними наслідками. Вони все ще беруть участь у Cписку побажань, тому що вважають, що це єдиний спосіб привернути увагу до важливих помилок і поліпшення функцій, або сигналізувати про потребу в ширших, стратегічних можливостях. Побажання часто описують як рішення, а не як проблеми. Рішення можуть здаватися розумними на папері, але не обов'язково враховують технічну складність або наслідки для стратегії руху.
Масштаб і обсяг побажань іноді перевищує повноваження і можливості Технічної спільноти або окремої команди, множачи розчарування, що призводить до запитів на коментар і закликів ліквідувати Список побажань. У той час як члени спільноти вважають за краще використовувати Список побажань для проєктних ідей, команди Фонду дивляться на Список побажань та інші процеси приймання заявок для визначення пріоритетів, частково через те, що побажання не встигають до річного планування і їх важко включити в дорожні карти / Цілі і ключові результати. Майбутній Список побажань має стати мостом між спільнотою та Фондом, де спільноти надаватимуть інформацію в структурованому вигляді, щоб ми могли вжити заходів і, своєю чергою, задовольнити волонтерів. Ми створюємо новий процес приймання заявок, щоб кожен зареєстрований волонтер міг подати побажання будь-якого дня року. Побажання можуть містити повідомлення про помилку, запит на покращення або ідею щодо нової функції. Будь-хто може прокоментувати побажання, взяти участь у семінарі або підтримати його, щоб вплинути на визначення пріоритетів. Фонд не класифікуватиме побажання як «завеликі» або «надто незначні». Побажання, які тематично стосуються ширшої проблемної сфери, можуть впливати на річне планування та дорожні карти команд, пропонуючи стратегічні напрямки та можливості. Побажання будуть видимими для Руху на інформаційній панелі, яка класифікує побажання за проєктами, продуктами/проблемними галузями та типами побажань. Фонд своєчасно реагуватиме на побажання та співпрацюватиме зі Спільнотою, щоб класифікувати та визначити пріоритетність побажань. Ми співпрацюватимемо з вікімедійцями, щоб визначити та встановити як пріоритет три сфери покращення, включені до Річного плану Фонду на 2025-2026 роки, що має покращити рівень прийняття та виконання побажань, що мають вплив. Ми позначатимемо чітко сформульовані побажання для спільноти волонтерів-розробників та команд Фонду, що сприятиме більшій залученості команд та розробників, а також більшій кількості виконаних побажань, що сприятиме задоволенню спільноти. Виконання більшої кількості побажань підвищує задоволеність дописувачів, їхню ефективність та зменшує плинність, що має призвести до якісніших редагувань, якіснішого вмісту та більшої кількості читачів. |
Jack Wheeler |
| PES1.3 | Провести і завершити два експерименти з наявними дослідницькими продуктами/функціями, які нададуть нам дані/інформацію про те, як ми розвиваємо Вікіпедію як джерело знань для нашої поточної аудиторії користувачів і волонтерів у першому і другому кварталах. До кінця третього кварталу завершити та поділитися отриманими знаннями та рекомендаціями для потенційного застосування у майбутній роботі ЦКР у кошику Вікідосвід. | Ця робота є відповідником цілі «Майбутні цільові групи», але натомість зосереджена на виявленні можливостей збільшити та поглибити залучення наших наявних цільових груп (користувачів та дописувачів Вікіпедії) шляхом більш вправного тестування більшої кількості ідей щодо продуктів на платформі.
Він знаходиться в PES1, оскільки є енерджайзером і мультиплікатором — переспрямовує час, який окремі особи й команди вже присвятили хакерству/експериментуванню над побічними проєктами, на те, щоб зосередитися на більш перспективних функціях. Замість того, щоб ці побічні проєкти довго і повільно тягнулися (не найкраще використання наших обмежених ресурсів), цей КР забезпечує шлях для деяких з цих ідей, які потенційно можуть потрапити до більшого середовища APP за допомогою перевірених експериментів, таким чином більш ефективно використовуючи час персоналу і мотивуючи їхню творчість і продуктивність. Беручи в роботу більшу кількість таких менших і коротших проєктів, ми також урізноманітнюємо наші «ставки» для отримання більшої кількості знань та випробування ідей, які можуть трансформувати Вікіпедію відповідно до мінливих потреб та очікувань нашої нинішньої аудиторії. Це зробить нашу роботу ефективнішою та швидшою, оскільки допоможе Фонду зосередитися на правильній меті за менший проміжок часу. |
Rita Ho |
| PES1.4 | Дізнатися, як формулювати, виконувати і контролювати рішення щодо ЦРО (Цілей рівня обслуговування). Вибрати принаймні одну нову річ, для якої, коли ми її випускаємо, потрібно визначити ЦРО. Співпрацювати з відповідною командою/командами (зазвичай: продуктовою, командою розробників, інжинірингу надійності сайту), щоб визначити ці ЦРО. Обміркувати і задокументувати настанови щодо того, які випуски повинні мати ЦРО в майбутньому і як їх встановлювати. | МАЙБУТНІЙ КР:
Налагодити процес та елементарні інструменти для встановлення та моніторингу ЦРО для нових релізів. Звітувати щоквартально і використовувати його, щоб вирішувати, коли варто (і не варто) визначати пріоритетність роботи, щоб щось виправити. Поділиться звітом зі спільнотою. НАВІЩО: Ми не знаємо, коли нам потрібно визначати пріоритетність робіт, щоб щось виправити. І у нас багато коду. Оскільки цей обсяг продовжує зростати, з'являється все більше ситуацій, коли нам слід вирішувати, чи займатись проблемами, чи зосередитися на інноваціях, і все більше невизначеності щодо того, коли ми повинні це робити. Крім того, персоналу і спільноті незрозуміло, який наш рівень підтримки/зобов'язань щодо надійності та продуктивності для всіх різних функцій і можливостей, з якими вони взаємодіють. Якщо ми визначимо очікуваний рівень обслуговування, ми зможемо знати, коли нам слід виділяти на нього ресурси, а коли ні. |
Mark Bergsma |
| PES1.5 | Визначити власність і зобов'язання (включаючи СЛО) щодо послуг і дізнатися, як відстежувати, звітувати і приймати рішення як стандартну та придатну до масштабування практику, випробувавши її у 3 командах серед старших лідерів у відділі. | Після спільного визначення SLO для функції EditCheck в рамках PES1.5 ми тепер спробуємо і навчимося використовувати SLO на практиці для сприяння вибору пріоритетів роботи над стійкістю. Ми також задокументуємо ролі та відповідальність за власність коду/служб, що дозволить нам чітко визначити спільні зобов'язання щодо рівня постійної підтримки. Ми спробуємо використовувати їх як практики у 3 командах по всьому відділу. | Mark Bergsma |
| PES1.6 | Річний план на 2025/26 роки (тобто до кінця четвертого кварталу) включає гіпотези, які НЕ призначені команді CommTech, і які безпосередньо стосуються щонайменше 3 різних напрямків списку бажань. | Оновлений список бажань спільноти робить ставку на нашу здатність впливати на команди розробників продуктів WMF, щоб вони враховували та приймали побажання, щоб команда технічних фахівців спільноти краще розподіляла обов'язки щодо виконання побажань по всьому руху. | Jack Wheeler |
| PES1.7 | До четвертого кварталу ми завершили 1 експеримент та визначили ще 3 експерименти для покращення початкової реакції на побажання (що призведе до зміни статусу) у наступному фінансовому році. | Ми хочемо додати ясності та точності до того, як фонд взаємодіє з новими побажаннями, щоб покращити задоволеність учасників та взаємодію зі списком бажань. Ми вважаємо, що покращуючи процес обробки побажань, фонд буде краще оснащений для визначення пріоритетів побажань. | Jack Wheeler |
Гіпотези
Подальші гіпотези є конкретними речами, які ми робимо щокварталу, щоб досягти пов'язаних ключових результатів, зазначених вище.
Кожна гіпотеза - це експеримент або етап експерименту, який, на нашу думку, допоможе досягти ключового результату. Команди розробляють гіпотезу, перевіряють її, потім уточнюють свої висновки або розробляють зовсім іншу нову гіпотезу. Гіпотезу можна сприймати як припущення команди для перевірки протягом даного часу. Команди роблять малі припущення на кілька тижнів або великі припущення на кілька місяців, але з урахуванням ризиків результат повинен бути пропорційним часу, який команда в нього вкладає. Наші гіпотези мають бути гнучкими і швидко адаптуватися. Ми можемо відкинути, використати або почати нову гіпотезу в будь-який момент кварталу.
Щоб побачити найбільш актуалізований стан гіпотези і/або обговорити гіпотезу з командою, будь ласка, натисніть посилання на сторінку проєкту нижче.
Перший квартал
Перший квартал (Q1) річного плану ФВМ охоплює липень-вересень.
| Гіпотези Вікідосвіду (ВД) | ||
|---|---|---|
| Акронім гіпотези | Q1 текст | Деталі і обговорення |
| WE1.1.1 | Якщо розширити Список подій до Спільнотного списку включно з Вікіпроєктами, нам вдасться зібрати деякі перші враження щодо того, як застосувати Вікіпроєкти для розвитку продукту. | |
| WE1.1.2 | Якщо ми визначимо щонайменше 15 Вікіпроєктів у 3-х окремих Вікіпедіях, щоб включити їх у Спільнотні списки, то ми зможемо дати поради групі Продукту Кампанії щодо ключових характеристик, необхідних для створення MVP Спільнотного списку, який включає Вікіпроєкти. | |
| WE1.1.3 | Якщо ми порадимось із 20-ма організаторами заходів і 20-ма організаторами Вікіпроєктів про найкраще використання тем, доступних через LiftWing, то ми можемо встановити пріоритети змін до тематичної моделі, яка покращить актуальні зв'язки між подіями і Вікіпроєктами. | |
| WE1.2.1 | Якщо ми створимо першу версію Edit Check API і використаємо її для впровадження нового інструменту перевірки, ми зможемо оцінити швидкість і простоту, з якою інші команди та волонтери можуть використовувати API для створення нового інструменту перевірки і підказки редагувань. | |
| WE1.2.2 | Якщо ми побудуємо бібліотеку компонентів інтерфейсу користувача та візуальних артефактів, досвід користувача інструменту Edit Check можна буде поширити на адаптацію алгоритмів Structured Tasks. | |
| WE1.2.3 | Якщо ми проведемо користувацькі тестування на двох або більше прототипах дизайну з запровадженням структурованих завдань для нових користувачів у рамках Візуального редактора чи близьких до нього, ми можемо швидко дізнатися, які елементи будуть працювати найкраще для нових редакторів, а також дозволити інженерам оцінити технічну виправданість і оцінити зусилля для кожного варіанту. | mw:Growth/Constructive activation experimentation |
| WE1.2.4 | Якщо ми навчимо LLM виявляти "поведінку павича" (намагання привернути увагу), після чого переконаємось, чи може він виявити це порушення політики з не менше ніж 70% точністю і більш ніж 50% скасувань і, в кінцевому підсумку, вирішити, чи є цей LLM достатньо ефективним, щоб забезпечити новий Edit Check і/або Suggested Edit. | |
| WE1.2.5 | Якщо ми проведемо тест A/B/C з прототипом альт-тексту підказки редагування у робочій версії додатку iOS, ми зможемо дізнатися, чи додавання тексту підписів до зображень є завданням, з яким новачки успішно справляються, і в кінцевому підсумку, вирішити, чи ця дія є настільки важливою, щоб реалізувати її у вигляді підказки редагування в мережі та/або в додатках. | mw:Wikimedia Apps/iOS Suggested edits project/Alt Text Experiment |
| WE1.3.1 | Якщо ми запустимо додаткове налаштування поведінки Automoderator і внесемо зміни на основі відгуків пілотного проекту у Q1, більше модераторів будуть задоволені його набором функцій і надійністю, і вирішать використовувати його на своєму проєкті Вікімедіа, тим самим збільшуючи прийняття продукту. | mw:Automoderator |
| WE1.3.2 | Якщо ми зможемо інтерпретувати категорії побажань як фокусну зону, пов'язану з модератором, і поділитися цими фокусними зонами для внеску спільнот у Q1-Q2, відтак ми отримаємо високу ступінь впевненості в тому, що наша обрана фокусна зона покращить задоволення модератора, коли вона буде випущена в Q3. | |
| WE2.1.1 | Якщо ми побудуємо модель висновку на рівні країни для статей Вікіпедії, ми зможемо фільтрувати списки статей до тих, що стосуються конкретного регіону з точністю більше 70% і відкликання більше 50%. | m:Research:Language-Agnostic Topic Classification/Countries |
| WE2.1.2 | Якщо ми побудуємо доказ концепції, що надає пропозиції щодо перекладу, які базуються на тематичних сферах, вибраних користувачами, ми будемо готові успішно протестувати, чи знайдуть перекладачі більше можливостей зробити переклади в своїх сферах зацікавлень і чи робитимуть більший внесок порівняно з загальними пропозиціями, наявними на даний момент. | mw: Translation suggestions: Topic-based & Community-defined lists |
| WE2.1.3 | Якщо ми пропонуємо створення списку як послугу, ми сприятимемо принаймні 5 спільнотам зробити більш цільові внески до своїх тематичних сфер, що вимірюється шляхом (1) зміни стандартного якісного покриття відповідних тем у відповідній вікі і (2) короткого опитування щодо задоволення організатора покриттям тематичної сфери на вікі. | |
| WE2.1.4 | Якщо ми розробили доказ концепції, який додає завдання перекладу, отримані з Вікіпроєктів та інших ініціатив створення списку, і представимо їх як пропозиції в рамках мобільного робочого потоку CX, то більше редакторів виявили б і перекладали статті, яких саме бракує у вікіпедії. Запровадивши варіант, який дозволяє редакторам вибирати пропозиції перекладу на основі тематичних списків, ми перевіряли б, чи цей підхід збільшує охоплення контенту в наших проєктах. | mw:Translation suggestions: Topic-based & Community-defined lists |
| WE2.2.1 | Якщо ми розширимо дані про стан мов Вікімедіа шляхом забезпечення домовленостей про обмін даними з ЮНЕСКО та Ethnologue, принаймні один партнер вирішить представити прогрес у включенні мов Вікімідії в своїх власних продуктах даних та комунікаціях. Крім того, що це корисно для наших організацій-партнерів, наш розширеній набір даних забезпечить важливу контекстну інформацію для прийняття рішень і надасть спільнотам інформацію, необхідну для визначення критичних сфер для втручання. | |
| WE2.2.2 | Якщо ми закартуємо діяльність у сфері документування мов, яку ведуть Вікімедійці за останні 2 роки, ми розробимо інформативну базу даних для досвіду спільноти щодо залучення нових мов. | |
| WE2.2.3 | Якщо ми надамо доступ до 5 нових мов, з Інкубатором або без нього, ми дізнаємося, чи доступ до повноцінної вікі з сучасними функціями, такими як на англійській Вікіпедії (включаючи підтримку ContentTranslation і Wikidata, розвинені інструменти редагувань та пошуку), сприятиме швидшому редагуванню. У кінцевому підсумку, це допоможе нам дізнатися, чи може цей підхід стати життєздатним напрямком для започаткування нових мовних розділів на основі нових або існуючих мов, виправдовуючи або ні подальші дослідження. | mw:Future of Language Incubation |
| WE2.3.1 | Якщо ми зробимо два подальші поліпшення потоку завантаження медіа на Вікісховище і поділимось ними зі спільнотою, відгуки будуть позитивними і це допоможе завантажувачам зробити менше невдалих завантажень (з огляду на авторські права), виміряні співвідношенням запитів на вилучення протягом 30 днів після завантаження. Це включатиме визначення дизайнів для подальших поліпшень UX на етапі вибору ліцензії при завантаженні на Вікісховище та запровадження MVP виявлення логотипів у ході завантаження. | |
| WE2.4.1 | Якщо ми побудуємо прототип запитів Вікіфункцій, вбудованих у вміст Медіавікі, ми будемо готові використовувати асинхронний процес обробки контенту Медіавікі і перевірити, наскільки ефективно він справляється, у другому кварталі. | phab:T261472 |
| WE2.4.2 | Якщо ми створимо прототип дизайну початкового випадку використання Вікіфункцій у Вікіпедії, ми будемо готові побудувати та перевірити нашу інтеграцію, і реалізація продуктивності буде перевірена у другому кварталі (див. гіпотезу 1). | phab:T363391 |
| WE2.4.3 | Якщо ми дозволимо користувачам Вікіфункцій отримати доступ до лексикографічних даних Вікіданих, вони розпочнуть створювати функції натуральної мови, які генеруватимуть фрази розмовної мови, включно з такими, що зможуть обробляти нестандартні форми. Якщо ми побачимо середній щомісячний рівень створення до 31 цих функцій, після того, як програма стане доступною, ми отримаємо підтвердження успішності нашого експерименту. | phab:T282926 |
| WE3.1.1 | Розробка і якісна оцінка трьох доказів концепції, спрямованих на створення курованих, персоналізованих та спільнотних навичок перегляду та навчання дозволить нам оцінити потенціал для збільшення повторного звернення читачів (експеримент 1: надання рекомендованого контенту в контексті пошуку та теми статті, експеримент 2: скорочення і спрощення змісту статті, експеримент 3: спрощення виконання розгалужених завдань на різних вікі). | |
| WE3.1.3 | Якщо ми розробимо моделі переробки змісту, наприклад, спрощення змісту або резюмування, яке можна буде розмістити і обслуговувати через нашу інфраструктуру (наприклад, LiftWing), ми створимо технічну організацію роботи, спрямовану на підвищення повторного звернення читачів за допомогою нових функцій отримання інформації. | |
| WE3.1.4 | Якщо ми аналізуємо прогнозований вплив на продуктивність гіпотез WE3.1.1 і WE3.1.2 на API пошуку, ми можемо визначити і вирішити проблеми з продуктивністю і масштабуванням, перш ніж вони негативно вплинуть на наших користувачів. | |
| WE3.1.5 | Якщо ми покращимо поле пошуку в додатку Android, щоб рекомендувати персоналізований контент на основі інтересів користувача і краще відобразити результати, ми дізнаємося, чи це покращує залучення користувачів, спостерігаючи, чи збільшує це показник враження і клікабельність (CTR) результатів пошуку на 5% у експериментальній групі порівняно з контрольною групою протягом 30-денного тесту A/B. Це поліпшення може потенційно призвести до збільшення на 1% повторного звернення незареєстрованих користувачів. | phab:T370117 |
| WE3.2.1 | Якщо ми створимо клікабельний прототип дизайну, який демонструє концепцію значка, що представляє донорів, зацікавлених у певних тематичних статтях, ми можемо дізнатися, чи буде прийнято спільнотою робочу версію цього методу для збору коштів у додатках. | Fundraising Experiment in the iOS App |
| WE3.2.2 | Збільшення виразності закликів до пожертв на незареєстрованих користувачів веб-мобільних та настільних пристроїв збільшить клікабельність посилання на пожертви на 30% рік за роком. | phab:T368765 |
| WE3.2.3 | Якщо зробити кнопку "Зробити пожертву" в iOS-версії більш виразною, наблизивши її на один клік або менше від головного навігаційного екрану, ми дізнаємося, чи пошукова простота була перешкодою для небанерних пожертв. | |
| WE3.3.1 | Якщо ми виберемо бібліотеку візуалізації даних і отримаємо початкову версію нової серверно-рендерної графічної служби доступної до кінця липня, ми зможемо дізнатися від волонтерів на Вікіманії, чи працюємо ми над рішенням, яке б вони використали для заміни старих графів. | |
| WE4.1.1 | Якщо ми впровадимо спосіб, яким користувачі можуть повідомляти про потенційні випадки переслідування та шкідливого контенту, наведеного в дискусіях, через систему звітності про інциденти, ми зможемо збирати дані про кількість і тип повідомлених інцидентів і, таким чином, краще зрозуміти контекст і дії, яких нам потрібно вжити. | |
| WE4.2.1 | Якщо ми вивчимо і визначимо методи, які стосуються Вікімедіа для унікальної ідентифікації пристроїв, ми зможемо визначити механізми збору та зберігання, які ми можемо пізніше реалізувати в наших робочих потоках проти зловживання, щоб забезпечити більш цільове блокування недобросовісних користувачів. | phab:T368388 |
| WE4.2.9 | Якщо ми надамо контекстуальну інформацію про репутацію, пов'язану з IP, щодо якого є намір блокуванння, ми завдамо менше супутньої шкоди через блокування пов'язаних IP і IP-діапазонів, тому що адміністратори матимуть більше уявлення про потенційну шкоду блокування для супутніх IP. Ми можемо виміряти це, використовуючи інструмент Special:Block і спостерігаючи, як змінюється поведінка, коли є додаткова інформація, і коли її немає. | WE4.2.9 Talk page |
| WE4.2.2 | Якщо ми визначимо алгоритм розрахунку рейтингу репутації користувача для використання в заходах протидії зловживанням, ми підготуємо основу для розробки заходів з використанням цього рейтингу як додаткового сигналу для адміністраторів, які вираховують ініціаторів шкідливих дій на нашій платформі. Ми знаємо, що гіпотеза є успішною, якщо алгоритм для розрахунку бальної оцінки з точністю X% для категорій існуючих облікових записів, наприклад, "низький" бал повинен застосовуватися до X% постійно заблокованих облікових записів. | WE4.2.2 Talk page |
| WE4.2.3 | Якщо ми побудуємо базу оцінювання, використовуючи доступні для публіки технології, подібні до тих, які використовувалися в попередніх атаках, ми дізнаємося більше про ефективність нашої нинішньої CAPTCHA при блокуванні атак і зможемо рекомендувати заміну CAPTCHA, яка приносить вимірюване поліпшення з точки зору зменшення рівня атак, досягнутого порівняно з витратами часу і фінансів. | |
| WE4.3.1 | Якщо ми застосуємо деякі інструменти машинного навчання та аналізу даних до журналів веб-запитів під час відомих атак, ми зможемо ідентифікувати неналежні IP-адреси з не менш ніж 80% точністю, звідки надходить переважно шкідливий трафік, який ми можемо потім скоротити, обмеживши найбільш виразний його край, тим самим покращуючи надійність для наших користувачів. | phab:T368389 |
| WE4.3.2 | Якщо ми обмежимо потік повторних атак з відомих нам IP-адрес, обмеживши інформацію, яку вони можуть розмістити на нашій інфраструктурі, ми зменшимо кількість ефективних перевантажувальних атак на 20%, покращуючи надійність для наших користувачів. | |
| WE4.3.3 | Якщо ми отримаємо докази концепції балансувальника навантаження 'Liberica', ми отримаємо вимір 33% поліпшення нашої спроможності в справі обробки потоків TCP SYN. | |
| WE4.3.4 | Якщо ми зробимо поліпшення в використанні і також виконаємо деякі тренувальні вправи на нашому інструменті 'requestctl', то SREs повідомлять про більшу впевненість у використанні інструменту. | phab:T369480 |
| WE4.4.1 | Якщо ми запустимо принаймні 2 цикли розгортання тимчасових рахунків, ми зможемо перевірити, чи це працює успішно. | |
| WE5.1.1 | Якщо ми успішно розгорнемо Parsoid Read Views на всіх Вікімандрах до першого кварталу, це підвищить нашу впевненість у розширенні Parsoid Reading Views на всі Вікіпедії. Ми вимірюємо успіх цього запуску шляхом детальних оцінок за допомогою звітів Confidence Framework, з особливим акцентом на звітах Visual Diff та показниках, пов'язаних з продуктивністю та зручністю використання. Крім того, ми оцінимо зменшення списку потенційних блокаторів, забезпечивши вирішення критичних питань до поширення Parsoid Read Views. | |
| WE5.1.2 | Якщо ми відключимо невикористану метрику Graphite, зосередимось на міграції з використанням db-префіксованої фабрики даних і збільшимо наші зусилля щодо поширення інформації до інших команд і спільноти в першому кварталі, то ми будемо на шляху до досягнення нашої мети зробити Graphite у режимі тільки для читання до третього кварталу 2015 року, спостерігаючи збільшення прогресу міграції на 30%. | |
| WE5.1.3 | Якщо ми реалізуємо канонічну структуру URL з налагодженням версії для нашого REST API, то ми можемо дозволити міграцію послуг і тестування для кінцевих точок Parsoid і аналогічних послуг у першому кварталі. | phab:T344944 |
| WE5.1.4 | Якщо ми завершимо решту роботи з метою зменшення впливу заходів анти-тракінгу переглядачів на автологін CentralAuth та перейдемо до більш стійкої інфраструктури автентифікації (SUL3), ми будемо готові розпочати продуктивні вікі у другому кварталі. | |
| WE5.1.5 | Якщо ми розширимо охоплення Sonar Cloud, включивши до нього ключові репозиторії MediaWiki Core, ми зможемо покращити підтримку кодової бази MediaWiki. Ця гіпотеза буде виміряна шляхом поділу вибраних репозиторіїв на тестові та контрольні групи. Ці групи потім будуть порівнюватися протягом кварталу, щоб оцінити вплив зворотного зв'язку на рівні комітів для розробників. | |
| WE5.2.1 | Якщо ми зробимо класифікацію типів хуків та властивостей реєстру розширень, що використовуються для впливу на поведінку ядра MediaWiki, ми зможемо зосередити подальші дослідження та втручання на найбільш впливових. | Simplify feature development |
| WE5.2.2 | Якщо ми дослідимо нову архітектуру сповіщень у ядрі MW та Echo, ми відкриємо нові способи забезпечення модульності та нові способи взаємодії розширень з ядром. | Simplify feature development |
| WE5.3.1 | Якщо ми інструментуватимемо код парсера та кешу для збору структури шаблону та детальних даних про час, ми зможемо кількісно оцінити очікуване покращення продуктивності, яке може бути реалізовано завдяки майбутньому розвитку платформи парсингу вікітексту. | T371713 |
| WE5.3.2 | Щодо редагування шаблонів, якщо ми зможемо реалізувати алгоритм у Parsoid для повторного використання HTML сторінки, яка залежить від відредагованого шаблону, без обробки сторінки з нуля та продемонструвати прискорення обробки в 1,5 раза або вище, ми матимемо потенційне рішення для поступового парсингу для ефективного оновлення сторінок після редагування шаблонів. | T363421 |
| WE5.4.1 | Якщо інженерна група MediaWiki успішно здійснить підзвітність процесу випуску та покращить свій процес комунікації до кінця другого кварталу. Узгодження зі стратегією продукту дозволить нам скасувати поточний процес, який залежить від незапланованої або волонтерської роботи, та підвищити задоволеність спільноти процесом випуску. Вимірюється відгуками спільноти щодо випуску 1.43 LTS у поєднанні зі значним скороченням незапланованих годин персоналу та волонтерів, необхідних для процесів випуску. | |
| WE5.4.2 | Якщо ми дослідимо та створимо процес для більш регулярного оновлення PHP разом із нашим процесом випуску MediaWiki, ми збільшимо швидкість та безпеку, одночасно зменшуючи складність та час виконання наших систем CI, спостерігаючи за успіхом оновлення PHP 8.1 перед випуском 1.43. | |
| WE6.1.1 | Якщо ми розробимо та завершимо початкове впровадження системи авторизації, ми створимо систему для ефективного управління схваленням усіх запитів на доступ LDAP. | |
| WE6.1.2 | Якщо ми дослідимо доступні показники документації, ми зможемо встановити показники, які вимірюють стан технічної документації Wikimedia, використовуючи документацію MediaWiki Core як тестовий випадок. | mw:Wikimedia Technical Documentation Team/Doc metrics |
| WE6.1.3 | Якщо ми зберемо інформацію про те, як різні команди приймають технічні рішення, ми зможемо зібрати передовий досвід та аналітичні дані, які можуть забезпечити та масштабувати подібні практики по всій організації. | |
| WE6.2.1 | Якщо ми публікуватимемо версію MediaWiki, розширень, скінів та конфігурації Wikimedia принаймні раз на день, ми виявимо нові обмеження та встановимо базовий рівень часу, необхідного для виконання. build. | mw:Wikimedia Release Engineering Team/Group -1 |
| WE6.2.2 | Якщо ми замінимо бекенд-інфраструктуру наших існуючих спільних середовищ розробки та тестування MediaWiki (від віртуальних серверів Apache до Kubernetes), це дозволить нам розширити її використання, забезпечивши доступ до сервісів MediaWiki на додаток до існуючої можливості розробки ядра, розширень та скінів MediaWiki в ізольованому середовищі. Ми розробимо одне середовище, яке включатиме MediaWiki, одне або декілька розширень та одну або декілька послуг. | wikitech:Catalyst |
| WE6.2.3 | Якщо ми створимо новий інтерфейс користувача розгортання, який надасть більше інформації розгортачеві та зменшить обсяг привілеїв, необхідних для розгортання, це спростить розгортання та відкриє розгортання для більшої кількості користувачів, що вимірюється кількістю унікальних розгортачів та кількістю патчів, перенесених у відсотках від наших загальних розгортань. | Wikimedia Release Engineering Team/SpiderPig |
| WE6.2.4 | Якщо ми перенесемо votewiki, wikitech та commons до MediaWiki на Kubernetes, ми отримаємо переваги узгодженості та більше не буде потреби підтримувати 2 різні інфраструктурні платформи паралельно, що дозволить зменшити кількість спеціально написаних інструментів, зробивши розгортання простішим та менш трудомістким для розгортачів. Це буде вимірюватися зменшенням загального часу розгортання та зменшенням кількості перешкод для розгортання. | завдання T292707 |
| WE6.2.5 | Якщо ми перенесемо маршрутизацію MultiVersion з MediaWiki, ми зможемо постачати контейнери MediaWiki з однією версією, що значно зменшить розмір контейнерів, що дозволить швидше розгортання, згідно з вимірюваннями інструменту розгортання. | SingleVersion MW: Routing options |
| WE6.3.1 | Консультуючись з розробниками Toolforge щодо найменш стійких аспектів платформи, ми зможемо зібрати список потенційних категорій для вимірювання. | |
| WE6.3.2 | Створивши «стандартний» інструмент для вимірювання кількості кроків для розгортання, ми зможемо оцінити максимальне покращення в процесі розгортання. | |
| WE6.3.3 | Якщо ми проведемо тести зручності використання, інтерв'ю з користувачами та конкурентний аналіз, щоб дослідити існуючі робочі процеси та варіанти використання Toolforge, ми зможемо визначити ключові області для покращення. Це дослідження дозволить нам визначити пріоритети покращень, які мають найбільший вплив на задоволеність та ефективність користувачів, закладаючи основу для майбутнього дизайну інтерфейсу користувача. | |
| Гіпотези щодо сервісів сигналів і даних (SDS) | ||
|---|---|---|
| Акронім гіпотези | Q1 текст | Деталі і обговорення |
| SDS 1.1.1 | Якщо ми співпрацюємо з власником ініціативи та оцінюємо вплив його роботи на показники Core Foundation, ми можемо визначити та соціалізувати повторюваний механізм, за допомогою якого команди у Foundation можуть надійно впливати на показники Core Foundation. | |
| SDS1.2.2 | Якщо ми вивчимо моделі набору, утримання та відтоку серед членів спільноти з тривалим стажем на офіційних посадах модерації та адміністрування, та зрозуміємо фактори, що впливають на ці явища («причини», що стоять за тенденціями), ми краще зрозуміємо масштаби, природу та мінливість цього явища в різних проєктах. Це, у свою чергу, дозволить нам визначити можливості для кращого втручання та підтримки, спрямованої на створення надійної багатопоколінної структури для редакторів. | phab:T368791 |
| SDS1.2.1 | Якщо ми зберемо варіанти використання від менеджерів з розробки продуктів та функцій щодо використання ШІ в сервісах Вікімедіа для читачів та учасників, ми зможемо визначити, чи слід нам тестувати та оцінювати існуючі моделі ШІ для інтеграції у функції продукту, і якщо так, то створити список моделей-кандидатів для тестування. | phab:T369281 |
| SDS1.3.1 | Якщо ми визначимо процес передачі всіх наборів даних та конфігурацій конвеєра з Платформи даних до DataHub, ми зможемо створити інструменти для автоматичного отримання документації походження. | |
| SDS 1.3.2 | Якщо ми впровадимо добре документований та зрозумілий процес створення проміжної таблиці, що представляє історію вікітексту MediaWiki, заповненої за допомогою платформи подій, та відстежуватимемо надійність та якість даних, ми дізнаємося, які додаткові частини процесу потрібні, щоб зробити цю таблицю готовою до створення та широко підтримуваною командою розробки Платформи даних. | |
| SDS2.1.2 | Якщо ми дослідимо поточний sdlc продуктів даних, ми зможемо визначити точки перегину, де знання QTE можуть бути застосовані, щоб позитивно вплинути на доставку продукту. | |
| SDS2.1.3 | Якщо команда Growth дізнається про Метрики Платформа, впровадивши модуль головної сторінки на платформі Metrics, тоді ми будемо готові окреслити план вимірювань у першому кварталі та завершити A/B-тестування на новій платформі Metrics до кінця другого кварталу. | |
| SDS2.1.4 | Якщо ми проведемо тестування зручності використання нашого прототипу серед пілотних користувачів нашого експериментального процесу, ми зможемо визначити та визначити пріоритети основних проблемних моментів, з якими стикаються менеджери продуктів та інші зацікавлені сторони під час самостійного налаштування та аналізу експериментів. Це розуміння призведе до вдосконалення наших інструментів, підвищення їхньої ефективності та впливу. | |
| SDS2.1.5 | Якщо ми розробимо систему документації, яка керуватиме досвідом користувачів, які створюють інструменти за допомогою платформи Metrics Platform, ми дозволимо цим користувачам самостійно створювати інструменти без прямої підтримки команд Data Products, за винятком крайніх випадків. | phab:T329506 |
| SDS2.2.1 | Якщо ми визначимо метрику для утримання читачів мобільних додатків, які не ввійшли в систему, яка застосовується для аналізу експериментів (A/B-тестування), ми можемо надати рекомендації щодо планування інструментів для вимірювання коефіцієнта утримання читачів, які не ввійшли в систему, у мобільних додатках та дозволити команді інженерів розробити стратегію експериментів, спрямовану на читачів, які не ввійшли в систему. | |
| SDS2.2.2 | Якщо ми визначимо стандартний підхід до вимірювання та аналізу коефіцієнтів конверсії, це допоможе нам створити колекцію чітко визначених метрик, які будуть використовуватися для експериментів та базових показників, а також почати порівнювати експерименти/проєкти для кращого вивчення цих даних. | |
| SDS2.2.3 | Якщо ми визначимо стандартний спосіб вимірювання та аналізу коефіцієнта кліків (CTR) у наших продуктах/функціях, це допоможе нам розробити експерименти, спрямовані на покращення CTR, стандартизувати інструменти відстеження кліків та дозволить нам зробити CTR доступним як цільовий показник для користувачів платформи експериментів. | |
| SDS2.3.1 | Якщо ми проведемо юридичний огляд запропонованих унікальних файлів cookie для користувачів, які не ввійшли в систему, ми зможемо визначити, чи існують якісь політики конфіденційності або інші правові питання, які впливають на обговорення в спільноті та/або впливають на саму технічну реалізацію. | |
| Гіпотези Майбутніх цільових груп (МЦГ) | ||
|---|---|---|
| Акронім гіпотези | Q1 текст | Деталі і обговорення |
| FA1.1.1 | Якщо ми докладемо дуже мало зусиль для внеску поза сайтом за допомогою експерименту «Додати факт» на базі штучного інтелекту, ми зможемо дізнатися, чи можуть користувачі поза платформою допомогти розвивати/підтримувати сховище знань у можливому майбутньому, коли контент Вікіпедії переважно споживатиметься поза платформою. | m:Future Audiences/Experiment:Add a Fact |
| Product and Engineering Support (PES) Hypotheses | ||
|---|---|---|
| Акронім гіпотези | Q1 текст | Деталі і обговорення |
| PES1.1.1 | Якщо керівна команда P&T регулярно синхронізуватиме інформацію про те, як вони спрямовують свої команди до більш ітеративної культури розробки програмного забезпечення, і ми збиратимемо базові показники поточних практик розробки та настроїв персоналу щодо того, як ми працюємо разом над випуском продуктів, ми виявимо можливості для управління змінами. Теми, що виникнуть, дозволять нам розробити цільові рекомендації або програми для наших команд у наступних кварталах. | |
| PES1.2.2 | Якщо команда інструментів модератора дослідить список бажань спільноти та розробить 2+ ключові області у першому кварталі, тоді ми зможемо отримати відгуки від спільноти та визначити проблему, яку спільнота та WMF зацікавлені вирішити. | |
| PES1.2.3 | Якщо ми об'єднаємо 3-5 побажань, пов'язаних з вибором та вставкою шаблонів, та запровадимо покращену функцію в першому кварталі, то CommTech зможе використати отримані знання для розробки тематичного дослідження для фонду, щоб включити більше «фокусних областей» до річного плану на 2025-26 роки. | |
| PES1.3.1 | Якщо ми надамо аудиторії інформацію про їхню спільноту та використання Вікіпедії протягом року, це стимулюватиме більший зв'язок з Вікіпедією – заохочуючи більшу залученість у формі обміну інформацією в соціальних мережах, часу, проведеного у взаємодії з Вікіпедією, або пожертвувань. Успіх буде вимірюватися завершенням експериментального проєкту, який пропонує принаймні одну рекомендацію щодо «Інформації з Вікіпедії» як можливості для підвищення залученості до он-вікі. | Wikipedia user insights |
| PES1.3.2 | Якщо ми створимо гру на основі Вікіпедії для щоденного використання, яка підкреслює зв'язки між широкими галузями знань, це заохочуватиме споживачів регулярно відвідувати Вікіпедію та сприятиме активному навчанню, що призведе до тривалішої та посиленої взаємодії з контентом у Вікіпедії. Успіх буде вимірюватися завершенням експериментального проєкту, який пропонує принаймні одну рекомендацію щодо гейміфікації навчання як можливості для підвищення залученості до он-вікі. | Wikipedia games |
| PES1.3.3 | Якщо ми розробимо новий процес/трек на хакерському заході Вікімедіа для інкубації майбутніх експериментів, це збільшить вплив та цінність таких подій, перетворивши їх на основу для майбутніх проєктів річного плану, одночасно сприяючи тіснішому зв'язку між волонтерами та інженерно-конструкторським персоналом для більшої участі у стратегічних ініціативах. Успіх буде вимірюватися тим, що принаймні один проєкт PES1.3 буде ініційований та/або просунутий до OKR в результаті заходу, підтримуваного фондом. | Incubator space |
| PES1.4.1 | Якщо ми розробимо SLO разом з командою редагування, яка випускає функцію перевірки редагування, ми почнемо вивчати та розуміти, як разом визначати та відстежувати SLO, орієнтовані на користувачів, та повторювати цей процес у майбутньому. | |
| PES1.4.2 | Якщо ми визначимо та опублікуємо SLA для переведення OOUI в «режим обслуговування», зростання нового коду з використанням OOUI в проєктах Вікімедіа залишатиметься в межах X% у першому кварталі. | |
| PES1.4.3 | Якщо ми зіставимо власність, використовуючи запропонований каталог сервісів для відомих сервісів, що належать, у першому кварталі, ми зможемо виявити значні прогалини в каталозі сервісів, оскільки це допоможе вирішити проблему культури SLO до кінця року. | |
Другий квартал
Другий квартал (Q2) річного плану ФВМ охоплює період з жовтня по грудень.
| Гіпотези Вікідосвіду (ВД) | ||
|---|---|---|
| Коротка назва гіпотези | Текст другого кварталу | Деталі і обговорення |
| WE1.1.1 | Якщо ми розширимо список подій, щоб він став списком спільноти, що включає ВікіПроєкти, тоді ми зможемо зібрати деякі ранні знання про те, як взаємодіяти з ВікіПроєктами для розробки продуктів. | Campaigns/Foundation Product Team/Event list |
| WE1.1.2 | Якщо ми запустимо принаймні 1 консультацію, зосереджену на співпраці у вікі, та якщо ми зберемо відгуки щонайменше від 20 залучених осіб. У такій співпраці ми зможемо консультувати Campaigns Product щодо ключових характеристик, необхідних для розробки нового або вдосконаленого способу зв'язку. | Campaigns/WikiProjects |
| WE1.1.3 | Якщо ми порадимось із 20-ма організаторами заходів і 20-ма організаторами Вікіпроєктів про найкраще використання тем, доступних через LiftWing, то ми можемо встановити пріоритети змін до тематичної моделі, яка покращить актуальні зв'язки між подіями і Вікіпроєктами. | |
| WE1.1.4 | Якщо ми інтегруємо CampaignEvents у Community Configuration у другому кварталі, то ми створимо основу для того, щоб щонайменше 5 вікі-сайтів вирішили ввімкнути функції розширення у третьому кварталі, тим самим збільшуючи використання інструментів. | |
| WE1.2.2 | Якщо ми створимо бібліотеку компонентів інтерфейсу користувача та візуальних артефактів, користувацький досвід Edit Check може бути розширений, щоб враховувати шаблони структурованих завдань. | |
| WE1.2.5 | Якщо ми проведемо A/B/C-тестування з прототипом запропонованих редагувань alt-тексту у робочій версії додатка для iOS, ми зможемо дізнатися, чи є додавання alt-тексту до зображень завданням, з яким успішно справляються новачки, і зрештою вирішити, чи є воно достатньо ефективним для впровадження як запропонованого редагування в Інтернеті та/або в додатках. | |
| WE1.2.6 | Якщо ми представимо новим власникам облікових записів структуроване завдання «Додати посилання» у статтях Вікіпедії, ми очікуємо збільшення відсотка нових власників облікових записів, які конструктивно активуються на мобільних пристроях, на 10% порівняно з базовим рівнем. | |
| WE1.3.1 | Якщо ми запустимо додаткове налаштування поведінки Automoderator і внесемо зміни на основі відгуків пілотного проекту у Q1, більше модераторів будуть задоволені його набором функцій і надійністю, і вирішать використовувати його на своєму проєкті Вікімедіа, тим самим збільшуючи прийняття продукту. | mw:Moderator Tools/Automoderator |
| WE1.3.3 | Якщо ми покращимо користувацький досвід та функції Розширення Nuke протягом другого кварталу, ми збільшимо задоволеність адміністраторів продуктом на 5 пунктів до кінця кварталу. | mw:Extension:Nuke/2024 Moderator Tools project |
| WE2.1.3 | Якщо ми пропонуватимемо створення списків як послугу, ми дозволимо щонайменше 5 спільнотам робити більш цілеспрямований внесок у свої тематичні області, що вимірюється (1) зміною стандартної якості висвітлення відповідних тем у відповідній вікі та (2) коротким опитуванням щодо задоволеності організаторів висвітленням тематичної області у вікі. | |
| WE2.1.4 | Якби ми розробили перевірку концепції, яка додає завдання перекладу, отримані з WikiProjects та інших ініціатив зі створення списків, і представляли їх як пропозиції в рамках робочого процесу CX для мобільних пристроїв, то більше редакторів виявляли б і перекладали статті, зосереджені на тематичних прогалинах.
Запровадивши опцію, яка дозволяє редакторам вибирати пропозиції перекладу на основі тематичних списків, ми перевіримо, чи збільшує цей підхід охоплення контенту в наших проєктах. |
|
| WE2.1.5 | If we expose topic-based translation suggestions more broadly and analyze its initial impact, we will learn which aspects of the translation funnel to act on in order to obtain more quality translations. | |
| WE2.2.4 | Якщо ми надамо доступ до 5 нових мов, з Інкубатором або без нього, ми дізнаємося, чи доступ до повноцінної вікі з сучасними функціями, такими як на англійській Вікіпедії (включаючи підтримку ContentTranslation і Wikidata, розвинені інструменти редагувань та пошуку), сприятиме швидшому редагуванню. У кінцевому підсумку, це допоможе нам дізнатися, чи може цей підхід стати життєздатним напрямком для започаткування нових мовних розділів на основі нових або існуючих мов, виправдовуючи або ні подальші дослідження. | |
| WE2.2.5 | Якщо ми перенесемо addwiki.php до ядра та налаштуємо його для Wikimedia, ми покращимо якість коду в нашій системі створення вікі, зробивши її тестованою та надійною, а також спростимо роботу для творців нових вікі та тим самим зробимо значні кроки до спрощення процесу створення вікі. | phab:T352113 |
| WE2.3.2 | Якщо ми внесемо ще два покращення до процесу завантаження медіафайлів на Commons та поділимося ними зі спільнотою, відгуки будуть позитивними, і це допоможе тим, хто завантажує, робити менше поганих завантажень (з акцентом на авторське право), що вимірюється співвідношенням запитів на видалення протягом 30 днів з моменту завантаження. Це включатиме випуск подальших покращень UX для кроку прав випуску в Майстрі завантаження на Commons та автоматичне виявлення зовнішніх джерел. | |
| WE2.3.3 | Якщо Робоча група BHL-Wikimedia створить категорії Commons та описові рекомендації для південноамериканських та/або африканських видів, зображених у публікаціях, вони зроблять 3000 зображень доступнішими для спільнот біорізноманіття. (BHL = Бібліотека спадщини біорізноманіття) | |
| WE2.4.1 | Якщо ми створимо прототип викликів Wikifunctions, вбудованих у контент MediaWiki, та протестуємо його локально на стабільність, ми будемо готові використовувати конвеєр асинхронної обробки контенту MediaWiki та перевірити його продуктивність у другому кварталі. | phab:T261472 |
| WE2.4.2 | Якщо ми створимо прототип початкового випадку використання Wikifunctions у вікі Вікіпедії, ми будемо готові створити та протестувати нашу інтеграцію, коли продуктивність буде підтверджена у другому кварталі, як зазначено в Гіпотезі 1. | phab:T363391 |
| WE2.4.3 | Якщо ми надамо користувачам Wikifunctions доступ до лексикографічних даних Wikidata, вони почнуть створювати функції природної мови, які генерують речення-фрази, включаючи ті, що можуть обробляти неправильні форми. Якщо ми побачимо середній щомісячний коефіцієнт створення 31 для цих функцій, після того, як функція стане доступною, ми знатимемо, що наш експеримент успішний. | phab:T282926 |
| WE3.1.3 | Якщо ми розробимо моделі для реміксування контенту, такі як спрощення контенту або узагальнення, які можна розміщувати та обслуговувати через нашу інфраструктуру (наприклад, LiftWing), ми визначимо технічний напрямок роботи, спрямованої на збільшення утримання читачів за допомогою нових функцій пошуку контенту. | Research |
| WE3.1.6 | Якщо ми впровадимо персоналізовану функцію «кролячої нори» в додатку для Android і рекомендуватимемо скорочені версії статей на основі типів тем і розділів, які цікавлять користувача, ми дізнаємося, чи є функція достатньо «закріпленою», щоб призвести до багатоденного використання 10% користувачів, які брали участь в експерименті протягом 30-денного періоду, та вищого рівня переглядів сторінок, ніж користувачі, які не мали доступу до цієї функції. | Rabbit Holes |
| WE3.1.7 | Якщо ми проведемо якісний експеримент, зосереджений на представленні узагальнень статей веб-читачам, ми визначимо, чи мають узагальнення статей потенціал збільшити утримання читачів, що підтверджується коефіцієнтом кліків та моделями використання. | |
| WE3.1.8 | Якщо ми створимо одну функцію, яка надає додаткові рекомендації на рівні статті, ми побачимо збільшення коефіцієнт кліків на 10% порівняно з існуючими варіантами рекомендацій та значне збільшення зовнішніх рефералів для користувачів, які активно взаємодіють з новою функцією. | |
| WE3.2.2 | Підвищення помітності точок входу для пожертвувань у мобільній та настільній версіях Vector, де не ввійшли в систему, збільшить коефіцієнт кліків посилання для пожертвування на 30% у річному обчисленні. | mw:Readers/2024 Reader and Donor Experiences |
| WE3.2.3 | Якщо зробити кнопку "Зробити пожертву" в iOS-версії більш виразною, наблизивши її на один клік або менше від головного навігаційного екрану, ми дізнаємося, чи пошукова простота була перешкодою для небанерних пожертв. | Navigation Refresh |
| WE3.2.4 | Якщо ми оновимо сторінку внесків для зареєстрованих користувачів у додатку, щоб включити активний значок для того, хто є донором додатка, та відобразити неактивний стан із запрошенням зробити пожертву для того, хто вирішив не робити пожертву в додатку, ми дізнаємося, чи є це визнання цінним для поточних донорів та заохочує до пожертвувань для потенційних донорів, інформуючи, чи варто розширювати концепцію значків донорів чи відмовитися від неї. | Private Donor Recognition Experiment |
| WE3.2.5 | Якщо ми створимо експеримент «Вікіпедія в огляді» в додатку Вікіпедія, щоб дозволити користувачам бачити та ділитися персоналізованими даними про свої звички читання, редагування та пожертвування, ми побачимо, що 2% глядачів роблять пожертви на iOS завдяки цій функції, 5% частки кліків та 65% користувачів оцінять функцію як нейтральну або задовільну. | Personalized Wikipedia Year in Review |
| WE3.2.7 | Збільшення Високий рівень точок входу для пожертвувань у мобільній та настільній версіях Minerva без входу в систему збільшить коефіцієнт кліків за посиланням для пожертвування на 30% у порівнянні з минулим роком. | |
| WE3.3.2 | Якщо ми розробимо MVP Charts та запустимо його повністю у тестових вікі-проєктах, принаймні дві Вікіпедії + Commons погодяться провести його пілотне тестування до заморожування коду в грудні. | |
| WE3.4.1 | Якби ми дослідили доцільність, провівши експеримент зі створення менших точок доступу (PoP) у хмарних провайдерів, таких як Amazon, ми могли б розширити карту наших центрів обробки даних та охопити більше користувачів по всьому світу за меншими витратами та збільшеним часом виконання. | |
| WE4.1.2 | Якщо ми розгорнемо принаймні одну ітерацію MVP Системи звітності про інциденти на пілотних вікі-проєктах, ми зможемо зібрати цінні дані про частоту та типи інцидентів, про які повідомляється. | Incident Reporting System |
| WE4.2.1 | Якщо ми дослідимо та визначимо специфічні для Wikimedia методи для унікальної моделі ідентифікації пристрою, ми зможемо визначити механізми збору та зберігання, які ми згодом зможемо впровадити в наші робочі процеси боротьби з зловживаннями, щоб забезпечити більш цілеспрямоване блокування зловмисників. | |
| WE4.2.9 | Якщо ми надамо контекстуальну інформацію про репутацію, пов'язану з IP, щодо якого є намір блокуванння, ми завдамо менше супутньої шкоди через блокування пов'язаних IP і IP-діапазонів, тому що адміністратори матимуть більше уявлення про потенційну шкоду блокування для супутніх IP. Ми можемо виміряти це, використовуючи інструмент Special:Block і спостерігаючи, як змінюється поведінка, коли є додаткова інформація, і коли її немає. | |
| WE4.2.2 | Якщо ми визначимо алгоритм для розрахунку оцінки репутації облікового запису користувача для використання в робочих процесах боротьби зі зловживаннями, ми підготуємо основу для інженерних зусиль, які використовуватимуть цю оцінку як додатковий сигнал для адміністраторів, що націлюються на зловмисників на нашій платформі. Ми знатимемо, що гіпотеза успішна, якщо алгоритм розрахунку оцінки відповідає з точністю X% категоріям існуючих облікових записів, наприклад, «Низький» бал має застосовуватися до X% постійно заблокованих облікових записів. | |
| WE4.2.3 | Якщо ми створимо систему оцінювання, використовуючи загальнодоступні технології, подібні до тих, що використовувалися в попередніх атаках, ми дізнаємося більше про ефективність нашої поточної CAPTCHA у блокуванні атак і зможемо рекомендувати заміну CAPTCHA, яка принесе вимірне покращення з точки зору досяжного рівня атак за заданий час та фінансові витрати. | |
| WE4.3.1 | Якщо ми застосуємо деякі інструменти машинного навчання та аналізу даних до журналів веб-запитів під час відомих атак, ми зможемо ідентифікувати неналежні IP-адреси з не менш ніж 80% точністю, звідки надходить переважно шкідливий трафік, який ми можемо потім скоротити, обмеживши найбільш виразний його край, тим самим покращуючи надійність для наших користувачів. | |
| WE4.3.3 | Якщо ми розгорнемо експериментальне випробування балансувальника навантаження «Liberica», ми виміряємо покращення нашої здатності обробляти TCP SYN-флуди на 33%. | |
| WE4.3.5 | Створивши систему, яка породжує та контролює тисячі віртуальних працівників у хмарному середовищі, ми зможемо імітувати атаки розподіленої відмови в обслуговуванні (DDoS) та ефективно вимірювати здатність системи протистояти таким атакам, пом'якшувати їх та реагувати на них. | |
| WE4.3.6 | Якщо ми інтегруємо вихідні дані моделей, які ми створили в WE 4.3.1, з динамічними порогами обмежень паралельності на IP-адресу, які ми створили для наших термінаторів TLS у WE 4.3.2, ми повинні мати змогу збільшити нашу здатність автоматично нейтралізувати атаки на 20% більшим обсягом, виміряним за допомогою системи моделювання, яку ми створюємо. | |
| WE4.3.7 | Якщо ми розгорнемо зручний веб-додаток, який дозволяє допоміжне редагування та створення Завдяки правилам requestctl, SRE зможуть запобігати атакам кешування на 50% швидше, ніж наш встановлений базовий рівень. | |
| WE4.4.2 | Якщо ми розгорнемо тимчасові облікові записи для набору малих та середніх проєктів, ми зможемо забезпечити належну роботу функціональності та зібрати дані для подальшої роботи. | Trust and Safety Product/Temporary Accounts |
| WE5.1.1 | Якщо нам вдасться успішно розгорнути Parsoid Read Views на всіх Wikivoyages до першого кварталу, це підвищить нашу впевненість у поширенні Parsoid Read Views на всі Вікіпедії. Ми будемо вимірювати успіх цього розгортання за допомогою детальних оцінок, використовуючи звіти Confidence Framework, з особливим акцентом на звіти Visual Diff та показники, пов'язані з продуктивністю та зручністю використання. Крім того, ми оцінимо скорочення списку потенційних блокувальників, забезпечуючи вирішення критичних проблем перед ширшим розгортанням. | |
| WE5.1.3 | Якщо ми перенаправимо кінцеві точки, які зараз доступні за шляхами rest_v1/page/html та rest_v1/page/title, на порівнянні кінцеві точки контенту MW, то ми зможемо розблокувати закриття RESTbase без переривання роботи клієнтів у першому кварталі. | |
| WE5.1.4 | Якщо ми завершимо решту роботи для пом'якшення впливу заходів проти відстеження браузерів на автоматичний вхід CentralAuth та перейдемо до більш стійкої інфраструктури автентифікації (SUL3), ми будемо готові до розгортання у виробничих вікі у другому кварталі. | |
| WE5.1.5 | Якщо ми збільшимо кількість відповідних правил SonarCloud, увімкнених для ключових репозиторіїв MediaWiki Core, та покращимо якість зворотного зв'язку, що надається розробникам, ми оптимізуємо досвід розробників та дозволимо їм покращити підтримку кодової бази MediaWiki в майбутньому. Це буде вимірюватися шляхом відстеження рівня задоволеності розробників та того, чи вважають розробники тестових груп інструмент більш корисним та ефективним у їхньому робочому процесі. Зворотній зв'язок буде зібрано за допомогою опитувань та безпосередньої інформації від розробників, щоб оцінити сприйнятий вплив на їхню довіру до інструменту та загальний досвід розробки. | |
| WE5.1.7 | Якщо ми представимо всі відповіді кінцевих точок модулів контенту (загалом 10) у наших визначеннях специфікацій MediaWiki REST API OpenAPI, ми зможемо реалізувати програмну перевірку, щоб гарантувати, що наша згенерована документація відповідає фактичним відповідям, поверненим у коді. | |
| WE5.1.8 | Якщо ми впровадимо підтримку перекладу опису кінцевих точок (тобто не включає фактичні визначення об'єктів або корисні навантаження) у наші згенеровані специфікації MediaWiki REST API OpenAPI, ми зможемо закласти основу для підтримки очікуваних стандартів інтернаціоналізації Вікімедіа. | |
| WE5.2.3 | Якщо ми проведемо експеримент з перевтілення принаймні [1-3] існуючих функцій Core та Extension, використовуючи новий шаблон компонентів платформи Domain Event та Listener як альтернативу традиційним перехоплювачам, ми зможемо підтвердити наше припущення про це втручання, що дозволить спростити реалізацію з більш послідовною поведінкою функцій. | |
| WE5.3.3 | Якщо ми інструментуватимемо обидва парсери для збору інформації про доступність попередніх розборів та час розширення шаблонів, а також для класифікації оновлень та залежностей, ми зможемо визначити пріоритети роботи над вибірковими оновленнями (Гіпотеза 5.3.2). на основі кількісної оцінки очікуваних переваг у продуктивності. | |
| WE5.3.4 | Якщо ми зможемо збільшити можливості нашої реалізації вибіркового оновлення прототипу в Parsoid, використовуючи висновки, отримані з гіпотези 5.3.1, ми зможемо використати більше можливостей для збільшення переваг у продуктивності від вибіркового оновлення. | |
| WE5.4.1 | Якщо інженерна група MediaWiki успішно здійснить підзвітність процесу випуску та покращить свій процес комунікації до кінця другого кварталу. Узгодження зі стратегією продукту дозволить нам скасувати поточний процес, який залежить від незапланованої або волонтерської роботи, та підвищити задоволеність спільноти процесом випуску. Вимірюється відгуками спільноти щодо випуску 1.43 LTS у поєднанні зі значним скороченням незапланованих годин персоналу та волонтерів, необхідних для процесів випуску. | |
| WE5.4.2 | Якщо ми дослідимо та створимо процес для більш регулярного оновлення PHP у поєднанні з нашим процесом випуску MediaWiki, ми збільшимо швидкість та безпеку, одночасно зменшуючи складність та час виконання наших систем неперервної інтеграції, спостерігаючи за успіхом оновлення PHP 8.1 до випуску 1.43. | |
| WE6.1.3 | Якщо ми зберемо аналітику того, як різні команди приймають технічні рішення, ми зможемо зібрати передовий досвід та аналітичні дані, які можуть забезпечити та масштабувати аналогічні практики по всій організації. | |
| WE6.1.4 | Якщо ми дослідимо рішення для індексації коду всіх проєктів, розміщених у репозиторіях коду WMF, ми зможемо вибрати рішення, яке дозволить нашим користувачам швидко знаходити код, коли справа доходить до реагування на інциденти або усунення несправностей. | |
| WE6.1.5 | Якщо ми протестуємо підмножину метрик чернеток на експериментальній групі колекцій технічної документації, ми зможемо прийняти обґрунтоване рішення про те, які метрики впроваджувати для документації MediaWiki. | Wikimedia Technical Documentation Team/Doc metrics |
| WE6.2.1 | Якщо ми публікуватимемо версію MediaWiki, розширень, скінів та конфігурації Wikimedia принаймні раз на день, ми виявимо нові обмеження та встановимо базовий рівень часу, необхідного для виконання. build. | mw:Wikimedia Release Engineering Team/Group -1 |
| WE6.2.2 | Якщо ми замінимо бекенд-інфраструктуру наших існуючих спільних середовищ розробки та тестування MediaWiki (від віртуальних серверів Apache до Kubernetes), це дозволить нам розширити її використання, забезпечивши сервіси MediaWiki на додаток до існуючої можливості розробки. Ядро, розширення та скіни MediaWiki в ізольованому середовищі. Ми розробимо одне середовище, яке включатиме MediaWiki, одне або декілька розширень та один або декілька сервісів. | wikitech:Catalyst |
| WE6.2.3 | Якщо ми створимо новий інтерфейс користувача розгортання, який надасть більше інформації розгортачеві та зменшить обсяг привілеїв, необхідних для розгортання, це спростить розгортання та відкриє розгортання для більшої кількості користувачів, що вимірюється кількістю унікальних розгортачів та кількістю патчів, перенесених у відсотках від наших загальних розгортань. | mw:SpiderPig |
| WE6.2.5 | Якщо ми перенесемо маршрутизацію MultiVersion з MediaWiki, ми зможемо постачати контейнери MediaWiki з однією версією, що значно зменшить розмір контейнерів, що дозволить швидше розгортання, згідно з вимірюваннями інструменту розгортання. | https://docs.google.com/document/d/1_AChNfiRFL3VdNzf6QFSCL9pM2gZbgLoMyAys9KKmKc/edit |
| WE6.2.6 | Якщо ми зберемо відгуки від QTE, SRE та осіб зі знаннями в конкретній предметній області та використаємо їхні відгуки для написання проєктного документа для розгортання та використання контейнера wmf/next OCI, то ми зменшимо тертя, коли почнемо розгортати цей контейнер. | T379683 |
| WE6.3.4 | Якщо ми ввімкнемо автоматичне розгортання мінімального інструменту, ми зможемо оцінити весь процес і закласти основу для додавання підтримки складніших інструментів і процесів розгортання. | phab:T375199 |
| WE6.3.5 | Оцінюючи відносну важливість кожної категорії сталого розвитку та пов'язаних з нею показників, ми можемо створити нормалізовану систему оцінювання. Ця система, після впровадження та реєстрації, забезпечить базову основу для вимірювання та порівняння прогресу Toolforge у сфері сталого розвитку з плином часу. | phab:T376896 |
| WE6.3.6 | Якщо ми проведемо дослідження, такі як інтерв'ю з цільовими користувачами та конкурентний аналіз, щоб визначити існуючі проблемні точки Toolforge та можливості для покращення, ми зможемо рекомендувати пріоритетний список функцій для майбутнього інтерфейсу користувача Toolforge. | Phab:T375914 |
| Гіпотези щодо сервісів сигналів і даних (SDS) | ||
|---|---|---|
| Акронім гіпотези | Текст другого кварталу | Деталі і обговорення |
| SDS 1.1.1 | Якщо ми співпрацюємо з власником ініціативи та оцінюємо вплив його роботи на показники Core Foundation, ми можемо визначити та соціалізувати повторюваний механізм, за допомогою якого команди у Foundation можуть надійно впливати на показники Core Foundation. | |
| SDS1.2.1.B | If we test the accuracy and infrastructure constraints of 4 existing AI language models for 2 or more high-priority product use-cases, we will be able to write a report recommending at least one AI model that we can use for further tuning towards strategic product investments. | Phab:T377159 |
| SDS1.2.2 | Якщо ми вивчимо моделі набору, утримання та відтоку серед членів спільноти з тривалим стажем на офіційних посадах модерації та адміністрування, та зрозуміємо фактори, що впливають на ці явища («причини», що стоять за тенденціями), ми краще зрозуміємо масштаби, природу та мінливість цього явища в різних проєктах. Це, у свою чергу, дозволить нам визначити можливості для кращого втручання та підтримки, спрямованої на створення надійної багатопоколінної структури для редакторів. | Learn more. |
| SDS1.2.3 | Якщо ми поєднаємо існуючі знання про модераторів з кількісними методами виявлення активності модерації, ми зможемо систематично визначати та ідентифікувати модераторів Вікіпедії. | T376684 |
| SDS1.3.1.B | Якщо ми інтегруємо конектор Spark / DataHub для всіх виробничих завдань Spark, ми отримаємо лінійність на рівні стовпців для всіх завдань платформи даних на основі Spark у DataHub. | |
| SDS1.3.2.B | Якщо ми реалізуємо часто використовувану роботу щодо запиту даних історії MariaDB MW на основі Spark, узгодимо відсутні елементи і збагатимо їх, ми надаватимемо щодня оновлювану таблицю даних про історію вікітексту MW. | |
| SDS2.1.1 | Якщо ми створимо середовище для тестування інтеграції для запропонованого стороннього експериментального рішення, ми зможемо практично співпрацювати з Data SRE, SRE, QTE та Product Analytics, щоб оцінити життєздатність рішення в інфраструктурі WMF, щоб дати впевнену рекомендацію щодо збірки/встановлення/купівлі. | mw:Data Platform Engineering/Data Products/work focus |
| SDS2.1.3 | Якщо команда Growth дізнається про платформу метрик, встановивши модуль домашньої сторінки на платформі метрик, ми будемо готові окреслити план вимірювань у 1-й квартал та завершення A/B-тестування на новій платформі Metrics до кінця 2-го кварталу. | |
| SDS2.1.4 | Якщо ми проведемо тестування зручності використання нашого прототипу серед пілотних користувачів нашого експериментального процесу, ми зможемо визначити та визначити пріоритети основних проблемних моментів, з якими стикаються менеджери продуктів та інші зацікавлені сторони під час самостійного налаштування та аналізу експериментів. Це розуміння призведе до вдосконалення наших інструментів, підвищення їхньої ефективності та впливу. | |
| SDS2.1.5 | Якщо ми розробимо систему документації, яка керуватиме досвідом користувачів, які створюють інструменти за допомогою платформи Metrics, ми дозволимо цим користувачам самостійно створювати інструменти без прямої підтримки команд Data Products, за винятком крайніх випадків. | завдання T329506 |
| SDS2.1.7 | Якщо ми надамо функцію реєстрації користувачів та механізм для захоплення та зберігання подій CTR у монотаблиці в попередньо оголошеному потоці подій, ми можемо випустити MPIC Alpha, щоб запустити базове розділене A/B-тестування для зареєстрованих користувачів. | |
| SDS2.2.2 | Якщо ми визначимо стандартний підхід до вимірювання та аналізу коефіцієнтів конверсії, це допоможе нам створити колекцію чітко визначених метрик, які будуть використовуватися для експериментів та базових показників, а також почати порівнювати експерименти/проєкти для кращого вивчення цих даних. | |
| SDS2.3.1 | Якщо ми проведемо юридичний огляд запропонованих унікальних файлів cookie для користувачів, які не ввійшли в систему, ми зможемо визначити, чи існують якісь політики конфіденційності або інші юридичні питання, які впливають на обговорення в спільноті та/або впливають на саму технічну реалізацію. | |
| Гіпотези Майбутніх цільових груп (МЦГ) | ||
|---|---|---|
| Акронім гіпотези | Текст другого кварталу | Деталі і обговорення |
| FA1.1.1 | Якщо ми докладемо дуже мало зусиль для зовнішнього внеску за допомогою експерименту «Додати факт» на базі штучного інтелекту, ми зможемо дізнатися, чи можуть позаплатформні користувачі допомогти розвивати/підтримувати сховище знань у можливому майбутньому, коли контент Вікіпедії буде споживатися переважно поза платформою. | Experiment:Add a Fact |
| Product and Engineering Support (PES) Hypotheses | ||
|---|---|---|
| Акронім гіпотези | Q1 текст | Деталі і обговорення |
| PES1.2.4 | Якщо ми дослідимо фокусну область «Пріоритетність завдань» у списку бажань спільноти в... На початку другого кварталу ми зможемо визначити та визначити пріоритети роботи, які покращать задоволеність модераторів, і впровадження яких ми зможемо розпочати у третьому кварталі. | |
| PES1.2.5 | Якщо ми зможемо опублікувати та отримати відгуки спільноти щодо понад 6 ключових напрямків у другому кварталі, то ми зможемо впевнено представити щонайменше 3 ключові напрямки для включення до річного плану на 2025-26 роки. | |
| PES1.2.6 | Запровадивши шаблони до обраного, ми збільшимо кількість шаблонів, доданих через діалогове вікно шаблонів, на 10%. | |
| PES1.3.4 | Якщо ми створимо досвід, який надає аудиторії Вікіпедії інформацію про їхню спільноту протягом року, це стимулюватиме більший зв'язок з Вікіпедією – заохочуючи залучення у формі обміну в соціальних мережах, часу, проведеного за взаємодією у Вікіпедії, або пожертвувань. | |
| PES1.4.1 | Якщо ми розробимо SLO разом з командою редагування, яка випускає функцію перевірки редагування, ми почнемо вивчати та розуміти, як разом визначати та відстежувати SLO, що контактують з користувачами, та повторювати цей процес у майбутньому. | |
| PES1.4.2 | Якщо ми визначимо та опублікуємо SLA для переведення OOUI в «режим обслуговування», зростання нового коду з використанням OOUI в проєктах Вікімедіа залишатиметься в межах X% у першому кварталі. | |
| PES1.4.3 | Якщо ми зіставимо власність, використовуючи запропонований каталог послуг для відомих сервісів, що належать нам, у першому кварталі, ми зможемо виявити значні прогалини в каталозі послуг, оскільки це допоможе вирішити проблему культури SLO, кінець року. | |
| PES1.5.1 | Якщо ми завершимо та опублікуємо чернетку SLO перевірки редагування, потренуємося впроваджувати його в регулярні робочі процеси та рішення, а також розробимо проєкт SLO Citoid, ми продовжимо вчитися, як разом визначати та відстежувати SLO, що взаємодіють з користувачами та між командами. | |
| PES1.5.2 | Якщо ми уточнимо та визначимо в письмовій формі документ із набором ролей та обов'язків зацікавлених сторін протягом життєвого циклу сервісу, це дозволить командам брати на себе обґрунтовані зобов'язання в каталозі сервісів, включаючи SLO. | |
Третій квартал
Третій квартал (Q3) річного плану ФВМ охоплює січень-березень.
| Гіпотези Вікідосвіду (ВД) | ||
|---|---|---|
| Акронім гіпотези | Текст третього кварталу | Деталі і обговорення |
| WE1.1.3 | Якщо ми порадимось із 20-ма організаторами заходів і 20-ма організаторами Вікіпроєктів про найкраще використання тем, доступних через LiftWing, то ми можемо встановити пріоритети змін до тематичної моделі, яка покращить актуальні зв'язки між подіями і Вікіпроєктами. | |
| WE1.1.5 | Якщо ми впровадимо принаймні 2 методи для пошуку Списку співпраці, то збільшимо кількість переглядів сторінок Списку співпраці, тим самим дозволивши більшій кількості людей знаходити події та Вікіпроєкти, які їх цікавлять. | |
| WE1.1.6 | If we identify and then contact 20 affiliates and/or groups connected to wikis that have high organizer activity in Q2, we can build advocacy networks that will set the stage for the extension being enabled on 3 more wikis by the end of Q3. | |
| WE1.1.7 | Якщо ми додамо принаймні 2 покращення до Списку співпраці для подій, то принаймні 50% опитаних респондентів вважатимуть Список співпраці кориснішим для пошуку подій, ніж до внесення змін. | |
| WE1.2.5 | Якщо ми проведемо A/B/C-тестування з прототипом запропонованих редагувань alt-тексту в робочій версії додатка для iOS, ми зможемо дізнатися, чи успішно справляються новачки з додаванням alt-тексту до зображень, і зрештою вирішити, чи достатньо воно ефективне для впровадження як запропонованого редагування в Інтернеті та/або в додатках. | |
| WE1.2.7 | If we deploy the Multi-Check sidebar (desktop) at all wikis where the Reference Check is available, we will unlock our ability to present multiple Edit Checks within a new "mid-edit" moment without negatively impacting the quality of new content edits newcomers publish. | |
| WE1.2.9 | Якщо ми запропонуємо структуроване завдання «Додати посилання» новим власникам облікових записів, які читають статті Вікіпедії, за допомогою A/B-тестування на пілотних вікі-сайтах, то очікуємо, що відсоток цих людей, які конструктивно активуються на мобільних пристроях, збільшиться на 10% порівняно з контрольною групою. | |
| WE1.2.10 | Якщо команда структурованого контенту покращить стан коду конвеєра даних пропозицій зображень на рівні статті, щоб відповідати 90% дедуплікація коду, розділення пропозицій зображень на рівні статей та розділів на рівні індексу; та адаптувати інструмент оцінки пропозицій зображень, щоб мати змогу отримувати базові показники якості пропозицій для цільових вікі, після чого завдання «Додати зображення» може бути випущено для новачків на додаткових Вікіпедіях. Це дозволить команді Growth реалізувати подальшу гіпотезу, спрямовану на збільшення конструктивної активації щонайменше в 10 додаткових Вікіпедіях. | |
| WE1.2.11 | Якщо ми випустимо структуроване завдання «Додати посилання» щонайменше для 5% новачків англійської Вікіпедії, то новачки з доступом до цього структурованого завдання продемонструють рівень конструктивної активації на мобільних пристроях, який на 10% вищий за базовий рівень, виміряний за допомогою A/B-тестування. | |
| WE1.3.3 | Якщо ми покращимо користувацький досвід та функції розширення Nuke протягом другого кварталу, ми збільшимо задоволеність адміністраторів продуктом на 5 відсоткових пунктів до кінця кварталу. | |
| WE1.3.4 | Якщо ми покращимо користувацький досвід та функції «Нещодавніх змін», ми збільшимо задоволеність адміністраторів продуктом на 5 відсоткових пунктів. | |
| WE1.5.1 | Якщо ми створимо короткий опис стратегії до лютого 2025 року, включаючи пріоритетну стратегію та компроміси, ми зможемо використовувати його як один з основних вхідних даних для APP25/26. | |
| WE1.5.2 | Якщо ми розробимо єдину стратегію вимірювання, ми дозволимо оцінити багаторічну стратегію продукту для учасників та задамо основу для визначення пріоритетів наступних кроків у метриці. розробка та звітність | |
| WE2.1.5 | If we expose topic-based translation suggestions more broadly and analyze its initial impact, we will learn which aspects of the translation funnel to act on in order to obtain more quality translations. | |
| WE2.1.6 | Якщо ми запропонуємо створення списків як послугу, ми дозволимо щонайменше 5 спільнотам робити більш цілеспрямований внесок у свої тематичні області, що вимірюється (1) зміною стандартної якості висвітлення відповідних тем у відповідній вікі та (2) коротким опитуванням щодо задоволеності організаторів висвітленням тематичної області у вікі. | |
| WE2.1.7 | «Якщо ми розробимо перевірку концепції, яка додасть завдання перекладу, отримані з WikiProjects та інших ініціатив зі створення списків, і представимо їх як пропозиції в рамках мобільного робочого процесу CX, тоді більше редакторів виявлятимуть та перекладатимуть статті, зосереджені на тематичних прогалинах.
Запровадивши опцію, яка дозволяє редакторам вибирати пропозиції перекладу на основі тематичних списків, ми перевіримо, чи збільшує цей підхід охоплення контенту в наших проєктах. |
|
| WE2.2.4 | Якщо ми задокументуємо шляхи до інкубатора, інкубатора та після інкубатора для п'яти пілотних вікі з кількісними та якісними даними, ми зможемо краще підтримувати нові мови в майбутньому. | |
| WE2.4.4 | Якщо ми розробимо живу перевірку концепції, використовуючи конвеєр асинхронної обробки контенту MediaWiki, для першого випадку використання Wikifunctions у Вікіпедії, ми будемо готові до…» Увімкніть це в новому році для спільноти Dagbani. | |
| WE2.6.1 | Якщо ми поширимо інтеграцію Wikifunctions з Test2Wiki на невелику виробничу Вікіпедію з MVP-інтерфейсом, ми побачимо, що ця функція використовуватиметься органічно без скасування. | |
| WE2.6.2 | Якщо ми зробимо можливим переклад речень у Wikifunctions з чогось «абстрактного», наприклад, функції, ми побачимо органічне збільшення щонайменше на 5 багатомовних функцій, які генерують речення природною мовою. Це важлива віха на шляху до створення абстрактної Вікіпедії. | |
| WE3.1.6 | Якщо ми впровадимо персоналізовану функцію «кролячої нори» в додатку для Android і рекомендуватимемо скорочені версії статей на основі типів тем і розділів, які цікавлять користувача, ми дізнаємося, чи є функція достатньо «закріпленою», щоб призвести до багатоденного використання 10% користувачів, які брали участь в експерименті протягом 30-денного періоду, і вищого рівня переглядів сторінок, ніж користувачі, які не мали доступу до цієї функції. | |
| WE3.1.8 | (2-3 квартал, веб) Якщо ми створимо одну функцію, яка надає додаткові рекомендації на рівні статті, ми побачимо збільшення коефіцієнта кліків на 10% порівняно з існуючими варіантами рекомендацій та значне збільшення зовнішніх рекомендації для користувачів, які активно взаємодіють з новою функцією. | |
| WE3.1.9 | Якщо ми створимо в додатку для Android вікторину на основі Вікіпедії для щоденного використання, то читачі, які не ввійшли в систему та взаємодіють з цією функцією, відкриватимуть додаток кілька днів протягом 20-денного періоду щонайменше на 5% частіше, ніж ті, хто не взаємодіє з цією функцією. | |
| WE3.1.10 | Якщо ми розробимо та протестуємо прототипи дизайну для перегляду з вкладками в додатку Вікіпедія для iOS, ми отримаємо та впровадимо практичні висновки щодо зручності використання, а також дозволимо інженерам оцінити технічну доцільність різних підходів, створивши міцну основу для додавання вкладок до додатка в четвертому кварталі. | |
| WE3.1.11 | Якщо ми зробимо рядок пошуку статей більш помітним, ми збільшимо кількість користувачів, які ініціюють пошук, на 8%, що, можливо, призведе до збільшення рівня утримання пошуку для користувачів, які не ввійшли в систему, на 1%. | |
| WE3.2.3 | Якщо зробити кнопку "Зробити пожертву" в iOS-версії більш виразною, наблизивши її на один клік або менше від головного навігаційного екрану, ми дізнаємося, чи пошукова простота була перешкодою для небанерних пожертв. | |
| WE3.2.4 | Якщо ми оновимо сторінку внесків для зареєстрованих користувачів у додатку, щоб включити активний значок для того, хто є донором додатка, та відобразити неактивний стан із запрошенням зробити пожертву для того, хто вирішив не робити пожертву в додатку, ми дізнаємося, чи є це визнання цінним для поточних донорів та заохочує до пожертвувань для потенційних донорів, інформуючи, чи варто розширювати концепцію значків донорів чи відмовитися від неї. | |
| WE3.2.7 | Збільшення Високий рівень точок входу для пожертвувань у мобільній та настільній версіях Minerva без входу в систему збільшить коефіцієнт кліків за посиланням для пожертвування на 30% у порівнянні з минулим роком. | |
| WE3.2.8 | Якщо ми покращимо персоналізований та колективний контент огляду року для iOS-додатків та масштабуватимемо його доступність, ми дізнаємося, чи є це ефективним методом збору коштів. | |
| WE3.4.1 | Якби ми дослідили доцільність, провівши експеримент зі створення менших точок доступу (PoP) у хмарних провайдерів, таких як Amazon, ми могли б розширити карту наших центрів обробки даних та охопити більше користувачів по всьому світу за меншими витратами та збільшеним часом виконання. | |
| WE3.5.1 | Якщо ми зробимо можливим категоризацію сторінок простору імен Commons Data та відображення їх використання в різних вікі, адміністратори Commons матимуть мінімальні інструменти, необхідні для управління збільшеним використанням простору імен Data, що гарантуватиме стале масштабування розгортання в усіх вікі. | |
| WE3.5.2 | Якщо ми покращимо тестове покриття та документацію для Charts, нам буде зручно передати технічне обслуговування та розробку майбутніх функцій [інженерам-читачам, підрядникам та волонтерам], що дозволить нам згорнути проект та робочу групу. | |
| WE3.5.3 | Якщо ми заповнимо список бажань спільноти функціями Charts, про які, як ми знаємо, просили волонтери, але які виходять за рамки MVP, з'явиться центральне місце для волонтерів та персоналу, де вони зможуть обговорювати майбутню роботу, пов'язану з Charts, що дозволить майбутнім розробникам керувати очікуваннями та отримувати інформацію для щорічного планування. | |
| WE4.1.3 | Якщо ми розгорнемо Систему звітності про інциденти MVP ще на x вікі (репрезентативна вибірка), ми зможемо зібрати цінні дані, які допоможуть нам виявити закономірності шкідливої поведінки у вікі. | |
| WE4.1.4 | Якщо ми залучимо зацікавлені сторони з ключових відділів до структурованих обговорень, ми зможемо спільно визначити спільне бачення та реалістичні рамки для Системи звітності про інциденти, узгоджені з пріоритетами організації та вимогами до дотримання нормативних вимог, що забезпечить цінну інформацію для інформування про річне планування. | |
| WE4.2.11a | Якщо ми визначимо термінологію та пороги для оцінок ризику повернення в різних вікі, ми зробимо можливим використання оцінок ризику повернення в ширшому діапазоні інструментів боротьби з зловживаннями, з якими стикаються користувачі. Ця гіпотеза впливає на WE4.2 KR, виконуючи необхідну підготовчу роботу для побудови оцінок ризику повернення. | |
| WE4.2.20 | Впровадити пробне впровадження, яке збиратиме дані про ефективність нової CAPTCHA на активованих вікі у запобіганні створенню облікових записів sockpuppet та спам-редагуванням на основі ботів, щоб виміряти ефективність та цінність впровадження нової технології у виробничому середовищі. | |
| WE4.2.15 | Якщо ми проаналізуємо атрибути заблокованих облікових записів користувачів на кількох вікі, ми визначимо закономірності в цих облікових записах та призначимо ваги на основі відносної важливості кожного атрибута для коефіцієнтів блокування, які будуть використані для розрахунку оцінки репутації облікового запису користувача. Успіх цієї гіпотези буде вимірюватися тим, чи нам вдасться визначити формулу для множення атрибутів облікового запису, щоб отримати оцінку репутації облікового запису, яка відповідає заблокованим користувачам. | |
| WE4.2.10 | Якщо ми додамо ще дві точки даних до конвеєра збору підказок клієнта, ми матимемо більше ентропії для кращої ідентифікації sockpuppet та потенційного ухилення від банів. Ми знатимемо, що досягли успіху, коли зможемо використовувати дані підказок клієнта для ідентифікації X% підтверджених sockpuppets на en:Wikipedia:Sockpuppet investigations. Або коли ми зможемо використовувати зібрані дані для ідентифікації Y% пари підозрюваних у вторгненні в заборону. Ця гіпотеза безпосередньо сприяє KR, надаючи нові сигнали (відбиток полотна браузера, список шрифтів), які дозволять CheckUsers точніше таргетувати sockpuppets та облікові записи, що намагаються обійти заборони. | |
| WE4.2.14b | «Якщо ми введемо змінні даних про репутацію IP-адреси у змінні AbuseFilter, ми забезпечимо пом’якшення наслідків, які можуть зменшити кількість повідомлень про вандалізм, спам та зловживання.
Контекст: Це безпосередньо сприяє досягненню мети KR, вводячи новий сигнал (репутацію IP-адреси), що дозволяє точніше пом’якшувати наслідки (впливають лише дії, що відповідають змінній). Ми могли б виміряти вплив цієї гіпотези, дослідивши обсяг скасованих редагувань у вікі до/після введення змінних. (Інші ідеї?) Спочатку ми б ввели такі змінні, як «ймовірно, це VPN» або «ймовірно, це проксі». Ми також могли б розглянути можливість надання інших змінних, залежно від обговорень у T354599: Зробіть репутацію IP-адреси доступною як змінну в AbuseFilter». |
|
| WE4.2.14a | Якщо ми проаналізуємо дані про репутацію IP, пов'язані з проблемною активністю редагування та обліковими записами користувачів, ми зможемо визначити пріоритети набору аспектів репутації IP, які можна буде надати як змінні в AbuseFilter. Цей аналіз потім буде використано WE4.2.14b пізніше в третьому кварталі для створення змінних в AbuseFilter, а також конкретних рекомендацій щодо того, які заходи пом'якшення було б доцільно використовувати разом із заданим набором змінних репутації IP. Наприклад, рекомендованим пом'якшенням для однієї змінної репутації IP може бути повне блокування редагувань, тоді як рекомендованим пом'якшенням для іншої змінної репутації IP може бути тег редагування для подальшого перегляду або показ CAPTCHA. | |
| WE4.2.18a | Якщо ми розробимо та створимо інтерактивний компонент для відображення публічних даних, пов'язаних з репутацією облікового запису користувача, для функціонарів, ми зможемо дізнатися, чи це корисно для них, спостерігаючи за кількістю повторних використань інструменту. | |
| WE4.3.3b | Якщо ми розгорнемо експериментальне випробування балансувальника навантаження «Liberica», ми виміряємо покращення нашої здатності обробляти TCP SYN-флуди на 33%. | |
| WE 4.3.6b | Якщо ми інтегруємо вихідні дані моделей, які ми створили в WE 4.3.1, з динамічними порогами обмежень паралельності на IP-адресу, які ми створили для наших термінаторів TLS у WE 4.3.2, ми повинні мати змогу збільшити нашу здатність автоматично нейтралізувати атаки на 20% більшим обсягом, виміряним за допомогою системи моделювання, яку ми створюємо. | |
| WE 4.3.8 | Якщо ми розгорнемо балансувальники навантаження liberica у всіх центрах обробки даних, ми збільшимо здатність обробляти TCP SYN-флуди на 33% скрізь. | |
| WE 4.3.9 | Якщо ми встановимо та будемо дотримуватися перевіреної процедури для регулярного тестування масштабних сценаріїв зловживань, то ми будемо постійно вимірювати та покращувати нашу здатність ефективно реагувати на такі інциденти. | |
| WE 4.3.10 | Якщо ми визначимо політику перегляду та підтримки правил requestctl, ми збережемо систему зрозумілою та керованою з часом. | |
| WE 4.3.11 | Якщо ми зможемо виявити закономірності та відокремити веб-скрапінг від загального трафіку, ми зможемо систематично створювати звіти для зменшення трафіку та підтримки стійкості нашої обслуговуючої інфраструктури. | |
| WE 4.4.3 | Якщо ми покращимо інтерфейс... У додатку для iOS ми зможемо чітко повідомити користувачам, як працюють тимчасові облікові записи, коли вони редагують без входу в систему, а додаток для iOS буде готовий до швидкого випуску тимчасових облікових записів для всіх проєктів. | |
| WE 4.4.4 | Якщо ми оновимо моделі даних в озері даних та відповідні конвеєри даних і панелі інструментів, щоб точно відображати нові типи облікових записів користувачів, ми зможемо надавати точну аналітичну звітність, пов'язану з діяльністю відповідних типів користувачів. | |
| WE 4.4.5 | Якщо ми вирішимо всі залишки проблем, пов'язаних з продуктом, дизайном та юридичними проблемами, для інженерної роботи, яку необхідно виконати до розгортання основних пілотних проєктів, ми зможемо вчасно завершити інженерну роботу для наступного раунду пілотного розгортання. | |
| WE5.1.9 | Якщо ми ввімкнемо Parsoid в Incubator та всі новостворені вікі до другого кварталу, ми додатково забезпечимо стійкість, не дозволивши зростати кількості вікі, які працюють на застарілому парсері. Ми будемо вимірювати успіх цього розгортання за допомогою детальних оцінок за допомогою звітів Confidence Framework, з особливим акцентом на звіти Visual Diff та показники, пов'язані з продуктивністю та зручністю використання. Крім того, ми оцінимо скорочення списку потенційних перешкод, забезпечуючи вирішення критичних проблем перед ширшим розгортанням. | |
| WE5.1.11 | Команда Observability прагне завершити підтримку Graphite, увімкнувши режим лише для читання та вимкнувши завантаження нових метрик до кінця третього кварталу 2024/2025 фінансового року. Для досягнення цієї мети команда встановила ціль охоплення 90% конвертуючи решту панелі інструментів та вилучаючи застарілі метрики та панелі, що вказують на метрики Graphite. | |
| WE5.1.12 | Якщо ми випустимо інтерактивну пісочницю документації для REST API MediaWiki, вона запровадить повторюваний шаблон для документації API з низьким рівнем обслуговування та високою якістю, одночасно полегшуючи впровадження API для розробників у всьому світі. Це гарантуватиме повне оновлення, тестування та локалізацію нашої документації API для поколінь розробників, одночасно знижуючи витрати на обслуговування та підвищуючи стійкість для видавців API. | |
| WE5.1.13 | Якщо ми розгорнемо SUL3 для всіх існуючих облікових записів та створення нових облікових записів у всіх вікі, ми забезпечимо сумісність із заходами захисту від відстеження браузера та покращимо безпеку, перемістивши автентифікацію на спеціальний домен, який вимагає взаємодії з користувачем та додатково запобігає вразливостям XSS. | |
| WE5.2.5 | Якщо ми змоделюємо принаймні ще одну зміну стану сторінки (наприклад, PageDelete) як подію PHP та сприятимемо подальшому впровадженню подій домену в процесі в компонентах та розширеннях MediaWiki, які зараз використовують подієподібні перехоплювачі, тоді ми зміцнимо довіру до подій як шаблону стійкості платформи, покращуючи межі компонентів, підвищуючи гнучкість інтерфейсу та зменшуючи шаблонний код високого ризику. | |
| WE5.2.6 | Якщо ми дослідимо розробку архітектури для серіалізації та трансляції подій, що генеруються в ядрі MediaWiki, ми створимо основу для надання першокласної підтримки подій, яка дозволить нам споживати події поза вихідним процесом MediaWiki PHP (наприклад, JobQueue, EventBus). Це зробить дані MediaWiki більш придатними для повторного використання поза межами платформи MediaWiki. | |
| WE5.2.7 | Якщо ми визначимо та узгодимо набір доменів, які можна використовувати для подій платформи MediaWiki, до кінця третього кварталу ми матимемо початкову карту меж основних компонентів і зможемо покращити узгодженість між інтерфейсами MediaWiki, використовуючи ті самі домени для модулів REST API MediaWiki. | |
| WE5.2.8 | Якщо ми чітко визначимо концепцію інтерфейсів розширення в документації MediaWiki, ми зможемо спростити розробку нових функцій поверх MediaWiki та забезпечити чіткіший шлях для визначення нових інтерфейсів розширення, таких як події доменів. Ми виміряємо це, визначивши місця в документації, де інтерфейси розширення представлені як «типи розширень», і замінивши 100% цих екземплярів. | |
| WE5.4.3 | Якщо ми надамо розробникам образи та інфраструктуру MediaWiki PHP8.1 для тестування їх на Kubernetes, вони зможуть перевірити та сертифікувати їх для розгортання у продакшені. Якщо ми також розробимо інфраструктуру для прогресивної міграції трафіку та використовуватимемо її для безпечної міграції продакшену до версії 8.1, це допоможе MediaWiki відмовитися від непідтримуваних версій PHP у майбутньому травневому випуску. Успіх буде спостерігатися завдяки можливості збільшити виробничий трафік до екземплярів PHP 8.1. | |
| WE5.4.4 | Якщо ми відокремимо процеси застарілих дампів від їхніх поточних хостів на голому залізі та натомість запустимо їх як робочі навантаження на кластері DSE Kubernetes, це принесе помітну користь для підтримки цих конвеєрів даних та полегшить оновлення PHP до версії 8.1 за допомогою спільних контейнерів mediawiki. | |
| WE5.4.6 | Якщо бета-кластер буде налаштовано для запуску MediaWiki з PHP 8.1, то група розробки платформи даних та їхня команда SRE зможуть перевірити, чи існуючий код дампів працює правильно, чи потрібні будь-які суттєві функціональні зміни. | |
| WE5.5.1 | Якщо до кінця січня ми зможемо вимірювати та контролювати трафік дампів, розміщених у Вікімедіа, за допомогою даних журналів, ми матимемо ясність щодо того, як користувачі використовують різні параметри форматування дампів та точки доступу. Це розблокує додаткові показники загального споживання в усіх потоках та покращить наше розуміння того, що цікавить користувачів з точки зору актуальності, завершення даних та структури, щоб ми могли відповідно адаптувати загальну стратегію API. | |
| WE5.5.2 | Якщо до кінця третього кварталу ми створимо консолідований огляд персон розробників та варіантів використання, зібраних під час туру прослуховування та дослідження, то ми виявимо менш вивчені прогалини та можливості в цій сфері. Це дозволить використати існуючу роботу, виконану командами зацікавлених сторін у відповідних сферах (наприклад: дампи, WME), а також створити нові аналітичні дані шляхом проведення інтерв'ю зі співробітниками WMF, технічними волонтерами та партнерами з повторного використання контенту з високим впливом (наприклад: клієнтами та потенційними клієнтами WME). | |
| WE6.1.7 | Якщо ми переглянемо відгуки користувачів, визначимося з рішенням для пошуку та перегляду коду, розгорнемо його у виробничій інфраструктурі як офіційно підтримувану послугу та забезпечимо індексацію як існуючих, так і нових репозиторіїв з обох систем відстеження коду, ми збільшимо обсяг коду, який індексується та доступний для пошуку, і спростимо процес пошуку коду в повсякденній роботі, а також під час реагування на інциденти. | |
| WE6.1.8 | Якщо ми проаналізуємо показники метрик документації з нашого тестового набору даних, ми зможемо оцінити корисність та ефективність проєктів метрик, зібрати відгуки та надати практичну інформацію для впровадження автоматизованого обчислення метрик. | |
| WE6.1.9 | Якщо ми передамо 5 додаткових груп доступу під управління в системі управління ідентифікацією, це покращить управління доступом, підвищивши ефективність, значно зменшивши навантаження та покращивши досвід адаптації для нових співробітників Вікімедіа та нових членів технічних спільнот. | |
| WE6.2.2 | Якщо ми замінимо бекенд-інфраструктуру наших існуючих спільних середовищ розробки та тестування MediaWiki (з віртуальних серверів Apache на Kubernetes), це дозволить нам розширити її використання, забезпечивши сервіси MediaWiki на додаток до існуючої можливості розробки ядра MediaWiki, розширень та... шкури в ізольованому середовищі. Ми розробимо одне середовище, що включає MediaWiki, одне або декілька розширень та одну або декілька служб. | |
| WE6.2.3 | Якщо ми створимо новий інтерфейс користувача розгортання, який надаватиме веб-інтерфейс для розгортань, відкритий для існуючих розгортачів, це дозволить розробникам зворотних портів мати спільний огляд поточних розгортань та забезпечить кращу видимість для них. | |
| WE6.2.5 | Якщо ми опублікуємо плановий документ для виведення маршрутизації однієї версії з MediaWiki та зберемо коментарі зацікавлених сторін щодо впровадження, то ми зменшимо тертя під час впровадження. | |
| WE6.2.6 | If we gather feedback from QTE, SRE, and individuals with domain specific knowledge and use their feedback to write a design document for deploying and using the wmf/next OCI container, then we will reduce friction during when we start deploying that container. | |
| WE6.2.7 | Якщо ми зробимо веб-інтерфейс користувача розгортання доступним за нашою системою єдиного входу та відкриємо його для спільноти розробників Wikimedia, це збільшить кількість розробників зворотних портів. | |
| WE6.2.8 | Продовжуючи можливості Catalyst щодо надання тестових середовищ перед злиттям MediaWiki та її розширень і скінів на Kubernetes, якщо ми сприятимемо розгортанню патчів перед злиттям для служб MediaWiki, запускаючи тести перед злиттям для Wikifunctions, тоді учасники зможуть тестувати більше проєктів MediaWiki зі стабільними, чітко визначеними, ізольованими тестовими середовищами. | |
| WE6.2.9 | Якщо ми Тестуючи запропоновану реалізацію маршрутизації MediaWiki з однією вікі, ми доведемо, що план працює, і зможемо прискорено розгортати його на інших вікі, а також зможемо направити контейнер однієї версії до інфраструктури хостингу вікі Вікімедіа. | |
| WE6.3.7 | Встановивши детальні критерії вимірювання та рекомендації щодо розвитку нашої системи сталого розвитку, ми створимо дієву систему оцінювання для покращення платформи. | |
| WE6.3.8 | Залучення потенційних користувачів для вивчення раннього прототипу дизайну Toolforge UI допоможе нам виявити можливості для покращення та ризики, які необхідно врахувати в наступній ітерації. | |
| Гіпотези щодо сервісів сигналів і даних (SDS) | ||
|---|---|---|
| Акронім гіпотези | Текст третього кварталу | Деталі і обговорення |
| SDS1.1.1 | Якщо ми співпрацюємо з власником ініціативи та оцінюємо вплив його роботи на показники Core Foundation, ми можемо визначити та соціалізувати повторюваний механізм, за допомогою якого команди у Foundation можуть надійно впливати на показники Core Foundation. | |
| SDS1.1.2 | Якщо ми оцінимо вплив нового південноамериканського центру обробки даних (MAGRU) на нашу метрику релевантності (унікальні пристрої), ми зможемо створити звіт, який надасть уявлення про рентабельність інвестицій поточних та майбутніх інвестицій у центри обробки даних. | |
| SDS1.3.1.B | Якщо ми інтегруємо конектор Spark / DataHub для всіх виробничих завдань Spark, ми отримаємо походження на рівні стовпців для всіх завдань платформи даних на основі Spark у DataHub. | |
| SDS1.3.2.B | Якщо ми реалізуємо часто використовувану роботу щодо запиту даних історії MariaDB MW на основі Spark, узгодимо відсутні елементи і збагатимо їх, ми надаватимемо щодня оновлювану таблицю даних про історію вікітексту MW. | |
| Гіпотези Майбутніх цільових груп (МЦГ) | ||
|---|---|---|
| Акронім гіпотези | Текст третього кварталу | Деталі і обговорення |
| FA1.1.1 | Якщо ми проведемо в позаплатформний дуже низькозатратний експеримент із застосуванням ШІ “Add a Fact”, ми можемо дізнатися, чи позаплатформні користувачі можуть допомогти зростанню/підтримці збереження знань у можливому майбутньому, де контент Вікіпедії переважно споживається поза платформою. | |
| Product and Engineering Support (PES) Hypotheses | ||
|---|---|---|
| Акронім гіпотези | Текст третього кварталу | Деталі і обговорення |
| PES1.1.2 | Якщо ми виберемо три основні напрямки, у яких збільшити зусилля, спрямовані на поліпшення нашої культури рецензування, і спілкуватися про них на правильних каналах, ми побачимо поліпшення у відгуках на ітеративний розвиток, прийняття рішень та співпрацю в наступному дослідженні культури (січня 2025 року). | |
| PES1.1.3 | Якщо ми надішлемо переглянуте опитування щодо культури, ми визначимо галузі, де ми можемо надати підтримку менеджерам, щоб продовжити зміцнювати нашу культуру патрулювання. | |
| PES1.3.5 | Якщо ми створимо гру на основі Вікіпедії для щоденного використання, яка підкреслює зв'язки в широких областях знань, це заохотить споживачів регулярно відвідувати Вікіпедію і сприятиме активному навчанню, що призведе до збільшення взаємодії з контентом на Вікіпедії і довших сеансів використання. | |
| PES1.3.6 | Якщо ми застосуємо уроки з першого Sprinthackular до другого заходу, спрямованого на поліпшення інструментів і процесів прототипування, принаймні один проєкт Sprinthackular покаже достатньо цінності і шансів щодо його інтеграції в АПП. Ми також зможемо розробити повторну систему Sprinthackular, яку інші команди визнають придатною для вивчення будь-якої фокусної зони. | |
| PES1.5.1 | (Розпочинаючи з 1 жовтня) Якщо ми завершимо і опублікуємо проєкт SLO Edit Check, практикуючи його включення в регулярні робочі процеси і рішення, а також розробимо SLO Citoid, ми продовжимо вчитися, як визначити і відстежувати спільні SLO для користувачів та команд. | |
| PES1.5.2 | (Починаючи з 1 жовтня) Якщо ми уточнимо і письмово подамо документ з набором ролей і обов'язків зацікавлених сторін протягом усього життєвого циклу послуг, це дозволить командам зробити свідомі зобов'язання в каталозі послуг, включаючи їхні SLO. | |
Четверти квартал
Останній квартал (4-й квартал) річного плану WMF охоплює квітень-червень.
| Гіпотези Вікідосвіду (ВД) | ||
|---|---|---|
| Акронім гіпотези | Текст четвертого кварталу | Деталі і обговорення |
| WE1.2.9 | Якщо ми запропонуємо структуроване завдання «Додати посилання» новим власникам облікових записів, які читають статті Вікіпедії, за допомогою A/B-тестування на пілотних вікі-сайтах, то очікуємо, що відсоток цих людей, які конструктивно активуються на мобільних пристроях, збільшиться на 10% порівняно з контрольною групою. | |
| WE1.2.12 | Якщо ми покажемо кілька перевірок довідок протягом сеансу редагування новачкам, які беруть участь в A/B-тестуванні, ми дізнаємося, чи ця зміна в перевірці... Сеанс корисного навантаження/редагування призводить до бажаних змін у якості редагування та завершенні редагування. | |
| WE1.2.13 | Якщо ми проведемо тести зручності використання початкової спроєктованої версії Peacock Check з ≥10 новачками та молодшими учасниками, і ≥80% з них описуватимуть досвід, використовуючи такі терміни, як «корисний», «має сенс» та «зрозумілий», тоді ми можемо бути впевнені, що запропонований UX має потенціал знизити швидкість, з якою нові редагування контенту скасовуються на підставі WP:WTW (та пов'язаних політик). | |
| WE1.2.14 | Якщо ми створимо модель, яка може виявляти мову «павичів» у поточних редагуваннях з точністю 90% та затримкою виведення Y, тоді ми зможемо забезпечити редагування, яке не повністю залежить від модераторів-людей для виявлення мови «павичів» у щойно опублікованих редагуваннях. | |
| WE1.3.4 | Якщо ми покращимо користувацький досвід та функції Останніх змін, ми підвищимо задоволеність адміністраторів продуктом на 5 відсоткових пунктів. | |
| WE1.3.6 | Якщо ми покращимо користувацький досвід та функції Списку спостереження, ми підвищимо задоволеність патрульних продуктом на 5 відсоткових пунктів. | |
| WE1.4.1 | Якщо ми розробимо план випуску... Розширення CampaignEvents буде випущено пакетами, залежно від регіональних цільових груп, до середини четвертого кварталу щонайменше для 10 вікі-проєктів. | |
| WE1.4.3 | Якщо ми розширимо способи доступу людей до реєстрації подій у вікі, то ми зможемо диверсифікувати базу користувачів розширення CampaignEvents, що вимірюється принаймні X співпрацями з недостатньо представленої аудиторії (наприклад,: диски з відставанням, конкурси письменників та події, організовані WikiProjects) за допомогою реєстрації подій до кінця четвертого кварталу. | |
| WE1.5.2 | Якщо ми розробимо єдину стратегію вимірювання, ми дозволимо оцінити багаторічну стратегію продукту для учасників та створимо умови для визначення пріоритетів наступних кроків у розробці та звітності метрик. | |
| WE1.6.1 | Якщо ми запровадимо можливість для волонтерів додавати шаблони до обраного, то щонайменше 1000 учасників додадуть 1 шаблон до обраного. | |
| WE2.5.2 | Якщо ми зробимо Колекції та Тематичні фільтри легшими для перекладачів на комп'ютерах та мобільних пристроях, більше користувачів знайдуть ці пропозиції, що призведе до збільшення публікації перекладів, запропонованих за допомогою цих фільтрів. | |
| WE2.5.3 | Якщо ми визначимо майбутні перекладацькі кампанії у третьому та четвертому кварталах, надамо організаторам підтримку у формуванні списків, де це необхідно, та зробимо списки видимими в Колекціях в інструменті перекладу контенту, ми збільшимо кількість високоякісних опублікованих статей, які вирішують тематичні прогалини. | |
| WE2.6.1 | Якщо ми поширимо інтеграцію Wikifunctions з Test2Wiki на невелику виробничу Вікіпедію з інтерфейсом MVP, ми побачимо, що функція, яка використовується органічно без скасування. | |
| WE2.6.2 | Якщо ми зробимо можливим переклад речень у Wikifunctions з чогось «абстрактного», як-от функція, ми побачимо органічне збільшення щонайменше на 5 багатомовних функцій, які генерують речення природною мовою. Це важлива віха на шляху до створення абстрактної Вікіпедії. | |
| WE2.6.3 | Якщо команда Content Transform вирішить завдання підтримки вікітексту, необхідні для використання вікіфункцій на крос-вікі сторінках Вікіпедії, це розблокує роботу команди абстрактної Вікіпедії з інтеграції вікіфункцій у Вікіпедії малою мовою. | |
| WE2.6.4 | Якщо ми встановимо та досягнемо стандартів продуктивності, ми можемо бути впевнені, що розгортання доступу Вікіфункцій до більшої кількості вікі не порушить досвід цих вікі чи роботу колег. | |
| WE2.6.5 | Якщо ми розгорнемо доступ Вікіфункцій до більшої кількості вікі Вікімедіа, ми побачимо ширше використання для доставки контенту та дізнаємося, наскільки добре він працює з різними мовами та спільнотами для усунення прогалин у контенті. | |
| WE2.7.2 | Якщо 3000 добре описаних зображень південноамериканських та/або африканських видів будуть опубліковані для ширшої спільноти біорізноманіття через 2-3 заходи редагування та робочий список вікі, 300 нових зображень будуть використані в іспанських, французьких та португальських проєктах Вікімедіа. | |
| WE3.1.9 | Якщо ми створимо в додатку для Android вікторину на основі Вікіпедії для щоденного використання, то читачі, які не ввійшли в систему та взаємодіють з цією функцією, відкриватимуть додаток кілька днів протягом 20-денного періоду щонайменше на 5% частіше, ніж ті, хто не взаємодіє з цією функцією. | |
| WE3.1.12 | Якщо ми впровадимо функцію попередньо згенерованого резюме як функцію підписки на мобільному сайті виробничої вікі, ми… мати змогу виміряти CTR понад 4%, гарантувати відсутність негативного впливу на тривалість сеансу, перегляди сторінок або внутрішні перенаправлення, а також використовувати ці дані, щоб вирішити, як і чи будемо ми далі масштабувати функцію зведення. | |
| WE 3.1.13 | Якщо ми підійдемо до розробки модерації зведення спільно зі спільнотами — через опитування та інші обговорення у вікі, ми зможемо визначити мінімальний життєздатний робочий процес модерації, необхідний для початкового масштабування функції, та уточнити, чи має модерація бути керованою спільнотою, автоматизованою (на рівні запиту) чи якоюсь комбінацією обох. | |
| WE3.1.14 | Якщо ми масштабуємо щоденну вікторину на основі Вікіпедії в додатку для Android, читачі, які не ввійшли в систему та завершили гру, відкриватимуть додаток кілька днів на 5% частіше, ніж ті, хто не отримує рекламної акції на гру, і тому не гратимуть у неї. | |
| WE3.1.15 | Якщо ми впровадимо персоналізовані списки для читання в додатку для Android та рекомендуватимемо статті на основі статей, які цікавлять користувачів, ми побачимо 5% збільшення утримання функції списку для читання. | |
| WE3.1.16 | Якщо ми розмістимо ідеальну версію функції WikiPodcasting та функцію перетворення тексту в мовлення Wiki на Android перед... Користувачі, вони повідомлятимуть, що неодноразово використовували б функцію WikiPodcasting, але не використовували б неякісну версію перетворення тексту в мовлення, окрім потреб доступності. | |
| WE3.2.7 | Підвищення помітності точок входу для пожертвувань у мобільних та настільних версіях Minerva без виходу з системи збільшить коефіцієнт кліків за посиланням для пожертвування на 30% у річному обчисленні. | |
| WE3.4.1 | Якби ми дослідили доцільність, провівши експеримент зі створення менших точок доступу (PoP) у хмарних провайдерів, таких як Amazon, ми могли б розширити карту наших центрів обробки даних та охопити більше користувачів по всьому світу за меншими витратами та збільшеним часом виконання. | |
| WE3.5.2 | Якщо ми вирішимо основні проблеми форматування та відображення діаграм, що виникли під час пілотної фази вікі, ми будемо впевнені в масштабуванні розгортання на більшу кількість вікі до кінця третього кварталу. | |
| WE3.5.3 | Якщо ми впровадимо рішення для фільтрації наборів даних, що використовуються для створення діаграм за допомогою Lua, волонтери матимуть гнучкість, необхідну для задоволення більшості своїх потреб в управлінні даними, і будуть задоволені станом MVP, коли проєкт завершиться в четвертому кварталі. | |
| WE3.5.4 | Якщо ми покращимо тестове покриття та документацію для Charts, нам буде зручно передати технічне обслуговування та розробку майбутніх функцій [інженерам-читачам, підрядникам та волонтерам], що дозволить нам згорнути проект та робочу групу. | |
| WE3.5.5 | Якщо ми заповнимо список бажань спільноти функціями Charts, про які, як ми знаємо, просили волонтери, але які виходять за рамки MVP, з'явиться центральне місце для волонтерів та персоналу, де вони зможуть обговорювати майбутню роботу, пов'язану з Charts, що дозволить майбутнім розробникам керувати очікуваннями та отримувати інформацію для щорічного планування. | |
| WE4.1.3 | Якщо ми розгорнемо Систему звітності про інциденти MVP ще на x вікі (репрезентативна вибірка), ми зможемо зібрати цінні дані, які допоможуть нам виявити закономірності шкідливої поведінки у вікі. | |
| WE4.1.4 | Якщо ми залучимо зацікавлені сторони з ключових відділів до структурованих обговорень, ми зможемо спільно визначити спільне бачення та реалістичні рамки для Системи звітності про інциденти, узгоджені з пріоритетами організації та вимогами до дотримання нормативних вимог, що забезпечить цінну інформацію для інформування про річне планування. | |
| WE4.1.5 | Якщо ми створимо панель інструментів для моніторингу ключових показників, ми зможемо оцінити, як люди використовують систему та які типи інцидентів повідомляються, що допоможе нам приймати рішення щодо можливих контрзаходів у четвертому кварталі. | |
| WE4.2.11a | Якщо ми визначимо термінологію та пороги ризику повернення оцінки у вікі, ми зробимо можливим використання оцінок ризику повернення в ширшому спектрі інструментів боротьби з зловживаннями, з якими стикаються користувачі. Ця гіпотеза впливає на ключовий критерій WE4.2, виконуючи необхідну підготовчу роботу для побудови оцінок ризику повернення. | |
| WE4.2.14a | Якщо ми проаналізуємо дані про репутацію IP-адрес, пов’язані з проблемною активністю редагування та обліковими записами користувачів, ми зможемо визначити пріоритет набору аспектів репутації IP-адрес, які можна буде надати як змінні в AbuseFilter. Цей аналіз потім буде використано у WE4.2.14b пізніше, у третьому кварталі, для побудови змінних у AbuseFilter, а також конкретних рекомендацій щодо того, які заходи пом’якшення було б доцільно використовувати разом із заданим набором змінних репутації IP-адрес. Наприклад, рекомендованим пом’якшенням для однієї змінної репутації IP-адреси може бути повне блокування редагувань, тоді як рекомендованим пом’якшенням для іншої змінної репутації IP-адреси може бути позначка редагування для подальшого перегляду або показ CAPTCHA. | |
| WE4.2.14b | «Якщо ми введемо змінні даних про репутацію IP-адреси у змінні AbuseFilter, ми забезпечимо пом’якшення наслідків, які можуть зменшити кількість повідомлень про вандалізм, спам та зловживання.
Контекст: Це безпосередньо сприяє досягненню мети KR, вводячи новий сигнал (репутацію IP-адреси), що дозволяє точніше пом’якшувати наслідки (впливають лише дії, що відповідають змінній). Ми могли б виміряти вплив цієї гіпотези, дослідивши обсяг скасованих редагувань у вікі до/після введення змінних. (Інші ідеї?) Спочатку ми б ввели такі змінні, як «ймовірно, це VPN» або «ймовірно, це проксі». Ми також могли б розглянути можливість надання інших змінних, залежно від обговорень у T354599: Зробіть репутацію IP-адреси доступною як змінну в AbuseFilter». |
|
| WE4.2.15 | Якщо ми проаналізуємо атрибути заблокованих облікових записів користувачів у кількох вікі, ми визначимо закономірності в цих облікових записах і призначимо ваги на основі відносної важливості кожного атрибута для коефіцієнтів блокування, щоб використовувати їх для розрахунку оцінки репутації облікового запису користувача. Успіх цієї гіпотези буде вимірюватися тим, чи нам вдасться визначити формулу для множення атрибутів облікового запису, щоб отримати оцінку репутації облікового запису, яка відповідає заблокованим користувачам. | |
| WE4.2.18 | Якщо ми розробимо та створимо інтерактивний компонент для відображення публічних даних, пов'язаних з репутацією облікового запису користувача, ми зможемо дізнатися, чи це корисно для них, спостерігаючи за кількістю повторних використань інструменту. | |
| WE 4.2.20 | Впровадимо пробне впровадження, яке збиратиме дані про ефективність нової CAPTCHA на ввімкнених вікі у запобіганні створенню облікових записів sockpuppet та редагуванню спаму на основі ботів, щоб виміряти ефективність та цінність впровадження нової технології у виробничу середу. | |
| WE4.3.3b | Якщо ми розгорнемо експериментальне випробування балансувальника навантаження «Liberica», ми виміряємо покращення нашої здатності обробляти TCP SYN-флуди на 33%. | |
| WE4.3.6b | Якщо ми інтегруємо результати моделей, які ми створили в WE 4.3.1, з динамічними порогами обмежень паралельності на IP-адресу, які ми створили для наших термінаторів TLS у WE 4.3.2, ми повинні мати змогу збільшити нашу здатність автоматично нейтралізувати атаки на 20% більше, виміряно за допомогою структури моделювання, яку ми створюємо. | |
| WE4.3.8 | Якщо ми розгорнемо балансувальники навантаження liberica у всіх центрах обробки даних, ми збільшить можливості обробки TCP SYN-флудів на 33% повсюди | |
| WE4.3.9 | Якщо ми встановимо та дотримуватимемося перевіреної процедури для регулярного тестування масштабних сценаріїв зловживань, то ми будемо постійно вимірювати та покращувати нашу здатність ефективно реагувати на такі інциденти. | |
| WE4.3.10 | Якщо ми визначимо політику перегляду та підтримки правил requestctl, ми збережемо систему зрозумілою та керованою з часом. | |
| WE4.3.11 | Якщо ми зможемо створити алгоритм для шаблонів веб-запитів наших журналів, ми зможемо розрізняти різні моделі поведінки користувачів. Ми зможемо вручну запускати аналіз для створення txt-файлів для перегляду можливих шаблонів парсингу, які є дороговартісними для фонду. | |
| WE4.4.3 | Якщо ми покращимо інтерфейс додатка для iOS, ми зможемо чітко повідомити користувачам, як працюють тимчасові облікові записи, коли вони редагують без входу в систему, і додаток для iOS буде готовий до швидкого випуску тимчасових облікових записів для всіх проєктів. | |
| WE4.4.4 | Якщо ми оновимо моделі даних в озері даних та відповідні конвеєри даних та панелі інструментів, щоб точно відображати нові типи облікових записів користувачів, ми зможемо надавати точну аналітичну звітність, пов'язану з діяльністю відповідних типів користувачів. | |
| WE4.4.5 | Якщо ми вирішимо всі залишки проблем, пов'язаних з продуктом, дизайном та правом, для інженерної роботи, яку необхідно виконати до розгортання основних пілотних проєктів, ми зможемо вчасно завершити інженерну роботу для наступного раунду розгортання пілотних проєктів. | |
| WE5.1.11 | Команда Observability прагне завершити підтримку Graphite, увімкнувши режим лише для читання та вимкнувши завантаження нових показників до кінця третього кварталу 2024/2025 фінансового року. Для досягнення цієї мети команда встановила ціль охоплення 90% конвертувавши решту панелі інструментів та вилучивши застарілі показники та панелі, що вказують на показники Graphite. | |
| WE5.2.11 | Якщо ми завершимо новий інтерфейс для сповіщень у ядрі MediaWiki, ми зможемо відмовитися від існуючих інтерфейсів, що використовуються Echo, та перейти до більш сталої розробки функцій сповіщень, перемістивши розширення до інтерфейсу, який є простішим та більш роз'єднаним. | |
| WE5.2.12 | Ми ефективно продемонструємо сталу схему подій домену, якщо завершимо моделювання, впровадження та впровадження внутрішньопроцесних подій домену PHP для всіх змін стану сторінки (оновлення, видалення, переміщення, створення, відновлення, захист, видимість) та задокументуємо заплановані наступні кроки для досягнення довгострокової цінності цієї роботи. | |
| WE5.2.13 | Якщо ми оновимо розширення EventBus для використання внутрішньопроцесних подій PHP для змін стану сторінки та проведемо початкове дослідження для перевірки можливості впровадження довготривалого слухача PHP Kafka, ми продемонструємо, що події домену є життєздатним варіантом як для трансляції, так і для споживання подій для випадків використання поза межами MediaWiki. | |
| WE5.4.4 | Якщо ми відокремимо процеси застарілих дампів від їхніх поточних хостів на голому металі та натомість запустимо їх як робочі навантаження на кластері DSE Kubernetes, це принесе помітну користь для підтримки цих конвеєрів даних та полегшить оновлення PHP до версії 8.1 за допомогою спільних контейнерів mediawiki. | |
| WE5.4.7 | Якщо ми використовуватимемо нещодавно розроблену та протестовану інфраструктуру для поступового повного розгортання PHP8.1 у продакшн, це допоможе MediaWiki відмовитися від непідтримуваних версій PHP у майбутньому травневому випуску. | |
| WE5.5.2 | Якщо до кінця травня ми створимо консолідований огляд персон розробників та варіантів використання, зібраних під час туру прослуховування та дослідження, то ми виявимо менш вивчені прогалини та можливості в цій сфері. Це дозволить використати існуючу роботу, виконану командами зацікавлених сторін у відповідних сферах (наприклад: Дампи, WME), а також створити нові ідеї шляхом проведення інтерв'ю зі співробітниками WMF, технічними волонтерами та партнерами з повторного використання контенту з високим впливом (наприклад, клієнтами та потенційними клієнтами WME). | |
| WE6.1.7 | Якщо ми переглянемо відгуки користувачів, визначимося з рішенням для пошуку та перегляду коду, розгорнемо його у виробничій інфраструктурі як офіційно підтримувану послугу та забезпечимо індексацію як існуючих, так і нових репозиторіїв з обох систем відстеження коду, ми збільшимо обсяг коду, який індексується та доступний для пошуку, та спростимо процес пошуку коду в повсякденних операціях, а також під час реагування на інциденти. | |
| WE6.1.10 | Якщо ми опублікуємо машинозчитуваний список репозиторіїв, розгорнутих WMF, який відповідає схемі Bitergia, та підтримуватимемо його через CI/CD, ми зменшимо накладні витрати на обслуговування, забезпечимо точність даних та забезпечимо ефективну фільтрацію даних репозиторіїв на наших інформаційних панелях розробника, що дозволить нам систематично відповідати на два запитання. | |
| WE6.2.7 | Якщо ми зробимо веб-інтерфейс розгортання доступним за нашою системою єдиного входу та відкриємо його для спільноти розробників Wikimedia, це збільшить кількість зворотних портів. розгортачі. | |
| WE6.2.8 | Продовжуючи можливості Catalyst щодо надання тестових середовищ перед злиттям MediaWiki та її розширень і скінів на Kubernetes, якщо ми полегшимо розгортання патчів перед злиттям для сервісів MediaWiki, запускаючи тести перед злиттям для Wikifunctions, тоді учасники зможуть тестувати більше проєктів MediaWiki зі стабільними, чітко визначеними, ізольованими тестовими середовищами. | |
| WE6.3.7 | Встановивши детальні критерії вимірювання та рекомендації щодо розвитку нашої системи сталого розвитку, ми створимо дієву систему оцінювання для покращення платформи. | |
| Гіпотези щодо сервісів сигналів і даних (SDS) | ||
|---|---|---|
| Акронім гіпотези | Текст третього кварталу | Деталі і обговорення |
| SDS1.1.1 | Якщо ми співпрацюємо з власником ініціативи та оцінюємо вплив його роботи на показники Core Foundation, ми можемо визначити та соціалізувати повторюваний механізм, за допомогою якого команди у Foundation можуть надійно впливати на показники Core Foundation. | |
| SDS1.1.2 | Якщо ми оцінимо вплив нового південноамериканського центру обробки даних (MAGRU) на нашу метрику релевантності (унікальні пристрої), ми зможемо створити звіт, який надасть уявлення про рентабельність інвестицій поточних та майбутніх інвестицій у центри обробки даних. | |
| SDS1.4.1 | Якщо команда DPE підтримає міграцію конвеєра метрик прогалин у знаннях до нової таблиці wmf_content.mediawiki_content_history_v1, пришвидшивши вирішення проблем блокування, тоді ми зможемо довести корисність цієї нової таблиці, а також покращити надійність прогалин у знаннях. конвеєр. | |
| SD1.4.2 | Дослідницька група запровадить wmf_content.mediawiki_content_history_v1 у всіх існуючих випадках використання, в яких вони наразі використовують застарілий wmf.mediawiki_wikitext_history. | |
| SDS1.4.3 | Якщо ми надамо щоденно оновлювану таблицю wmf_content.mediawiki_content_current_v1 в озері даних, яка включає вміст поточної редакції для всіх сторінок усіх вікі, ми спростимо роботу з інтеграції та зменшимо обчислювальні ресурси, необхідні для споживачів, які цікавляться лише останнім станом. | |
| SDS1.4.4 | Якщо ми запровадимо нову таблицю озера даних wmf_content.mediawiki_content_history_v1 для створення пропозицій зображень, то конвеєри даних IS будуть стабільнішими. | |
| SDS2.4.3 | Якщо ми підготуємося до взаємодії зі зовнішньою спільнотою, ми зможемо залучити зацікавлених сторін, структурувати наратив, щоб уточнити, чого ми хочемо досягти, та створити план проєкту для продуктивної взаємодії зі спільнотою, який визначатиме, чи будемо ми схвалювати розгортання унікальних файлів cookie для користувачів, які не ввійшли в систему, у майбутньому. | |
| SDS2.4.4 | Якщо ми успішно впровадимо та розгорнемо файли cookie Edge Uniques у нашій виробничій CDN, ми матимемо основу на основі яких можна реалізувати надійне A/B-тестування для анонімних читачів. | |
| SDS2.4.7 | Якщо ми оновимо клієнтські бібліотеки Javascript та PHP Експериментальної платформи для обробки даних реєстрації в експерименті для користувачів, які не ввійшли в систему, ми зможемо ввімкнути A/B-тестування на анонімних користувачах. | |
| SDS2.4.8 | Якщо ми змінимо EventGate для прийняття даних реєстрації в експерименті та відмовимося від збору користувацьких агентів, ми зможемо ввімкнути збір даних для A/B-тестування, а команди зможуть знизити рівень ризику збору даних. | |
| SDS2.4.9 | Якщо хешовані версії хеш-значень унікальних файлів cookie на периферії можна буде генерувати, передавати та перевіряти як стійкі до колізій, тоді стане можливим використовувати їх для аналізу експериментів, використовуючи як поточні спеціалізовані методи, так і Growthbook. | |
| SDS2.4.10 | Якщо ми створимо API Experiment Manager у MediaWiki, ми зможемо стандартизувати конфігурацію експерименту та збір даних. | |
| SDS2.4.11 | Якщо ми проведемо принаймні одне наскрізне A/A-тестування на анонімних користувачах за допомогою Edge Uniques (див. SDS 2.4.4), ми можемо перевірити наш алгоритм вибірки реєстрації в експерименті (SDS 2.4.9) у співпраці з Edge Uniques та точність нашого збору даних. | |
| SDS2.4.13 | Якщо ми зробимо інтерфейс користувача Experimentation Lab сумісним з технічною інфраструктурою, яка підтримує експерименти з анонімними користувачами, ми дозволимо власникам експериментів проводити A/B-тестування з трафіком, що не ввійшов у систему, та перевіряти нову функціональність від початку до кінця, використовуючи нашу платформу MVP. | |
| SDS2.4.16 | Якщо ми створимо панель інструментів Superset для звітування про результати експерименту на основі показників взаємодії (не фандрейзингу) з плану вимірювання (SDS 2.4.14), команда розробників продукту матиме швидкий та готовий доступ до початкових даних, щойно дані стануть доступними в нашому озері даних – та повних даних невдовзі після завершення A/B-тестування – без залежності від спеціаліста з даних (аналітика продукту). | |
| Гіпотези Майбутніх цільових груп (МЦГ) | ||
|---|---|---|
| Акронім гіпотези | Текст третього кварталу | Деталі і обговорення |
| FA1.1.2 | Чи можемо ми охопити менш залучену молодшу аудиторію, реміксуючи контент Вікіпедії, курований спільнотою, у короткі відео та публікуючи його на популярних платформах коротких відео? | |
| FA1.1.3 | Чи може бот Discord допомогти нам дізнатися, чи хочуть люди взаємодіяти з розмовною Вікіпедією на базі штучного інтелекту поза платформою, і допомогти нам охопити/збільшити залученість до Вікіпедії серед молодшої аудиторії? | |
| FA1.1.4 | Якщо ми створимо новий досвід Вікіпедії на Roblox, ми дізнаємося, чи може це бути ефективним способом представити наш бренд молодшій (покоління Альфа) аудиторії. | |
| Product and Engineering Support (PES) Hypotheses | ||
|---|---|---|
| Акронім гіпотези | Q1 текст | Деталі і обговорення |
| PES1.1.2 | Якщо ми оберемо три основні сфери, в яких ми висвітлимо зусилля, що докладаються для покращення нашої культури рецензування, та повідомимо про них у правильних каналах, ми побачимо покращення у відповідях на ітеративну розробку, прийняття рішень та співпрацю в наступному опитуванні культури (січень 2025 р.). | |
| PES1.3.5 | Якщо ми створимо гру на основі Вікіпедії для щоденного використання, яка підкреслює зв'язки між широкими галузями знань, це заохочуватиме споживачів регулярно відвідувати Вікіпедію та сприятиме активному навчанню, що призведе до посилення взаємодії з контентом у Вікіпедії та збільшення тривалості сеансів. | |
| PES1.5.3 | Якщо ми контекстуалізуємо актуальність документа «Ролі та обов'язки» та «Каталог послуг» для аудиторії вищого керівництва, пов'язавши цінність цих інструментів зі стратегічними цілями відділу, тоді ми будемо готові надати керівництву ретельний короткий опис рішень для розгляду. Рішення, викладені в брифі рішення, визначатимуть, чи маємо ми необхідну основу для відстеження, звітності та прийняття рішень за допомогою SLO як стандартної та масштабованої практики. | |
| PES1.5.4 | Якщо ми розробимо SLO для Експериментальної лабораторії та потренуємося інтегрувати SLO EditCheck та Citoid у регулярні робочі процеси та рішення, ми розширимо наше розуміння міжкомандних SLO, застосовуючи цей підхід до проєктів на нових етапах їхнього організаційного життєвого циклу. | |
| PES1.7.1 | Якщо ми дослідимо, як слід обробляти побажання (внутрішньо та зовні), то ми зможемо зібрати практичні висновки для доповнення списку бажань у короткостроковій перспективі та надати довгострокові рекомендації щодо потреб списку бажань для обслуговування внутрішніх зацікавлених сторін. | |
| PES1.7.2 | Якщо ми розробимо бриф рішення щодо довгострокової підтримки програмного забезпечення списку бажань, включаючи інформацію з дослідження зацікавлених сторін та відгуки консультантів зі списку бажань, ми зможемо вибрати конкретний підхід, який відповідає потребам наших користувачів. | |
| PES1.7.3 | Якщо хтось знаходиться між побажаннями та консультантами зі списку бажань, ми можемо ефективно повідомляти відповіді волонтерам, де «ефективним» є повідомлення «чому» рішень, а наслідки — ні. викликати негативний хвильовий ефект у настроях громади. | |
| PES1.7.4 | Якщо ми проведемо Маямі бажань, то отримаємо щонайменше 20 латок із бажаннями під час заходу, які підкажуть нам, чи підходять ці бажання для роботи. | |
Пояснення кошиків
Вікідосвід
Метою цього кошика є ефективне надання, покращення та впровадження інновацій у забезпечення вікідосвіду, що дозволяє поширювати вільні знання по всьому світу. Цей кошик відповідає рекомендаціям стратегії руху №2 (Покращуйте досвід користування) та №3 (Забезпечте безпеку та інклюзію). Наші аудиторії включають всіх, хто спільно працює на наших вебсайтах, а також читачів та інших споживачів вільних знань. Ми підтримуємо сайт, що входить в топ-10 світових вебсайтів і багато інших важливих вільних культурних ресурсів. Ці системи мають вимоги до продуктивності та часу безвідмовної роботи на рівні з вимогами найбільших технологічних компаній у світі. Ми надаємо користувацькі інтерфейси для вікі, переклад, API розробників (і багато іншого!), а також допоміжні застосунки та інфраструктуру, які всі разом утворюють надійну платформу для співпраці волонтерів для створення вільних знань у всьому світі. Наші цілі для цього кошика повинні дозволити нам удосконалити нашу основну технологію та можливості, забезпечити постійне покращення нами досвіду редакторів-волонтерів і модераторів наших проєктів, покращити досвід усіх технічних вкладників, які працюють над покращенням або розширенням такого вікідосвіду і забезпечити найкращі враження для читачів і споживачів вільних знань у всьому світі. Ми зробимо це за допомогою роботи над продуктом і технологією, а також за допомогою досліджень і маркетингу. Ми очікуємо, що будемо мати щонайбільше п'ять цілей для цього кошика.
Знання створюються людьми! І тому наш річний план буде зосереджений на вмісті, а також на людях, які його створюють, і на тих, хто має до нього доступ і читає його.
Наша мета — розробити операційний план на основі наявної стратегії, головним чином, наших гіпотез про «маховик» дописувача, споживача та вмісту. Основна зміна, про яку я прошу, — це акцент на тій частині маховика, яка стосується вмісту, і дослідження того, що наші модератори й функціонери можуть потребувати від нас зараз, з метою визначення показників стану спільноти в майбутньому.
Сервіси сигналів і даних
Щоб відповідати рекомендаціям Стратегії руху щодо Забезпечення справедливості у прийнятті рішень (Рекомендація №4), Покращення досвіду користування (Рекомендація №2) та Оцінювання, ітерації та адаптації (Рекомендація №10), особи, які приймають рішення у всьому русі Вікімедіа, повинні мати доступ до надійних, релевантних та своєчасних даних, моделей, інсайтів та інструментів, які можуть допомогти їм оцінити вплив (як реалізований, так і потенційний) їхньої роботи та роботи їхніх спільнот, що дасть їм змогу ухвалювати кращі стратегічні рішення.
У кошику «Сервіси сигналів і даних» ми виділили чотири основні аудиторії: співробітників Фонду Вікімедіа, афіліатів і груп користувачів Вікімедіа, розробників, які повторно використовують наш вміст, і дослідників Вікімедіа, а також ми визначаємо пріоритети й задовольняємо потреби цих аудиторій у даних і відомостях. Наша робота охоплюватиме низку видів діяльності: визначення прогалин, розробку показників, побудова потоків для обчислення показників, а також розробка шляхів дослідження даних і сигналів, які допомагають особам, які приймають рішення, ефективніше та з задоволенням взаємодіяти з даними та інсайтами.
Майбутні аудиторії
.svg)
Метою цього кошика є дослідження стратегій розширення за межі наших наявних цільових груп споживачів і дописувачів, щоб, як необхідна інфраструктура екосистеми вільних знань, справді охопити кожного у світі. Цей кошик відповідає Рекомендації №9 Стратегії Руху (Впроваджуйте інновації у вільних знаннях). Люди все більше і більше споживають інформацію в інтерфейсах і формах, які відрізняються від нашої традиційної пропозиції вебсайту зі статтями — люди користуються голосовими помічниками, проводять час з відео, взаємодіють зі штучним інтелектом і т.д. У цьому кошику ми запропонуємо і перевіримо гіпотези щодо потенційного довгострокового майбутнього екосистеми вільних знань і того, як ми будемо її необхідною інфраструктурою. Ми робитимемо це через роботу над продуктом та технологією, а також через дослідження, партнерства та маркетинг. У міру того, як ми визначатимемо перспективні майбутні стани, уроки з цього кошика впливатимуть і розширюватимуться через кошики №1 і №2 у наступних річних планах, підштовхуючи наші продуктові та технологічні пропозиції туди, де вони повинні бути, щоб служити шукачам знань майбутнього. Наші цілі для цього кошика повинні спонукати нас до експериментів та досліджень, оскільки ми зосереджуємось на баченні майбутнього вільних знань.
Менші кошики
У нас також є два інші «менші кошики», які складаються з областей критично важливих функцій, які повинні існувати у Фонді для підтримки наших основних операцій, і щодо деяких з них ми маємо спільні риси з будь-якою організацією, що має справу з програмним забезпеченням. Ці «менші кошики» не матимуть власних цілей вищого рівня, але будуть робити внесок у досягнення цілей вищого рівня інших груп і підтримувати їх. Вони такі:
- Базова інфраструктура. До цього кошика належать команди, які підтримують та розвивають наші центри обробки даних, обчислювальні платформи та платформи зберігання даних, сервіси для їх експлуатації, інструменти та процеси, які забезпечують роботу наших загальнодоступних сайтів та сервісів.
- Продуктова та інженерна підтримка. До цього кошика належать команди, які працюють «масштабно», надаючи послуги іншим командам, що підвищує продуктивність та покращує роботу цих інших команд.