Jump to content

Годовой план Фонда Викимедиа/2025-2026/Цели и ключевые результаты Отдела по продуктам и технологиям

Add links
From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs and the translation is 59% complete.
Outdated translations are marked like this.
Other languages:
Wikimedia Foundation Annual Plan 2025–2026

На предстоящий год

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

Интернет быстро меняется. Новые поколения получают информацию посредством видео в соцсетях и ИИ-услуг, и по сравнению с предыдущими группами меньшее количество людей осведомлено о Википедии. Мы наблюдаем связанный с этим спад в количестве людей, посещающих наши сайты, и количестве редакторов. Тем временем платформы на пространстве всего интернета фундаментально зависят от контента Викимедиа с точки зрения работы своих поисковых и ИИ-продуктов. Эта динамика является серьезным вызовом, но она ясно показывает, почему надежные и свободные знания, создаваемые общими усилиями, очень важны. Мир нуждается в источнике достоверной, проверяемой человеком информации как никогда раньше, а проекты Викимедиа продолжают доказывать, что они могут ее предоставить.

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

Инфраструктурная цель заключается в том, как платформа и пользовательская среда будут способствовать решению этих вопросов и охвату большинства участников движения. Это не просто список проектов, а ряд направлений для подпитки роста числа волонтеров, для придания волонтерам возможностей в плане создания достоверного энциклопедического наполнения, для финансирования нашей миссии и развития того, что мы предлагаем, чтобы формировать изменяющийся интернет. Вы можете прочитать более подробно об этих четырех стратегических столпах.

Стимулирование роста количества волонтеров

Сообщество волонтеров ‒ это уникальный двигатель, определяющий успех проектов Викимедиа, и нам требуется, чтобы оно оставалось здоровым и развивающимся. Однако в предыдущем году мы наблюдали на проектах спад в количестве новых и возвращающихся редакторов. Чтобы лучше понять и более эффективно удовлетворить потребности существующих волонтеров, Фонд преобразовал Список пожеланий сообщества из ежегодного опроса в постоянно активный процесс, в рамках которого потребности пользователей и идеи проектов могут служить основой для работы многочисленных команд Фонда. Мы сгруппировали пожелания в "Приоритетные области" и внесли три из них в раздел ключевых результатов годового плана. Мы также запустили пилотный вариант Наблюдательного совета по продуктам и технологиям, чтобы дополнить многочисленные обсуждения, которые проводят команды Фонда с членами сообщества как в рамках вики-проектов, так и за их пределами в течение года. Кроме того, мы выявили возможности для привлечения новых поколений на наши проекты, например принимая во внимание тот факт, что молодые люди охотно взаимодействуют на других социальных онлайн-пространствах, где у них есть простые и адаптированные для мобильных устройств способы общения по интересующим их темам.

В предстоящем году мы будем поддерживать рост числа волонтеров, облегчая само участие и делая его более привлекательным путем развития мобильно-ориентированных, новых способов редактирования ("структурные задачи") и добавления интеллектуальных рабочих процессов, которые облегчают полезное редактирование с мобильных устройств для новых участников ("проверка правок"). Чтобы глубже увлечь и сохранить существующих волонтеров, мы предложим рекомендуемые действия и задачи, а также разместим их в едином центре, который упростит организацию деятельности на вики-проектах. Мы будем обдуманно применять ИИ для поддержки волонтеров в их работе, всегда сохраняя человеческий контроль и уделяя особое внимание прозрачности. Как для новых, так и для опытных волонтеров мы создадим возможности для взаимодействия и совместной работы на наших сайтах, черпая вдохновение в успешных кампаниях и вики-проектах, что позволит им находить редакторов со схожими взглядами и повышать качество интересующего их контента (в соответствии с этой приоритетной областью Списка пожеланий).

Обеспечение достоверного энциклопедического наполнения

По мере роста созданных при помощи ИИ материалов, миру требуется достоверный энциклопедический контент как никогда раньше. Мы хотим расширить возможности волонтеров в области создания нового контента, обеспечения надежности существующего и предоставления достоверного наполнения новому поколению читателей с новыми потребностями и предпочтениями.

Чтобы помочь волонтерам создавать новое наполнение, мы будем опираться на существующие инструменты и рабочие процессы (такие как инструмент языкового перевода), чтобы большие и малые сообщества в равной степени могли работать с важным контентом. Чтобы обеспечить достоверность существующего наполнения, мы поможем опытным волонтерам более эффективно управлять своей растущей нагрузкой путем развития инструментов, используемых ими для поиска требующих внимания задач. Это облегчит им обновление статей и отмену неконструктивных правок (в соответствии с данной приоритетной областью Списка пожеланий).

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

Чтобы контент был доступен новым поколениям, мы внедрим такие функции, как помощь новым видам читателей в понимании статей, помощь в поиске интересующей их информации и обеспечение их активного участия по мере чтения. Эти изменения задуманы для поощрения того, чтобы новые читатели Википедии стали преданными пользователями, а некоторые из них ‒ жертвователями (в соответствии с этой приоритетной областью списка пожеланий).

Обеспечение достоверного наполнения также означает поддержку модели “знание как услуга”, где вся совокупность интернета опирается на контент Викимедиа. В этой модели наша инфраструктура является не только ценным ресурсом для посещающих наш вебсайт людей, но также и для компаний, предоставляющих поисковые и ИИ-услуги, которые автоматически используют наш контент в качестве основополагающей исходной информации для своих продуктов и результатов их работы. Компании такого типа являются лишь одним из немногих примеров использования, создающих чрезмерную нагрузку на нашу инфраструктуру. В течение предыдущего года значительный рост запросов, исходящих от инструментов извлечения информации и ботов, сделал вопрос корректировки этой тенденции более насущным. Нам необходимо создать устойчивые пути доступа к контенту для разработчиков и пользователей-посредников, чтобы люди были в приоритете перед ботами.

Финансирование будущей 'свободности'

Отдел продуктов и технологий играет важную роль в обеспечении устойчивости нашего движения. В следующем году мы установим тесные партнерские отношения с командой по сбору средств, чтобы опыт взаимодействия для наших жертвователей был более понятным и полезным. На наших сайтах и в мобильных приложениях мы добавим для читателей возможность выражения благодарности Википедии путем пожертвований, а также привнесем новые способы выражения признательности благотворителям, чтобы они продолжали делать взносы год за годом.

Формирование изменяющегося интернета

Чтобы свободные зания были доступны всем людям в мире, нам требуется взаимодействовать с ними там, где они находятся, при помощи способов, которые помогают им узнавать новое. Люди в возрастной категории 18-24 лет осведомлены о Википедии меньше и используют ее реже, чем предыдущие поколения. Они в основном взаимодействуют с видео-платформами, с заслуживающими доверия онлайн-персонами, платформами социальных игр и, все в большей степени, ИИ-приложениями, а также и получают оттуда новые знания. В этом году мы сделаем Википедию доступной для данных аудиторий в тех местах, где они проводят время в сети, чтобы они были осведомлены о Википедии как о источнике достоверных знаний, созданных людьми. Мы расширим наше присутствие на популярных видео-платформах, распространяя контент Википедии на этих полщадках и формируя там сообщество. Кроме того, мы исследуем идеи по привнесению знаний Википедии на игровые и социальные платформы.

Внутри инфраструктурной цели это подразделяется на три рабочих портфеля (называемых "корзинами"): Среда Вики (Вики-опыт), Сигналы и Сервисы данных, а также Аудитории будущего. Эти корзины остаются такими же, как и в прошлом и позапрошлом году.

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

Построение, усовершенствование и поддержка инфраструктуры для проектов и волонтеров Викимедиа с опорой на наши ценности

"Фонд будет размещать полезную информацию в рамках своих проектов в интернете и бессрочно обеспечивать ее безвозмездную доступность."

Команды продуктов и технологий уделяют постоянное, круглогодичное внимание построению, доработке и поддержке инфраструктуры, обслуживающей проекты Викимедиа. Мы инвестируем в хостинг проектов Викимедиа, разработку программного обеспечения и систем проектирования с открытым исходным кодом, а также управление и усовершенствование инфраструктуры для продуктов анализа данных и ИИ-моделей.

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

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

Чтобы предусмотреть доступность наших проектов и контента в интернете как в настоящий момент, так и на будущую перспективу, наши команды посвящают значительную часть своих усилий обеспечению высокой надежности наших сайтов и сервисов. Одним из аспектов этой работы является аварийное восстановление после катастрофических или вредоносных событий. Например, мы обеспечиваем наличие резервных копий важной информации и можем ее восстановить. Аналогично, два раза в год мы тестируем наши возможности по переключению наших сайтов между нашими дата-центрами в автоматическом режиме и устраняем любые обнаруженные проблемы. Другой аспект этой работы сфокусирован на обнаружении развивающихся тенденций, касающихся типа и объемов получаемого нами трафика, и адаптации к ним. Например, с учетом беспрецедентного роста автоматических скреперов (извлекателей данных), мы уделяем особое внимание работе по обеспечению того, что наши сайты и сервисы остаются доступными для пользователей-людей, применяя системный подход по установлению норм, касающихся ответственного использования нашей инфраструктуры.

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

Цели по продуктам и технологиям

Представленные здесь цели находятся на стадии разработки ‒ отзывы и обсуждения приветствуются.

  • Цели отражают направления общего характера на высоком уровне.
  • "Ключевые результаты" (КР) представляют собой способ количественного отслеживания достижения цели.
  • "Гипотезы", лежащие в основе каждого ключевого результата, представляют собой фактические работы, производимые нами с целью достижения соответствующих ключевых результатов. Они будут обновляться как в этом документе, так и на соответствующих страницах проектов и команд, по мере того как будет достигаться более глубокое понимание в течение года.
  • Символ wishlist item обозначает работы, которым дается приоритет в соответствии со списком пожеланий сообщества.

Среда Вики (WE)

Опыт участников (WE1)

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

Жизненно важные знания (WE2)

  • Цель: сделать больше жизненно важных знаний доступными и хорошо иллюстрированными, по разным темам и на разных языках. Обсудить
    • Контекст цели. Эта цель будет стимулировать рост объемов контента, который будет соответствовать как заинтересованности участников в определенных темах и языках, так и потребностям читателей в хорошо иллюстрированных жизненно важных знаниях. Жизненно важные знания ‒ это комплекс статей, обеспечивающих широту и глубину охвата тем, необходимых для пригодного к использованию языкового проекта Википедии. Они определяются сообществами с учетом известности, актуальности, прогнозируемой читательской аудитории и взаимосвязей между статьями.
    • Мы будем использовать социально-технический подход, повышая эффективность функций, инструментов и социальных процессов. Мы внедрим высокоэффективные функции продуктов, такие как предлагаемые задачи, медиа-поиск и языковой перевод контента, а также будем способствовать становлению и развитию малых языковых вики-проектов. Мы будем поддерживать организаторов Викимедиа, которые набирают, обучают и поддерживают участников в процессе совместной работы над общим наполнением при помощи структур взаимодействия, таких как Вики-проекты и кампании. (По нашим оценкам, по крайней мере 300 организаторов активны каждый квартал.) Мы также будем развивать отношения с наиболее значимыми издательствами, чтобы устранить барьеры для исходных материалов. (В настоящий момент у нас есть партнерские отношения с более чем 100 ведущими мировыми базами данных, доступными только по подписке.)
    • Чтобы убедиться в положительном эффекте от наших действий в отношении жизненно важных знаний, мы будем измерять как рост объемов контента, приоритетного для сообщества, так и качество этого контента, учитывая такие факторы, как частота откатов и количество цитат и изображений.
      • Ключевой результат WE2.1: внедрение и оценка до конца второго квартала трех модификаций, которые помогут участникам улучшить состояние жизненно важных знаний на своих вики-проектах.
        • В рамках данного ключевого результата будут выявлены пробелы в механизмах редактирования, таких как обнаружение изображений в Википедии, языковой перевод контента и контролируемое создание новых статей. Мы также внедрим и протестируем социально-технические новации для поддержки деятельности по созданию контента в малых языковых сообществах. Успех будет измеряться в рамках каждой гипотезы.
      • Ключевой результат WE2.2: К концу четвёртого квартала разработать платформенные возможности, необходимые для подтверждения нашей способности поддерживать реализацию видения Абстрактной Википедии на масштабном уровне. Мы будем считать, что достигли успеха, если сможем продемонстрировать, что система способна генерировать богатый, многоязычный энциклопедический контент с использованием Викиданных и генерации естественного языка, управляется сообществом Викимедиа и сохраняет производительность при масштабном развёртывании.
        • Теперь, когда мы можем использовать Викиданные для вывода базового текстового контента в Википедии, следующим шагом станет развитие платформенных возможностей для поддержки Абстрактной Википедии на масштабном уровне. Платформа должна обеспечивать создание богатого, многоязычного контента под управлением сообщества при сохранении производительности. Это ключевая веха, знаменующая переход от «0 к 1».
      • Ключевой результат WE2.3: К концу четвёртого квартала запустить начальную версию новой вики для раннего создания абстрактных статей сообществом.
        • Этот ключевой результат позволит нам протестировать возможности Абстрактной вики в следующем году. Новая, самостоятельная вики будет размещать библиотеку абстрактных статей, построенных на Викифункциях, и обеспечит платформенные возможности, необходимые для последующей интеграции абстрактных статей в Википедию.
      • Ключевой результат WE2.4: К концу второго квартала согласовать между Фондом Викимедиа и Викимедиа Германия определение успеха для улучшений технической инфраструктуры, поддерживающей критически важные сценарии использования Викиданных, включая определение метрик и целей на 2025–2026 финансовый год.
        • Команда Wikidata Platform (WDP) Фонда Викимедиа была сформирована и укомплектована (один руководитель продукта и один технический руководитель) в августе 2025 года. Как новая часть программы, развивавшейся годами усилиями технических и продуктовых команд Фонда Викимедиа и Викимедиа Германия, эта цель отражает наше намерение осуществить передачу ответственности через согласование сценариев использования, зависимостей и ключевых критериев успеха. Этот ключевой результат создаст основу для общего понимания проблемной области, на которой будет строиться дальнейшая работа в течение оставшегося финансового года (до мая 2026 года).
      • Key result WE2.5: By the end of Q4, our backend replacement has been stood up in parallel to Blazegraph and is capable of supporting the cutover of select users. We define “migration ready” for this KR as capable of supporting the pilot phase of our migration in Q1 of FY26-27.
        • Following the progress made towards defining the success criteria as a part of WE2.4, we are now shifting into execution mode. In the next two quarters, we will outline all of the variables associated with the Blazegraph cutover in a migration plan, determine which are critical for pilot launch, implement them in a new RDF database, and define the migration timeline for all requirements beyond our pilot personas. Our work between now and our target launch of a new WDQS backend (est. July 2026) will be guided by the requirements laid out in this plan.

Потребительский опыт (WE3)

  • Цель: читатели из многих поколений привлекаются к использованию Википедии и остаются приверженцами, что приводит к измеримому прогрессу в сохранении аудитории и росту пожертвований. Обсудить
    • Контекст цели. Данная цель будет сосредоточена на удержании новых читателей посредством инновационных форматов контента, удержании ключевой аудитории путем усовершенствования привычной читательской среды и обеспечении долгосрочной устойчивости путем углубления связей с читателями и диверсификации пожертвований. Это будет включать в себя продолжение нашей работы про облегчению поиска контента посредством новых и экспериментальных функций, таких как краткая ИИ-сводка и персонализированные "кроличьи норы". Кроме того, будет проводиться работа по сохранению и улучшению качества пользовательской среды на более глубоких уровнях "воронки чтения", а также работа по исследованию читательского кураторства посредством списков для чтения и другого не связанного с редактированием участия. Касательно жертвователей, будет продолжена работа по диверсификации источников дохода внутри платформы.
      • пункт списка пожеланий Ключевой результат WE3.1: демонстрация до конца второго квартала практически значимого роста в удержании незарегистрированных (вышедших из системы) читателей посредством А/Б-тестирования одной функции на каждой платформе.
        • Данный ключевой результат будет ориентирован на продолжение инвестиций в среду, которая позволит оптимизировать способы просмотра и изучения контента, преимущественно за счет использования новых технологий и форматов. Это позволит презентовать контент новыми и увлекательными способами. В этом финансовом году мы хотим продолжить наши эксперименты с новыми функциями, параллельно также уделяя внимание масштабированию успешных экспериментов на другие вики-проекты и платформы. Работа в рамках данного ключевого результата будет охватывать вебсайты для мобильных и настольных устройств, равно как и приложения для iOS и Android. Также внимание будет уделено обнаружению контента (точкам входа и рекомендациям) и адаптивным форматам обучения (машиногенерируемым сводкам, перефразированию контента).
        • Приоритетная область списка пожеланий: Обновленный потребительский опыт
      • Ключевой результат WE3.2: ежегодный рост на 5% на каждой платформе числа пожертвований, не связанных с баннерами или электронной почтой, посредством новаций в области продуктов, которые углубляют связи с жертвователями и снижают для них неудобства, до конца второго квартала.
        • В рамках данного ключевого результата мы продолжим исследование новых точек входа для пожертвований и других возможностей, позволяющих привлечь пользователей к пожертвованиям, а также и удержать их путем углубления их связи с вики-проектами, в том числе и путем персонализированного контента. Этот ключевой результат будет сосредоточен на внедрении новых и на пересмотре существующих точек входа в приложениях и на вебсайтах при сотрудничестве с командой сбора средств.
      • Ключевой результат WE3.3: демонстрация до конца второго квартала практически значимого роста в удержании зарегистрированных читателей посредством А/Б-тестирования одной функции на каждой платформе.
        • Этот ключевой результат будет сосредоточен на усовершенствовании среды чтения и обучения для существующих и опытных читателей с целью сохранения нашей текущей аудитории и углубления ее связи с сайтом, чтобы они могли изучать больше, а также были готовы и открыты для перехода к пожертвованиям и редактированию. Данная работа будет направлена на усовершенствование читательского опыта как на вебсайтах, так и в приложениях (повышение читаемости, улучшенная навигация и поиск), а также на создание и пересмотр наших текущих предложений по курированию и персонализации (списки для чтения, персонализированные рекомендации, история пользователя и история статей и т.д.)
      • Ключевой результат WE3.4: до конца четвёртого квартала устранить все выявленные препятствия для развёртывания небольших кэширующих узлов (PoP), которые соответствуют нашим текущим стандартам качества обслуживания и безопасности.
        • Данный ключевой результат будет направлен на обоснование концепции, согласно которой мы можем повысить производительность вебсайтов и уменьшить задержку для наших читателей, облегчая нашу инфраструктуру кэша и совершенствуя процессы развертывания кэширующих сайтов путем сокращения базового времени развертывания от в среднем одного года до максимум одного квартала. Основное внимание будет уделено завершению процесса снижения сложности, развертыванию PoC, проведению проверки безопасности и формированию краткой сводки для принятия решения о развертывании пограничных кэширующих элементов в публичных облачных сервисах. Результатом уменьшения задержки может стать доказанный рост числа просмотров страниц и более географически разнообразная база читателей.
      • Ключевой результат WE3.5: обеспечение до конца четвертого квартала улучшенной идентификации благотворителей, подразумевающей, что все согласные на это авторизованные читатели могут иметь статус спонсора для более персонализированного взаимодействия.
        • Мы внедрим стратегии идентификации жертвователей для обеспечения того, что все согласные на это авторизованные читатели могли бы иметь статус спонсора, дающий возможность получать более персональный и увлекательный опыт взаимодействия. В течение четвертого квартала, работам по идентификации благотворителей будет уделено особое внимание, чтобы поддержать более эффективные инициативы по персонализации и активации в будущем.
      • Ключевой результат WE3.6: до конца четвертого квартала доработать, опубликовать и распространить стратегию Викимедиа в области читательского и потребительского взаимодействия, с заданными целями и базовыми показателями, разработанными при сотрудничестве с заинтересованными сторонами и сообществом, чтобы направить нашу работу в перспективе до 2030 года.
        • Работа над потребительской стратегией будет продолжена, причем особое внимание будет уделено созданию и распространению стратегии как внутри, так и в рамках сообщества, а также определению и внедрению ключевых показателей для потребителей и их базовых значений.
      • Key result WE3.7: Increase the number of donations through non-banner or email methods by 10% YoY per platform through product interventions that foster deeper connections and reduce friction for donors by the end of Q4.
        • This KR will see us continue to explore new entry points for donation and other opportunities to convert readers into donors and retain them by deepening their connections to the wikis, including more personalized content. The KR will focus on introducing new entry points and iterating on existing entry points on apps and web, in collaboration with the fundraising team.
      • Key result WE3.8: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for active readers in a test environment, monitoring a guardrail appropriate for the feature.
        • This KR will focus on scaling features that showed promise in improving engaged reader retention (or related indicator metric) across web and apps, based on experiment results from Q1/Q2. This includes scaling of the reading list on web (to drive account creation and internal referral rate), activity tab on iOS (for account creation and retention), and a potential longer production analysis of activity tab on Android (already released) to validate feature retention improvements.
      • Key result WE3.9: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for logged-out casual readers in a test environment, monitoring a guardrail appropriate for the feature.
        • In this KR, we will scale successful experiments that have proven to provide a high value to readers, new and lapsed, who do not currently engage with wiki projects. We will scale improvements focused on logged-out reader experiences that support knowledge seeking- content discovery experiences, visual presentations and modalities for sharing (knowledge, content, topics of interest). This KR spans across mobile web and apps platforms (iOS and Android).
      • Key result WE3.10: By the end of Q4, perform at least one experiment per platform (web and apps) that shows a practically significant improvement in logged-out casual reader retention or another indicator metric over control (with casual reader retention defined as 21-day cumulative retention for web, and 14-day cumulative retention for apps).
        • We are continuing our investment in experiments that convey Wikipedia's value to readers, new and lapsed, who do not currently engage with wiki projects. We will look to test improvements to the logged-out reader experience focusing on content discovery (e.g., Minerva TOC, semantic search, Q&A), visual presentations (e.g., visually engaging link cards), and modalities for sharing (e.g., share action). This KR spans web (mobile and desktop, though with an emphasis on mobile due to the audience) and apps (iOS and Android).

Защита и безопасность (WE4)

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

Ответственное использование инфраструктуры (WE5)

  • Цель: разработчики и пользователи-посредники получают доступ к знаниям через заранее подобранные механизмы, что обеспечит устойчивость нашей инфраструктуры и ответственное переиспользование контента. Обсудить
    • Контекст цели. Данная цель будет сосредоточена на обеспечении механизмов ответственного переиспользования контента.
    • Викимедиа хранит самую большую коллекцию собранных человеком знаний в интернете. Это делает нашу инфраструктуру знаний бесценным местом назначения не только для людей, но и для автоматизированных потребителей данных. Наш контент наполняет поисковые системы, социальные медиа-платформы, электронную коммерцию, а с момента появления ИИ он используется для обучения больших языковых моделей. Потребители получают данные путем скрейпинга, через программные интерфейсы приложений (API) и просто путем скачивания контента ‒ часто без указания авторства. В потоке неавторизованного трафика мы не можем достоверно отличить одного пользователя от другого, и это существенно ограничивает наши возможности, чтобы инициировать и обеспечить ответственное использование нашей инфраструктуры. Как мы можем далее поддерживать наше сообщество, одновременно внося ограничения, касающиеся автоматизированного потребления контента? Как мы можем направлять пользователей в предпочтительные, поддерживаемые каналы? Какие рекомендации нам нужны, чтобы стимулировать ответственное переиспользование контента? Как мы можем достичь целостного опыта для разработчиков и создавать продукты, которые соответствуют потребностям разработчиков-волонтеров, сотрудников и пользователей-посредников? Хотя эти вопросы не новы, актуальность их решения выросла экспоненциально. Начиная с 2024 года мы наблюдаем значительный рост объема запросов, причем в значительной степени этот рост обусловлен инструментами извлечения информации (скрейперами) и ботами, которые собирают обучающие данные для создания рабочих процессов и продуктов на основе ИИ. Нагрузка на нашу инфраструктуру чрезмерна, что ставит под угрозу доступ людей к знаниям. Мы должны действовать сейчас, чтобы заново установить здоровый баланс, который позволит нам эффективно поддерживать проекты Викимедиа и достичь твердых успехов в нашей миссии.
      • Ключевой результат WE5.1: до конца четвертого квартала 50% запросов к программным интерфейсам должны поступать от известных разработчиков или приложений.
        • В настоящий момент наши возможности по выявлению источников автоматизированного трафика ограничены. В отличие от вики-сайтов, у нас также ограничены возможности для связи с пользователями или регулирования их доступа. Мы наблюдаем значительный рост объема внешнего автоматизированного трафика, который является чрезмерным для нас и ставит под угрозу доступ к знаниям для людей. Мы хотим увеличить процент автоматизированного трафика, который можно приписать к зарегистрированным учетным записям, путем обязательной аутентификации и авторизации в рамках многоуровневого доступа при больших объемах скрейпинга или использования API. Это поможет определить тех, кто повторно использует наш контент в больших масштабах, а также позволит нам защитить нашу инфраструктуру, улучшить контроль в отношении добросовестного использования и более эффективно удовлетворить потребности пользователей. Мы также изучим, как эффективнее поддержать техническое сообщество посредством более целостной среды разработки, которая гарантирует привилегированный доступ для членов сообщества и обеспечивает новые функции для разработчиков.
      • Ключевой результат WE5.2: поддержка 70% точек входа в программный веб-интерфейс (API) Викимедиа при помощи общей инфраструктуры к концу 4 квартала.
        • Мы намереваемся повысить удобство использования и надежность наших методов разработки, предложив более последовательные, стабильные и доступные программные интерфейсы приложений (API) для всех разработчиков Викимедиа. Мы упростим структуру предлагаемых интерфейсов путем внедрения более централизованной инфраструктуры для ключевых функций API, что позволит нам получить более целостные подходы и методы управления для: документации и спецификаций OpenAPI, контроля доступа и идентификации разработчиков, контроля политики API, маршрутизации, контроля версий и обработки ошибок. Оптимизируя наш комплекс программных интерфейсов, мы сделаем более приятной разработку инструментов, ботов, исследовательских проектов и функций, которые служат миссии Викимедиа. Данный подход обеспечивает многопоколенческое будущее миссии, снижая затраты на управление инфраструктурой API, повышая прозрачность, усиливая контроль доступа для борьбы со злонамеренными пользователями, а также способствуя укреплению сообщества разработчиков.
      • Ключевой результат WE5.3: до конца четвёртого квартала опубликовать и разместить на всех сайтах Викимедиа новую систему правил указания авторства для веба, приложений, голосовых помощников и больших языковых моделей. Провести две демонстрации повторного использования, показывающие измеримое вовлечение, и обеспечить внедрение передовых практик указания авторства одним внешним партнёром.
        • Для повышения уровня корректного указания авторства контента Викимедиа мы разработаем чёткие практические руководства, способствующие ответственному повторному использованию. Это включает создание системы атрибуции для ключевых платформ (веб, приложения, голос, мультимедиа) и демонстрацию не менее двух примеров, показывающих образцовое использование контента Викимедиа. Примеры включают: побуждение медиаорганизаций указывать авторство изображений с Викисклада, поисковых систем — эффективнее отображать данные Викимедиа, а ИИ-ассистентов — интегрировать знания Википедии прозрачными и ответственными способами, повышающими доверие к их надёжности. Укрепление практики указания авторства не только повышает общественную осведомлённость и стимулирует вовлечённость непосредственно в проекты Викимедиа, но и помогает установить ответственные и инновационные способы повторного использования знаний, предотвращая неправомерное использование.
      • Ключевой результат WE5.4: снижение объема трафика, генерируемого скрейперами, на 20% с точки зрения частоты запросов и на 30% с точки зрения пропускной способности.
        • Скрейпинг всегда присутствовал: поисковые системы десятилетиями опирались на Википедию, чтобы предоставлять информацию своим пользователям. Однако в последнее время появился дополнительный стимул для извлечения наших данных ‒ самый крупный многоязычный набор знаний, который вы можете найти в интернете, являющийся фундаментальным инструментом для обучения больших языковых моделей. Это касается как нашего энциклопедического наполнения, так и нашего мультимедийного хранилища ‒ Викисклада, который бесценен для моделей машинного обучения, генерирующих изображения.
        • В результате за последний год мы наблюдали значительное увеличение объема трафика со стороны скрейперов, а также рост связанных с этим проблем со стабильностью сайта. Инженерам по надежности сайтов неоднократно приходилось внедрять на индивидуальной основе ограничения или блокировки веб-сканеров, чтобы защитить нашу инфраструктуру. Скрейпинг стал настолько частым явлением, что объем нашего исходящего трафика в 2024 году вырос на 50%. Более того, недавний анализ показал, что по крайней мере 65% самых затратных запросов (таких, которые нельзя обработать при помощи кэширующих серверов; вместо этого их обработка производится при задействовании главных баз данных) исходят от ботов.
        • По сравнению с объемом обрабатываемого нами трафика, наши вычислительные ресурсы весьма ограничены. По этой причине нам требуется расставлять приоритеты в отношении тех, кого мы обслуживаем. И мы отдаем предпочтение людям, уделяя особое внимание поддержке проектов Викимедиа и наших участников при помощи скудных ресурсов.

Ускорение методов внедрения продуктов (WE6)

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

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

Метрики (SDS1)

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

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

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

Экспериментальные платформы (SDS2)

  • Цель: менеджеры по продуктам должны иметь возможность быстро, легко и конфиденциально оценить эффект от внедрения новых функциональностей продуктов в Википедии. Обсудить
    • Контекст цели. Для обеспечения ускоренного принятия обоснованных решений по разработке продуктовых функций, менеджерам по продуктам требуется экспериментальная платформа, на которой они могли бы определять эти функции, выбирать затрагиваемую пользовательскую аудиторию и наблюдать результаты измерений эффекта. Сокращение периода времени от запуска до проведения анализа является критически важным, так как сокращение сроков изучения ускорит эксперименты и, в конечном итоге, инновации. Ручные задачи и индивидуальные подходы к измерениям были обозначены как барьеры для скорости. В идеальном случае менеджеры по продуктам должны иметь возможность перейти от запуска эксперимента к получению результатов при небольшом или нулевом ручном вмешательстве со стороны инженеров и аналитиков.
    • В следующем финансовом году мы сосредоточимся на Википедии, так как команда базового опыта заинтересована в проведении экспериментов именно в ней (организационная стратегия побуждает нас удвоить усилия в отношении Википедии), потому что это позволяет нам сосредоточиться и более четко обозначить, с какими командами и проектами мы взаимодействуем. Другие команды уже использовали компоненты экспериментальной платформы и могут продолжать делать это и далее, но это применение не будет в центре внимания этой цели.
      • Ключевой результат SDS2.1: завершение по крайней мере двух полных экспериментальных циклов с использованием платформы для проведения экспериментов.
        • Поскольку в нашей организации уделяется все больше внимания принятию продуктовых решений на основе данных, мы должны сделать проведение экспериментов доступным для всех продуктовых команд, а не только для обладающих специальными навыками. Продуктовые команды должны иметь общие стандарты, инструменты и инфраструктуру, которая позволяет:
          • быстро тестировать идеи в рамках нашей глобальной пользовательской базы;
          • измерять эффект от модификаций продуктов при помощи стандартных показателей;
          • прозрачно обмениваться результатами с заинтересованными сторонами Движения.
        • Почему мы переходим от концентрации на количестве «вовлеченных команд» к «завершенным экспериментам»:
        1. Стратегическое соответствие: это наш основной показатель успеха в рамках платформы.
        2. Подход, учитывающий данные: наше пользовательское исследование (в процессе) показывает разную готовность команд в рамках всей организации, в то время как мы знаем, что веб-команда подтвердила интерес к двум конкретным экспериментам.
        3. Оптимизация ресурсов: развертывание нашей платформы MVP потребует персонализированного введения в курс дела, в результате чего более эффективным шагом в ближайшем будущем будет концентрация внимания на возможностях эксперимента, нежели чем на широком охвате сразу нескольких команд. Мы планируем двигаться к общему релизу и не хотим снова вкладывать средства в обучение команд, если это возможно.
        4. Ориентация на будущее: отзывы, полученные в ходе полных экспериментальных циклов, послужат более эффективной основой для совершенствования платформы, чем знания, полученные на основе частичного или неполного внедрения. По мере продвижения к общему релизу, концентрация на завершении экспериментов позволяет избежать инвестиций во временные подходы, которые пришлось бы переделывать.
        • Мы проводим пользовательские исследования, чтобы выявить запросы и потребности среди команд. На вторую половину мая запланированы опрос и интервью, чтобы прояснить потребности продуктовой команды. После завершения исследования мы составим календарь экспериментов, который может служить основой для определения следующих целей по ключевым результатам и расстановки приоритетов.
      • Key result SDS2.2: Before the end of Q3, results for at least one web experiment can be analyzed and viewed in GrowthBook.
        • After a long and arduous process, we finally made a decision to integrate GrowthBook as a third-party experimentation solution that offers experiment flagging, automated analysis, and dashboarding, with support for guardrail metrics. Experiment Platform intends to replace the UI to define and deploy experiments (1) and the experiment analytics pipeline (5) with GrowthBook.
        • Because of the risks associated with this integration, the Experiment Platform Team believes that GrowthBook should be integrated as an experiment analytics pipeline first because it's non-disruptive and because it's the greatest source of risk.
        • The architectural decisions we made during FY24/25 SDS2 and GrowthBook’s modularity allow us to replace parts of the Experimentation Lab out of order, i.e. WMF staff can define and deploy experiments with xLab UI while analyzing them with GrowthBook. Further, we can run the current experiment analytics pipeline and GrowthBook’s in parallel, which allows for side-by-side comparisons as well as User Acceptance Testing in real-world scenarios.
      • Key result SDS2.3: By the end of Q4, all new Test Kitchen experiments are configured in GrowthBook.
        • After having enabled WMF staff to use GrowthBook for analyzing experiment results, the Experiment Platform team held a design sprint to assess options for experiment configuration. The decision was to use GrowthBook as the source of truth for experiment configuration but keep Test Kitchen UI (TKUI) as the source of truth for instrument configuration.
          In making GrowthBook the source of truth for experiment configuration, we aim to:
          • Reduce coordination when running an experiment
          • Enable more frequent and repeatable experimentation
          • Clearly delineate between instruments and experiments
          • Move toward a mental model centered on metrics rather than instruments
      • Key result SDS2.4: At least 14 out of 20 product teams have used Test Kitchen to inform a strategic decision for an OKR initiative, by the end of Q4.
        • The work done under SDS2.1 revealed a critical insight: building an experiment platform is not enough — Product & Tech teams face some barriers to adoption. Even though teams see value, they often lack time, infrastructure, instrumentation, or confidence to begin. In addition to this, they may encounter technical blockers that will need to be addressed by thoughtful partnership.
        • KR SDS2.4 shifts our focus from building to scaling adoption. By continuing to partner with teams as they onboard onto the platform, overcoming technical barriers and providing hands-on migration support, we aim to consolidate experimentation onto Test Kitchen as the unified platform for product teams, enabling fast, self-service testing cycles that reduce dependence on engineering and analytics support.
        • This KR was planned after we decided to split SDS2.2 in two pieces of work, which is why the numbering was affected. SDS2.3 is an upcoming KR that is sequential to GrowthBook for Experiment Analytics.

Аудитории будущего (FA)

Аудитории будущего (FA1)

  • Цель: предоставление Фонду Викимедиа рекомендаций по стратегическим инвестициям, которые помогут нашему движению охватить новые аудитории в изменяющемся интернете. Обсудить
    • Контекст цели. В связи с текущим развитием технологий и меняющимся онлайн-поведением пользователей (например, растущая тенденция получения информации через социальные приложения, популярность коротких обучающих и развлекательных видео, развитие генеративного ИИ), движение Викимедиа стоит перед вызовами привлечения и удержания читателей и участников. Эти изменения также создают возможности для охвата новых аудиторий путем создания и предоставления информации новыми способами. Тем не менее мы как движение не имеем четкого, подтвержденного данными представления о преимуществах и компромиссах, связанных с различными потенциальными стратегиями, которые мы могли бы принять для преодоления проблем и использования новых возможностей. Например, мы могли бы...
      • Инвестировать в новые крупные функции, такие как чатботы?
      • Привнести знания Викимедиа и соответствующие пути сотрудничества на популярные сторонние платформы?
      • Что-либо еще?
    • Чтобы гарантировать, что Викимедиа станет многопоколенческим проектом, мы будем тестировать гипотезы для лучшего понимания и выработки перспективных стратегий относительно привлечения и удержания аудиторий будущего – как для Фонда Викимедиа, так и для движения Викимедиа.
      • Ключевой результат FA1.1: по результатам экспериментальных идей и рекомендаций по аудиториям будущего, обеспечить появление по крайней мере одной цели или ключевого результата, принадлежащего несвязанной с аудиториями будущего команде, в проекте годового плана на следующий год.
        • Начиная с 2020 года Фонд Викимедиа отслеживает внешние тенденции, которые могут оказать влияние на наши возможности по охвату будущих поколений, потребляющих и сохраняющих знания, чтобы остаться процветающим движением свободных знаний на многие поколения вперед. Команда аудиторий будущего, будучи небольшим отделом исследований и разработок, намеревается:
          • проводить быстрые, ограниченные по времени эксперименты (планируя не менее трех экспериментов в течение финансового года) для исследования способов ответа на эти тенденции;
          • на основе экспериментального опыта выработать рекомендации по новым, неэкспериментальным инвестициям, которые Фонду Викимедиа следует осуществить ‒ например в новые продукты или программы, требующие участия полновесной команды или команд, ‒ в течение нашего регулярного годового периода планирования.
        • Этот ключевой результат будет выполнен, если по крайней мере одна цель или ключевой результат, принадлежащий внешней по отношению к аудиториям будущего команде, но обусловленный самими рекомендациями по аудиториям будущего, появится в проекте годового плана на следующий финансовый год.

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

  • Цель: достижение того, что молодые люди (младше 25 лет) любят контент Википедии, изучают его, взаимодействуют с ним и делятся им на платформах, где они предпочитают проводить онлайн-время. Обсудить
    • Контекст цели. Эксперименты с короткими видео в рамках направления аудиторий будущего, проведенные в этом финансовом году, показали, что мы можем охватить на этих платформах масштабную молодую аудиторию. Однако наши данные о "здоровье" бренда показывают недостаточность текущих инвестиций, чтобы противостоять снижению осведомленности о Википедии и интереса к ней среди представителей поколения Z.
    • Чтобы эффективно охватить и вовлечь это поколение, мы считаем, что нам потребуется использовать различную тактику и значительно повысить наше присутствие в таких областях, как платный маркетинг, маркетинг влияния и креативные кампании, а также реагировать на тенденции и расширять поле для экспериментов в этих каналах.
    • Мы ожидаем, что вызовы, стоящие перед нами, потребуют более основательных инвестиций, чтобы помочь нам их преодолеть, особенно в области коммуникаций и маркетинга для создания вовлеченности, а также в области сотрудничества между отделами по теме создания новых продуктов и сред, направленных на увеличение присутствия бренда Википедии на этих платформах.
      • Ключевой результат FA2.1: обеспечение до конца первого полугодия 9 500 000 просмотров коротких видеороликов на всех собственных каналах.
        • В этом году мы достигли приблизительно одного миллиона просмотров спустя три месяца с момента запуска коротких видио на каналах @Wikipedia в TikTok, Instagram и YouTube. До начала следующего финансового года мы ожидаем, что у нас появится больше подписчиков на наших каналах и больше информации об эффективном/увлекательном контенте, который мы можем запустить на практике для охвата еще большего числа зрителей.
        • Задавая амбициозные цели в первом полугодии, мы надеемся добиться более значительной отдачи, создать новые стратегии/процессы для облегчения работы и получить возможность отстоять дополнительные ресурсы для достижения этой цели.
      • Ключевой результат FA2.2: увеличить количество подписчиков в TikTok с уровня Mid tier (100–250 тыс.) до уровня Macro tier (250 тыс. – 1 млн) к концу 2025/26 финансового года (июнь 2026).
        • В настоящее время мы находимся на уровне Mid tier (100–250 тыс. подписчиков), и наша цель — достичь уровня Macro tier (250 тыс. – 1 млн). Эти категории являются стандартными показателями охвата аудитории. Для достижения цели мы уточним контент-стратегию, чтобы лучше привлекать аудиторию поколения Z и усилим видимость через работу с сообществом. Результаты первой половины года позволят внести тактические корректировки во второй половине для ускорения роста и достижения этой цели.
      • Ключевой результат FA2.3: запуск продукта, нацеленного на новые методы изучения и потребления медиа-информации, вне нашей платформы и вывод его на рынок путем совместной кампании по брендингу и маркетингу продукта.
        • Команда аудиторий будущего обычно работает над небольшими экспериментами с минимальным/органичным маркетинком. В этом году мы хотели бы зарезервировать время для более масштабной маркетинговой кампании по новым продуктам, ориентированной на молодую аудиторию вне нашей платформы.

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

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

  • Цель: достижение большей эффективности командами продуктовой и инженерной поддержки благодаря усовершенствованным процессам, при содействии позитивным сдвигам в нашей культуре. Обсудить
    • Контекст цели. Эта цель заключается в том, чтобы методы работы Фонда Викимедиа стали быстрее, рациональнее и лучше. Она охватывает то, как мы работаем. Это подразумевает меньше трений и препятствий (неэффективности и ошибок) в процессах, а также и более быстрое достижение результата. Эта цель также затрагивает изучение методов работы, которые могут быть внедрены во всем отделе или организации.
      • Ключевой результат PES1.1: формулировка до конца второго квартала, целей уровня обслуживания (SLO) для шести действующих сервисов на основе критерия важности, нацеленного на максимально эффективное изучение того, как определять и использовать SLO для принятия заинтересованными командами обоснованных решений о приоритетности работ по надежности.
        • Цель уровня обслуживания (SLO) – это соглашение между заинтересованными командами о заданном уровне надежности или производительности услуг, который эти команды надеются достичь в процессе сотрудничества (и незначительно превысить). Например, это поможет определить, когда работа над надежностью или производительностью должна иметь для команды разработчиков повышенный или пониженный приоритет, или установить, в чем заключается проблема. Команды должны устанавливать срочность (оповещение/реагирование на инциденты/критические ошибки) или отсутствие таковой. Цель заключается в снижении соперничества между функциями путем согласования ориентиров и совместной, прозрачной расстановки приоритетов.
      • Ключевой результат PES1.2: до конца второго квартала сигналы сообщества (в том числе и список пожеланий) должны повлиять на то, что WMF повысит приоритет по крайней мере для пяти продуктовых направлений работы на перспективу третьего и четвертого квартала.
        • Наша цель — выявлять и поощрять случаи, когда команды расставляют приоритеты в работе на основе запросов сообщества, подкрепленных фактами.
        • Две запланированные гипотезы сосредоточены исключительно на Списке пожеланий. Они направлены на повышение доверия, оптимизацию процессов и рост участия среди сотрудников и волонтеров. Другая гипотеза является экспериментом, направленным на проверку того, достаточное ли количество сигналов поступает с местных форумов сообществ и т.д., а также и того, может ли ИИ укрепить наши возможности по сбору этих сигналов.
      • Ключевой результат PES1.3: включение двух межотдельных экспериментов, проведенных на ранних стадиях и одобренных внешней аудиторией потребителей, жертвователей и участников, в ежегодный план Фонда.
        • Данная работа заключается в создании экспериментов и процессов экспериментирования для последующего внедрения в рамках организации.
        • Фонд укрепляет культуру экспериментирования между отделами путем включения двух одобренных экспериментов, проведенных на ранней стадии, в ежегодное планирование. Эта инициатива способствует расширению сотрудничества за пределами команд отдела продуктов и технологий, стимулируя больше инноваций совместно с другими отделами организации (такими как отдел коммуникаций и продвижения). Порождая новые, непроверенные идеи и оптимизируя процессы экспериментирования, команды повышают производительность и расширяют масштабы результативности. Успех определяется проведением двух межотдельных экспериментов в год с дальнейшей интеграцией их в работу по ЦКР и повышением уровня распространенности практики экспериментов. Примерами результатов могут служить новые прототипы, ускоряющие рост числа редакторов и повышающие их производительность, а также экспериментальные функции, укрепляющие связи читателей и благотворителей с Википедией. Одной из выявленных возможностей является исследование малых функций в контексте празднования 25-летия Википедии.
      • Key result PES1.4: By the end of Q4, we'll see a 10% adoption rate increase for Codex among P&T teams.
        • As a standardized UI library, Codex vastly reduces both the maintenance burden of creating custom UI components, as well as the time needed for implementing product UIs. Codex also provides a shared vocabulary for talking about design and implementation, which increases efficiency between Design & Engineering.
        • Codex will lose utility if adoption doesn’t increase and Codex isn’t widely used, and currently it is not being adopted or widely used in some places because the tooling isn't ready for some use cases. It may also need more prominent advertising/awareness. This work is a priority because teams must be able to adopt Codex organically, and currently not all can without blockers to adoption being addressed first.
        • We're anticipating that this will mean:
          • Discovery - What do different teams show us is blocking them? What are the use cases and blockers about which we are not yet aware?
          • Improvement - Example: We know that Codex PHP 1.0 will unblock server-side adoption.
          • Metrics deep dive - Example: What do the baseline metrics established in Q1 tell us about where organic adoption is not working (and are there lessons from OOUI adoption in years past)?
        • The KR will focus on tracking “official” usage (i.e. adoption that follows the documented guidance) separately from partial or piecemeal usage, e.g. when teams use only part of a component or just the CSS. The latter type of adoption incurs a higher maintenance cost than out-of-the-box component usage.
      • Key result PES1.5: 20% of service SLOs result in an impactful decision made by the end of Q4.
        • Service Level Objectives (SLOs) are a tool used to determine priorities based on data from service reliability. For instance, whether a down service needs immediate attention. SLOs work most effectively when ownership is clear, and everyone is using them. To make this happen we need to shift development culture toward adopting SLOs for every service. Building on the last few quarters of creating SLOs and testing them with service teams, we've identified an opportunity to clarify the value of SLOs, so that we can continue to spread this culture.
          • We have 19 SLOs currently.
          • We want to incentivize SLOs for services that would be most likely to leverage them. If we get ~3-4 (~20% 0f 19) "impactful decisions" from our current crop, great, but we anticipate we'll need to make more. The denominator will increase, but that further incentivizes targeting the right services.
          • Q4 is the end of the timebox because we want more than one cycle of data, and each quarter is a cycle. It also gives us space to shore up tooling, pilot SRE-alerting, etc.
        • Success looks like:
          • Impactful decision = “is this service currently reliable enough, or do we need to prioritize work to fix it” -- that is, it's as much a decision to find an error and say it's OK not to prioritize it, as it is to find an error and prioritize correcting it.
          • We want decisions to be diverse (e.g. Architectural vs Organizational vs Implementation; or affirmative vs deciding not to do something), because this is about spreading the value of SLOs and shifting culture. All the same type of decision or all from the same team doesn't accomplish that, even if it's good.
          • Even if we don't meet the KR target, we hypothesize that we'll have learned valuable information about why (e.g. we're targeting the wrong services).
          • Important: 80% of our SLOs not having an impactful decision is not a failure state for those, because most of the time services should not be failing.
      • Key result PES1.6: 20% of critical unowned services, according to a risk analysis framework, get owners committed by the end of Q4.
        • Clear code and service ownership is critical to ensuring the Wikimedia Foundation’s technical infrastructure remains reliable, scalable, and secure. Addressing current gaps in ownership will improve accountability, enhance cross-team collaboration, fast-track effective decision-making, and reduce risks to platform stability, security and sustainability. Additionally, it will provide greater clarity for Wikimedia affiliates and volunteers, helping them understand who is responsible for maintaining and supporting key services.
          • We estimate there are ~20 critical services without owners.
          • We think we can assign 4 owners over 4 months during Q3/4. The first 2 months or so will be setting ourselves up for success with prep work.
          • We plan to develop a risk analysis framework to determine criticality, as part of hypothesis work under this KR.
      • Key result PES1.7: By the end of Q4, 85% of wishes have a response within 10 working days, and a monthly update is posted on the work we committed to implement.
        • Having revamped Wishlist triage in the first half of the year, we want to consistently demonstrate that volunteers are getting responses to their Wishes plus a monthly update consisting of what’s coming, what’s pending or blocked, and what’s being scoped. We will judge the metric by measuring response time on a rolling average over a month, and aim to sustain that for at least a month.

Гипотезы

Первый квартал

Первый квартал (Q1) годового плана WMF охватывает период с июля по сентябрь.

Гипотезы по направлению «Среда Вики» (WE)

[ Ключевые результаты WE ]

Обсуждение

Краткое наименование гипотезы Формулировка в первом квартале Подробности и обсуждения
WE1.1.1 Если мы попросим новых волонтеров, копирующих текст с внешнего сайта, подтвердить, что они сами написали контент, который пытаются добавить, то мы увидим снижение на ≥10% доли публикуемых новыми волонтерами правок, отмененных на основании WP:COPYVIO (и сопутствующих правил).
WE1.1.2 Если мы выпустим первоначальную бета-версию функции сопровождаемых правок «Улучшить тон», мы сможем узнать, является ли этот новый формат сопровождаемых правок практическим способом увеличения количества конструктивных правок для новых участников без роста нагрузки на патрульных/рецензентов.
WE1.1.3 Если мы внедрим новый режим сопровождения, ориентированный на заслуженных участников, в визуальном редакторе (мобильные устройства + компьютеры) в качестве бета-функции с ≥ 3 новыми предложениями по редактированию, мы выясним, какие корректировки (если таковые будут) необходимо внести перед проведением оценки опыта взаимодействия с новыми волонтерами посредством контролируемого эксперимента.
WE1.1.4 Если мы развернем функцию проверки ссылок в Английской Википедии посредством контролируемого эксперимента, мы увидим увеличение на ≥10% числа конструктивных правок, публикуемых новыми волонтерами, и узнаем, имеется ли достаточная поддержка среди патрульных и модераторов для более широкого внедрения этой функции.
WE1.1.5 Если мы протестируем систему прогресса при помощи дизайн-прототипов с привлечением новичков, то сможем определить, какие виды временных этапов, руководства и признания воспринимаются как наиболее мотивирующие, и использовать эти результаты для окончательной доработки дизайна для будущих пилотных вики-экспериментов.
WE1.1.6 Если мы изучим, посредством пользовательского исследования и анализа данных, основные технические, социальные и поведенческие барьеры и помогающие факторы в контексте мобильного веб-редактирования, мы получим по меньшей мере 3 практических рекомендации, которые восполнят ключевые пробелы в знаниях и укрепят нашу способность уверенно расставлять приоритеты в продуктовых инвестициях на вторую половину финансового периода 2025-2026 гг. и далее.
WE1.2.1 Если мы создадим прототип, отображающий данные о совместном вкладе на вики-проектах, мы сможем собрать отзывы как минимум от 30 участников, причем 70% респондентов скажут, что эта функция полезна и может способствовать развитию сотрудничества.
WE1.3.1 Если мы учтем потребности, выявленные в ходе предыдущих исследований, разработаем и опубликуем предварительные макеты наиболее значимых модулей модерации в количестве X, мы сможем модифицировать с их помощью домашнюю страницу для модераторских действий.
WE1.3.2 Если мы изменим домашнюю страницу нового участника таким образом, чтобы модули модерации отображались в зависимости от некоторых условий, то мы сможем обосновать целесообразность использования домашней страницы для модераторов.
WE1.4.1 Если мы внесем ряд улучшений, обозначенных в T396489, мы сократим на крупных вики-проектах количество медленных запросов о недавних изменениях на X процентов. Тогда инструменты модерации смогут разворачивать модули на домашних страницах этих вики-проектов без особых соображений, касающихся производительности баз данных. T400696
WE2.1.1 Если мы пригласим, через баннер центральных объявлений на проекте Википедии с высоким трафиком в соответствующем регионе, носителей языка из небольших вики-проектов внести свой вклад по теме предлагаемых правок и других функций развития, мы сможем оценить, привлечет ли этот подход новых носителей языка и будут ли они использовать эти инструменты редактирования для улучшения жизненно важного наполнения.
WE2.1.2 Если бы мы разработали и внедрили функцию предложения перевода, адаптированную для новых редакторов, мы бы тогда смогли проверить, обеспечивает ли данный подход лучшие результаты перевода по сравнению с нашим текущим подходом.

Это решило бы известные проблемы, с которыми сталкиваются новые редакторы, имеющие более высокую вероятность удаления статей. Предлагая им переводить более удобный контент, мы стремимся сделать ознакомление с процессом перевода менее перегруженным и более доступным. Хорошие статьи и разделы могут восприниматься как не слишком сложные с точки зрения форматирования и общего объема.

WE2.1.3 Если мы изучим опыт редакторов при создании новых статей и разделов (включая их мотивацию, проблемные вопросы и реакцию на новые идеи о том, какая поддержка для них лучше), то мы выявим потребности и поведение пользователей, которые дадут практические идеи и стратегии для отделов продуктов, дизайна и инжиниринга в плане усовершенствования среды создания статей.
WE2.1.4 Если мы исследуем с помощью совместных семинаров или интервью то, как три проекта Википедии среднего размера решают вопросы недостатка знаний и их важности, мы выявим практические определения и рамочные концепции для «жизненно важных знаний», которые будут актуальны для каждого сообщества.
WE2.2.1 Если мы последуем примеру Parsoid и внедрим Викифункции на большинстве проектов Викисловарей и на некоторых версиях Википедии с низкой посещаемостью, мы получим необходимое тестирование для уверенного развертывания на более крупных вики-проектах.
WE2.2.2 Если мы дополним Викифункции способностью выводить HTML-таблицы, стили и ссылки, то при помощи функции, которая отображает таблицу спряжения, мы продемонстрируем возможность генерации на проектах Викисловарей новых знаний, а не только простых преобразований.
WE2.2.3 Если мы добавим поддержку объектов Викиданных при вызовах встроенных функций, мы обеспечим работу более 200 новых функций, которые смогут генерировать комплексные предложения с использованием объектов Викиданных. Это в целом упростит использование функций на проектах Викимедиа.
WE2.2.4 Если мы разработаем архитектурный план того, где будет размещен Абстрактный Контент и как он будет взаимодействовать с Википедией, мы будем в большей степени готовы к внедрению платформы Абстрактной Википедии, чтобы увеличить объемы высококачественного энциклопедического наполнения.
WE2.2.5 Если мы определим и обсудим с командами по продуктам и технологиям потребности продуктов с точки зрения цитирования, которое требуется для абстрактного контента, мы сможем стимулировать в рамках Викимедиа работу по предоставлению информации о происхождении, которая связана с абстрактным контентом. Это имеет решающее значение для успешного внедрения на всех вики-проектах.
WE2.2.6 Если мы сделаем формат внутренних запросов к бэкенду более выразительным и кратким, мы сможем повысить стабильность системы и тем самым поддержать более масштабное развертывание.
WE2.2.7 Если мы представим фрагменты прототипа, использующего Викиданные и вызовы Викифункций для генерации элементов естественного языка, мы покажем нашу готовность для этого проекта и к тому, что его можно будет использовать для обучения ИИ, чтобы людям не приходилось слишком много думать о функциях.
WE2.2.8 Если мы обеспечим импорт выражений Викиданных вместе с классификаторами, то появится возможность генерировать многогранные факты (факты, для выражения которых требуется нечто большее, чем просто предмет/предикат/значение), к которым относится примерно 50% энциклопедического контента в Викиданных.
WE2.2.9 Если мы обеспечим кэширование извлеченных объектов Викиданных, мы сократим как минимум на 50% среднее время выполнения функций, использующих содержимое Викиданных, уменьшив тем самым время ожидания и разочарование пользователей.
WE2.2.10 Если мы добавим в пользовательский интерфейс Викифункций компонент обработки лексем Викиданных, то участники смогут обнаруживать и выбирать соответствующие лексемы, не покидая платформу/Викифункции, что сократит необходимость переключения контекста и позволит быстрее и успешнее создавать связанные с языком функции.
WE2.2.11 Если мы рассмотрим результаты изысканий сообщества Дагбани по удобству использования в контексте интеграции Викифункций в Википедию, то увидим, что редакторы сталкиваются с малым или нулевым количеством критических проблем удобства использования при вставке функции в статью во время тестирования.
WE3.1.1 Если мы проведем, в приложении IOS, A/Б-тестирование улучшенной версии функции просмотра с использованием вкладок, то увидим рост многодневного использования на 5% среди пользователей вкладок.
WE3.1.3 Если мы предоставим пользователям новый способ просмотра соответствующего графического или видео-контента на страницах статей, то увидим, что среди пользователей, которым представлена эта функция, значение коэффициента кликов составит не менее чем 3%.
WE3.1.4 Если мы покажем читателям несколько концепций навигации по сети знаний на вики-проектах, мы получим приоритетный список концепций для дальнейшей разработки.
WE3.1.5 Если мы предоставим веб-читателям возможность просматривать машинный перевод контента Википедии, недоступного на их языке, мы узнаем, увеличится ли уровень читательской активности, который можно измерить как увеличение количества взаимодействий со страницами на 3%. Это привлечет читателей на локальную версию вики-проекта на местном языке и потенциально увеличит активность локального редактирования. Это будет осуществляться в рамках контролируемого A/Б-тестирования длительностью не более 6 месяцев в рамках 13 проектов Википедии (с их предварительного согласия), используя открытые сервисы машинного перевода, уже доступные редакторам Википедии.
WE3.2.1 Если мы будем сотрудничать с отделом сбора средств, мы разработаем более увлекательные, интегрированные и персонализированные спонсорские слайды для iOS Year-in-Review, которые будут оцениваться по результатам пользовательского тестирования. Во втором квартале будет выдвинута гипотеза, позволяющая оценить, увеличилось ли на 5% количество пожертвований благодаря обновленным материалам Year-in-Review по сравнению с Year-in-Review 2024 года.
WE3.2.2 Если мы предложим пользователям мобильного приложения для Android, на не охваченных кампаниями рынках, необязательное напоминание о пожертвованиях (с возможностью настройки суммы и частоты) с учетом их интенсивности использования Википедии, мы увидим на этих рынках рост пожертвований через меню приложения на 5%.
WE3.2.3 Если мы проведем эксперимент по А/Б-тестированию среди неавторизованных пользователей по отображению ненавязчивых вариантов пожертвований как на мобильных устройствах, так и на настольных компьютерах, то увидим рост на 2% количества пожертвований, совершенных через данные пути, по сравнению с контрольной группой.
WE3.3.1 Если мы добавим элементы персонализации, запрошенные пользователями iOS в 2024 году для Year-in-Review 2025 года, то увидим рост уровня удовлетворенности на 3% по сравнению с предыдущим годом, что можно измерить посредством тестирования удобства использования или бета-тестирования.
WE3.3.2 Если мы расширим существующую вкладку редактирования в Android-приложении до хаба персональной активности, содержащего данные по читательской активности и участию без редактирования, мы увидим рост многодневного взаимодействия с этой вкладкой на 5% по сравнению с оригинальной версией.
WE3.3.3 Если мы добавим в Android-приложение для владельцев учетных записей хотя бы один открываемый аватар (получаемый за значимые читательские действия, например за сохранение определенного количества статей), мы увеличим на 10%, среди зарегистрированных пользователей, уровень повторной вовлеченности в указанные действия на протяжении нескольких дней.
WE3.3.4 Если мы предоставим авторизованным читателям возможность сохранять статьи в личном списке чтения, мы ожидаем, что уровень взаимодействия с сайтом повысится, что может быть измерено как рост на 5% внутреннего реферального трафика среди использующих эту функцию читателей, а также как статистически значимый рост для всех пользователей.
WE3.3.5 Если мы проведем пользовательское исследование, которое позволит веб-читателям собирать/коллекционировать контент из Википедии, то по крайней мере 10% участников добавят в свою коллекцию не менее двух различных типов наполнения (например, статьи, выдержки и медиа-файлы).
WE3.4.1 Если мы будем работать над гибридным развертыванием сети доставки контента с точками присутствия (PoP/CDN), это позволит нам по мере необходимости внедрять как полноценные, так и мини-точки присутствия (PoP), будь то физические или облачные. Это заложит основу для прототипного развертывания мини-точек присутствия (PoP) в будущем.
WE3.6.1 Если мы проведем A/A-тестирование по показателю удержания неавторизованных пользователей, мы установим базовый показатель коэффициента удержания, который можно будет использовать в будущих кварталах.
WE3.6.2 Если мы сформулируем и опубликуем определение авторизованного (вошедшего в систему) читателя, мы сможем использовать это определение совместно со всеми командами и гипотезами, связанными с ключевым результатом WE3.3.
WE3.6.3 Если мы привлечем сообщества к обсуждению развивающихся потребностей читателей и меняющейся природы знаний в интернете, мы сможем выработать общее понимание относительно обслуживания читателей и совместной работы по проведению (если требуется) тестирования наших различных идей (в том числе связанных с мультимедиа, поиском и обнаружением, а также машинным обучением).
WE3.6.4 Если мы изучим различные мотивы, модели поведения и потребности, которые лежат в основе того, когда, почему и как читатели используют Википедию и другие платформы знаний, мы получим результаты, которые сможем использовать для формирования и развития нашей потребительской стратегии.
WE4.1.1 Если мы создадим прототип минимально функционирующего неэкстренного потока и будем поддерживать по мере разработки постоянную обратную связь с пользователями с расширенными правами, то эти группы поддержат расширенное внедрение этого потока. Project page
WE4.2.1 Если мы сообщим уровень риска hCaptcha, связанный с созданием аккаунта, доверенным функционерам, мы сократим время, необходимое для выявления злоумышленников, и увеличим количество обнаруженных злонамеренных учетных записей, созданных на платформе. Успешность гипотезы можно оценить по количеству блокировок учетных записей, сопоставлению уровней риска hCaptcha и блокировок аккаунтов в целом, а также по отзывам функционеров.
WE4.2.2 Если мы будем формировать списки рекомендуемых расследований для проверяющих администраторов, мы увидим сокращение сроков, необходимых для выявления вредоносных учетных записей, и рост уровня их обнаружения. Мы оценим успешность, если увидим регулярное использование функции «Рекомендуемые расследования», увеличение количества предотвращающих мер в отношении обнаруженных таким образом учетных записей, а также по результатам опросов о качестве работы.
WE4.2.3 Если мы проанализируем данные, полученные в ходе пробного запуска создания учетных записей с применением hCaptcha, мы поймем весь цикл создания учетной записи и эффективность головоломок и рейтингов hCaptcha, а также получим необходимые данные для планирования дальнейшего развертывания функции создания учетных записей с применением hCaptcha.
WE4.2.4 Если мы внедрим информационную карточку пользователя (UserInfoCard) на всех вики-проектах, мы расширим возможности функционеров и модераторов по эффективному обнаружению и противодействию злоумышленникам. Project page
WE4.2.5 Если мы проведем исследования, проконсультируемся с сообществами и изучим технические решения, мы сможем сформулировать структурированный список причин блокировки, который можно применять на всех вики-проектах.
WE4.2.6 Если мы привнесем возможность развертывания кластеров на базе OpenSearch на платформе данных, то инженерные команды по продуктовым функциям получат возможность разрабатывать системы, интегрирующие эту функциональность, с обеспечением высокой степени автономности, отказоустойчивости и изоляции от других поисковых систем. Первым и основным клиентом этой системы станет сервис IPoid.
WE4.2.7 Если мы развернем корпоративную интеграцию hCaptcha на нескольких работающих проектах Википедии в качестве пилотного тестирования, мы сможем собрать данные об эффективности и ценности корпоративного пакета hCaptcha с точки зрения борьбы со злоупотреблениями, обнаружения ботов, удобства использования и доступности.
WE4.3.1 Если мы интегрируем поддержку нового уникального периферийного куки-файла (Edge Uniques) в инструменте requestctl, являющемся нашим механизмом периферийных правил, который используется инженерами по надежности (SREs) для борьбы со злоупотреблениями, мы сможем эффективнее защищаться от DDoS-атак и повторного использования контента.
WE4.4.1 Если мы сможем внести улучшения на основе обратной связи от пилотного тестирования и развернуть функциональность временных учетных записей на всех проектах, мы сможем защитить персонально значимую информацию (IP-адреса) незарегистрированных пользователей на всех наших проектах, сделав ее доступной менее чем 0,1% всех (зарегистрированных) пользователей. Project page
WE4.4.2 Если мы будем взаимодействовать с соответствующими заинтересованными сторонами (включая вики-сообщества и глобальных функционеров) вовремя и прозрачным образом, мы сможем развернуть все оставшиеся вики-проекты, снизить объем работ, обнаруженных в последний момент, и избежать откатов при запусках.
WE4.4.3 Если мы облегчим фильтрацию действий временных учетных записей и просмотр их активности на основе IP-адресов, мы обеспечим успешный запуск временных учетных записей на всех вики-проектах.
WE4.4.4 Если мы разрешим отзывать доступ к раскрытию IP-адресов временных учетных записей в соответствии с политикой доступа к раскрытию IP-адресов и сообщим об этой функции в большем количестве мест, то мы сможем успешно внедрить временные учетные записи на всех вики-проектах.
WE4.5.1 Если мы проведем качественное исследование для выявления примеров злоупотреблений со стороны злоумышленников с применением генеративного ИИ (например, спам, преследование, постоянные нарушители, скрытое платное редактирование или кампании по дезинформации), мы сможем оценить риск для наших моделей сообщества и сформировать идеи по противодействию различным видам злоупотреблений, осуществляемым при помощи генеративного ИИ.
WE4.6.1 Если мы автоматизируем процесс синхронизации учетных записей в Zendesk в контексте сброса паролей, это снизит нагрузку на команду доверия и безопасности и позволит ей обрабатывать больше входящих 2FA-запросов на сброс.
WE4.6.2 Если мы будем поддерживать и поощрять пользователей в плане активации нескольких факторов аутентификации, пользователи с включенной двухфакторной аутентификацией с меньшей вероятностью сами заблокируют свою учетную запись.
WE4.6.3 Если мы позволим всем пользователям с подтвержденным адресом электронной почты включить двухфакторную аутентификацию (2FA) для своих учетных записей, но не будем заблаговременно рекламировать пользователям это нововведение, нагрузка на нашу службу поддержки восстановления данных останется на приемлемом уровне.
WE5.1.1 Если мы будем использовать разные бэкенды для хранения данных авторизованных и анонимных сессий, мы сможем защитить сессионное хранилище данных (Sessionstore) от DDoS-атак и скреперов с большим трафиком, не перегружая его анонимными сессиями, которые создаются для обеспечения CSRF-защиты на страницах аутентификации. T398814
WE5.1.2 Если мы преобразуем сессионные куки MediaWiki в структурированный формат с криптографической подписью, мы сможем использовать наличие сессии в качестве фактора защиты против скреперов путем обеспечения надежной верификации сессий на периферии производительным и высоко масштабируемым способом. T398815
WE5.1.3 Если мы создадим решение по ограничению количества запросов к порталу программного интерфейса (API) с использованием локальной среды разработки на базе Kubernetes, мы сможем определить наилучший вариант для тестирования с реальным трафиком путем сравнения производительности и функциональности как минимум трех различных сервисов ограничения количества запросов. T398913
WE5.2.1 Если мы переработаем пользовательский интерфейс тестовой площадки REST API, чтобы лучше удовлетворить информационные потребности разработчиков, мы повысим ясность документации, что может быть проверено путем тестирования удобства использования.
WE5.2.2 Если мы направим трафик программных интерфейсов API, доступных под rest.php, через центральный портал, мы сделаем возможными средства централизованного управления API и сможем начать последовательные измерения трафика и шаблонов использования REST API, чтобы получить информацию для планирования будущих решений и действий.
WE5.2.3 Если мы внедрим панели мониторинга и сигналы оповещения для программного интерфейса REST API у MediaWiki, то сможем продемонстрировать устойчивый, полезный и воспроизводимый способ повышения прозрачности работы наших систем, а также раньше выявлять проблемы, особенно во время критических изменений.
WE5.3.1 Если мы расширим и оптимизируем руководство по указанию авторства в рамках пользовательской среды с одновременным обновлением любых существующих правил, мы создадим базовый набор усовершенствованных правил, готовых для внутреннего тестирования и последовательной доработки, чтобы подготовиться к более широкому публичному использованию.
WE5.3.2 Если мы создадим предложение, демонстрирующее преимущества указания авторства Википедии для сторонних агентов повторного использования контента и их конечных пользователей, мы сможем поддержать WME4.1 и WME4.2, предоставив по крайней мере одному новому агенту повторного использования возможность согласиться на участие в тематическом исследовании по указанию авторства или в демонстрации до конца первого квартала.
WE5.4.1 Если мы обеспечим то, что большинство веб-запросов получат уникальный периферийный куки-файл, то обнаружение ботов и поддельных запросов станет более легким.
WE5.4.2 Если мы создадим масштабируемый способ обнаружения известных клиентов, мы сможем вносить исключения в политику общего ограничения количества запросов, применительно к ботам из проверенных источников, и двигаться дальше к системному применению наших правил.
WE5.4.3 Если мы реорганизуем фильтрацию текстовых запросов в сети доставки контента (CDN) на основе подхода «белый список/запрещенный список», мы сможем обеспечить более строгое общее ограничение количества запросов для ботов и оптимизировать фильтрацию трафика.
WE5.4.4 Если мы разработаем единую стратегию измерений, мы сможем оценить многолетнюю стратегию «ответственного использования инфраструктуры» и определить дорожную карту для управления возможностями разработки метрик и отчетности.
WE6.1.1 Если мы перенесем ежедневные сборки на сервер развертывания и добавим обновления образов, запускаемых посредством выбранных внедренческих работ, мы выявим ограничения и установим базовый уровень времени, необходимого для выполнения более непрерывных запусков.
WE6.1.3 Если мы добавим массивы вики-серверов в среду предварительного тестирования, то это позволит группам разработчиков, которые делают производственные сборки и которым требуется несколько вики-проектов для изолированного тестирования исправлений, обрести большую уверенность на этапе подготовки к развертыванию и снизить количество упущенных дефектов.
WE6.2.1 Если мы доработаем и опубликуем наш контрольный список готовности к развертыванию, в котором четко определены предварительные условия для признания сервиса готовым к запуску вместе с задачами самообслуживания, мы согласуем ожидания между инженерами по надежности (SRE) и командами разработчиков, повысив общую операционную эффективность и масштабируемость.
WE6.2.2 Если мы анонсируем создание программной библиотеки на базе Golang или Node.js, реализующей множество трудоемких для разработчиков задач, они в ответ дадут свои отзывы и выразят заинтересованность.
WE6.2.3 Если мы создадим контрольный список/рабочую таблицу, разработчики смогут заранее полностью подготовиться к обзору дизайна сохранения данных.
WE6.3.1 Если в первом квартале мы осуществим запуск для по крайней мере 70 проектов Википедии с низким трафиком, не считая вики-проектов с поддержкой языковых вариантов, мы повысим нашу уверенность в завершающем запуске на десяти самых крупных вики-проектах, что окажет более значительное влияние на количество просмотров страниц, обслуживаемых через Parsoid.
WE6.4.1 Если мы развернем таблицу разделенных ссылок Викисклада на собственном сервере, мы повысим вероятность того, что рост базы данных Викисклада останется стабильным. T398709
WE6.4.2 Если мы (SRE) окажем помощь инженерным командам MediaWiki путем создания документации, подготовки необходимой инфраструктуры (например, пакеты PHP, контейнерные образы), а также предложим направляющее содействие и обратную связь, то они смогут уверенно начать обновление производственных мощностей до PHP 8.3 до начала второго квартала. T360995
WE6.4.3 Если мы будем требовать дополнительный физический фактор аутентификации (аппаратный ключ безопасности) при входе через SSH для пользователей с расширенными системными привилегиями, мы снизим риск того, что скомпрометированный портативный ПК приведет к серьезному нарушению безопасности.
WE6.4.4 Если мы унифицируем наши домены, обслуживая все просмотры страниц на сайтах MediaWiki через каноническое доменное имя, мы снизим сложность платформы и риски поисковой оптимизации (SEO), устранив перенаправления на мобильные поддомены. Критерий завершения: сокращение количества редиректов для мобильных посещений на канонических доменах с 100% до 0%. T214998
WE6.4.5 If the MediaWiki Engineering Team actively monitor and fix issues in MediaWiki related to the PHP 8.3 upgrade, the SRE team will be unblocked to proceed with the PHP 8.3 upgrade by the start of Q2. T360995
Гипотезы по направлению «Сигналы и сервисы данных» (SDS)

[ Ключевые результаты SDS ]

Обсуждение

Краткое наименование гипотезы Формулировка в первом квартале Подробности и обсуждения
SDS1.1.1 Если мы проанализируем эффективность эвристики автоматического обнаружения трафика в наших массивах данных по просмотру страниц, мы сможем разработать метрики качества данных для описания производительности и определить необходимость дальнейших инвестиций в такого рода эвристику.
SDS1.2.2 Если мы перенесем процесс выгрузки XML из текущей инфраструктуры Dumps-1 в конвейер данных, использующий потоки контента MediaWiki, мы сможем гарантировать заданный уровень обслуживания (SLO) и отключить экспорт XML на основе Dumps-1.
SDS1.2.3 Если мы проведем пошаговый анализ и проанализируем заданный уровень обслуживания (SLO) для истории контента MediaWiki и платформы событий/портала событий, мы сможем проверить показатели, клиентов и соответствующие заинтересованные стороны, а также определить улучшения, которые могут потребоваться для SLO, что поможет нам устранить любые пробелы в наших еженедельных гарантиях обслуживания.
SDS2.1.1 Если мы будем тесно сотрудничать с командами, проводящими эксперименты, мы узнаем, как добавить в систему больше самообслуживания в будущем и с какими концептуальными или техническими проблемами они могут столкнуться.
SDS2.1.2 Если мы сможем внедрить более эффективную отладку журналов событий, то продуктовые команды смогут понять, что в рамках их эксперимента сбор данных о событиях происходит в запланированном режиме. Это повысит уверенность инициаторов экспериментов.
SDS2.1.3 Если мы улучшим ведение журналов и прозрачность для системного (xLab) компонента A/Б-тестирования в рамках платформы экспериментов, а также и для связанных с ней частей MediaWiki, мы сможем определить базовые показатели производительности системы и реагировать на относящиеся к экспериментам сбои.
SDS2.1.4 Если мы будем публиковать описания и результаты экспериментов в рамках всей организации раз в месяц (на совещаниях по эксплуатации продуктов, встречах команды дизайнеров и межкомандных презентациях), то мы получим естественное принятие платформы для экспериментов.
SDS2.1.5 Если мы сообщим пользователям, что их инструмент (если он создан в xLab) содержит набор атрибутов, изменяющий категорию риска, мы удержим пользователей инструментов от чрезмерного сбора данных и повысим ясность в отношении того, какая комбинация атрибутов требует проверки конфиденциальности.
Гипотезы по направлению «Аудитории будущего» (FA)

[ Ключевые результаты FA ]

Обсуждение

Краткое наименование гипотезы Формулировка в первом квартале Подробности и обсуждения
FA1.1.1 Если мы (1) предложим собирателям медиа-ресурсов на других платформах (таких как Letterboxd, Goodreads и RateMyMusic) пополнить свои коллекции эксклюзивными знаниями из Википедии или (2) предложим этим собирателям интересные материалы для социальных сетей, то мы сможем увеличить охват Википедии за пределами своей платформы.
FA2.1.1 Если в первом квартале мы нарастим внутренний потенциал по созданию контента коротких видео (за счет увеличения численности команды, проведения аудита и выявления возможностей повышения эффективности текущего производственного процесса), мы сможем действовать с учетом знаний, полученных на основе наполнения, созданного в финансовом периоде 2024-2025 гг., и достичь более высокого охвата для контента, созданного во втором квартале финансового периода 2025-2026 гг., по сравнению с предыдущим годом.
Гипотезы по направлению "Продуктовая и инженерная поддержка" (PES)

[ Ключевые результаты PES ]

Обсуждение

Краткое наименование гипотезы Формулировка в первом квартале Подробности и обсуждения
PES1.1.1 Если мы будем способствовать тому, чтобы xLab, диаграммы и «проверка тона» определили метрики для показателей уровня обслуживания (SLI) в Prometheus, а также внедрили заданные уровни обслуживания (SLO) в Pyrra, мы изучим пределы и экстремальные режимы нашего инструментария в различных сложных сценариях, а также проясним, какие модификации необходимы для шаблона SLO. Это поможет нам осуществлять более полную поддержку шести уровней обслуживания (SLO), запланированных в ключевом результате.
PES1.1.2 Если мы запустим два пилотных набора панелей оповещения о заданных уровнях обслуживания (SLO), мы узнаем, насколько сложно будет внедрить подходящий инструментарий, чтобы владельцы сервисов четко понимали свои обязательства; и также стоит ли нам переходить на другой инструмент, предлагающий только единое отображение конкретного SLO. Одна панель мониторинга будет предназначена для квартальных отчетов (где устанавливается фактическое соглашение об уровне обслуживания для бюджета ошибок). Вторая, малая динамическая панель (называемая «скользящей»), будет предназначена для повседневных операций и оповещений.
PES1.1.3 Если мы продолжим поддерживать группу Абстрактной Википедии в подготовке заданных уровней обслуживания (SLO) для проекта Викифункций, мы научимся определять список целевых параметров SLO (вместе с соответствующими метриками индикаторов уровня обслуживания) для сложной функциональности, которая в настоящее время внедряется в критически важный пользовательский рабочий процесс: рендеринг вики-статей. Мы также научимся делать правильное визуальное отображение соответствующих бюджетов ошибок и оповещать о них с помощью информационных панелей и мониторов, предоставляемых инженерами по надежности (SRE).
PES1.1.4 Если мы поможем группе платформ данных с пересмотром и доработкой заданных уровней обслуживания (SLO) для проекта истории контента MediaWiki, мы узнаем, как использовать SLO для поддержки управления сервисами, когда комбинация сервисов пакетной и потоковой обработки совместно управляется с целью обновления массива данных, сохраняя его целостность и доступность для получающих пользователей.
PES1.2.1 Если мы направим три целевых улучшения в список пожеланий, то это поощрит рост на 30% количества уникальных участников списка пожеланий.
PES1.2.2 Если мы будем сортировать поступающие пожелания и назначать мейнтейнера (например, менеджера по продукту) в течение 72 часов (включая отказ, уточнение, пометку о не поддерживаемых сервисах и прочее) путем перекрестного сопоставления новых пожеланий с таблицей мейнтейнеров и присвоения «категории мейнтейнера» наиболее актуальной продуктовой команде или отдельному лицу, то мейнтейнеры (например, менеджеры по продукту) смогут оценить пожелания и дать ответ в течение 10 дней.
PES1.2.3 Если мы проведем пилотную работу по обнаружению сигналов сообщества в широком смысле, мы сможем в большей степени учесть мнения волонтеров в процессе нашей деятельности по определению приоритетов с учетом интересов сообщества.
PES1.2.4 Если в первом квартале мы опробуем процесс ежеквартального анализа пожеланий и сигналов сообщества с участием трех команд, мы привлечем менеджеров по продуктам к интеграции сигналов сообщества в свои процессы квартального и годового планирования.
PES1.3.1 Если к концу первого квартала мы скоординируем три сессии функционального планирования с отделом коммуникаций и командами по продуктам, чтобы согласовать позиции в отношении сообщений, творческих потребностей и сроков кампании в рамках инициатив WP25, то мы завершим подготовку творческих заданий для всех трех экспериментов этой кампании (25YiR, Easter Eggs, WikiRun).
PES1.3.2 Если мы создадим руководящий комитет с представителями отдела дизайна и разработки функций, мы сможем определить базовые показатели вклада в Codex: осведомленность, использование, качество и количество участия. Результаты оценки по этим базовым показателям помогут нам определить дорожную карту для обеспечения роста и диверсификации базы участников Codex.

Второй квартал

Второй квартал (Q2) годового плана Фонда Викимедиа охватывает период с октября по декабрь.

Гипотезы по направлению «Среда Вики» (WE)

[ Ключевые результаты WE ]

Обсуждение

Краткое наименование гипотезы Формулировка во втором квартале Подробности и обсуждения
WE1.1.1 Если мы проанализируем заранее определённый набор ключевых показателей не ранее чем через 2 недели после начала A/B-теста функции «Paste Check», мы сможем определить, какие аспекты пользовательского опыта (если таковые есть) требуют корректировки или дополнительного изучения, прежде чем можно будет уверенно оценивать влияние функции.
WE1.1.4 Если мы развернём функцию «Reference Check» («Проверку ссылок») в английской Википедии через контролируемый эксперимент, мы увидим увеличение на ≥4% количества конструктивных правок, публикуемых новыми (или относительно новыми) участниками, и узнаем, достаточно ли поддержки среди патрулирующих и модераторов, чтобы расширить использование функции.
WE1.1.7 Если мы проанализируем заранее определённый набор ключевых показателей не ранее чем через 2 недели после начала A/B-теста функции «Tone Check», мы сможем определить, какие аспекты пользовательского опыта (если таковые есть) требуют корректировки или дополнительного изучения, прежде чем можно будет уверенно оценивать влияние функции.
WE1.1.8 Если мы применим модель «Tone Check» к опубликованным статьям, мы сможем определить, удастся ли выявить ≥10 000 случаев проблем с тоном (каждый с вероятностной оценкой 0,8 или выше), достаточных для формирования высококачественного пула рекомендаций (с точностью ≥70%), которые помогут редакторам улучшить стиль и тон статей.
WE1.1.10 Если мы проведём интервью примерно с ~10 опытными участниками английской и французской Википедий, которые создают «AbuseFilters» и другие инструменты (гаджеты, скрипты, шаблоны, уведомления), автоматизирующие процессы патрулирования и модерации, мы сможем выявить не менее 3 закономерностей или потребностей, которые помогут сформировать ценностное предложение для функции «Edit Checks», создаваемой силами сообщества.
WE1.1.11 Если мы проведём опрос среди ≥500 успешных новичков[i] и получим качественные данные, репрезентативные для более широкой группы успешных новичков, мы сможем выявить ≥4 практических инсайта, которые помогут определить приоритетные направления для улучшения процесса вовлечения новичков.
WE1.1.12 Если мы привлечём ≥3 волонтёров, чтобы они оценили ≥30 примерных правок каждый (для каждой из 10 новых языковых версий, куда мы планируем масштабировать «Tone Check»), мы узнаем, насколько часто волонтёры соглашаются с прогнозами модели, и сможем решить, на какие вики стоит выходить с предложением о внедрении «Tone Check».
WE1.1.13 Если функция «Add a Link» («Добавить ссылку») будет масштабирована до 100% новых участников английской Википедии, это улучшит вовлечённость и удержание новичков, что приведёт к увеличению количества конструктивных правок, сделанных новыми участниками, на ≥4%.
WE1.2.3 Если мы уберём требование наличия права «Event Organizer» для использования функции «Event Registration» на малых и средних вики, то к концу финансового года мы увидим как минимум X дополнительных событий, созданных на этих вики.
  • (ожидается уточнение базового показателя и целевого значения).
WE1.2.4 Если мы доработаем MVP функции «Collaborative Contributions» с добавлением как минимум двух улучшений, то количество совместных редактирований, создаваемых через «Event Registration», увеличится.
WE1.2.5 Если в начале второго квартала (Q2) мы определим стратегию внедрения «Event Registration» на Викискладе, мы сможем протестировать её с организаторами хотя бы одной крупной кампании и предоставить возможность использовать функцию пяти локальным организаторам.
WE1.3.3 Если мы запустим эксперимент с новой панелью модератора для новых участников, то 10% из тех, кто посетил её, будут возвращаться к ней две недели подряд.
WE1.4.1 Если мы реализуем улучшения, описанные в T396489, мы сократим количество «медленных» запросов «recentchanges» как минимум на 30% на крупных вики, что позволит команде «Community Tech» внедрить функцию «Watchlist Labels» без перегрузки базы данных «recentchanges».
WE1.4.3 Если мы добавим инструменты на страницах «свежие правки» и «список наблюдения», мы сможем определить базовый показатель того, как часто пользователи переходят по ссылкам на страницы из этих списков.
WE1.5.1 Если мы создадим дашборд для анализа семи показателей, связанных с участниками, и стандартизируем расчёт хотя бы одного из них с использованием dbt, это позволит продуктовым командам, работающим с участниками, самостоятельно получать аналитические данные, а также выработать стандарт хранения логики расчёта метрик.
WE1.5.2 Если во втором квартале (Q2) мы определим, какие действия по модерации включать в определение понятия «модератор», то команда «Movement Insights» сможет в третьем и четвёртом кварталах разработать метрику «Ежемесячно активные модераторы».
WE2.1.3 Если мы изучим опыт участников при создании новых статей и разделов (включая их мотивацию, трудности и реакцию на новые идеи по улучшению поддержки редакторов), мы сможем выявить пользовательские потребности и модели поведения, которые дадут практические инсайты и стратегии для продуктовых, дизайнерских и инженерных команд, чтобы улучшить процесс создания статей.
WE2.2.12 Если мы запустим Викифункции на вики, где уже включён «Parsoid», мы сможем продолжить тестирование того, остаётся ли система производительной и удобной в использовании при всё более широком внедрении.
WE2.2.13 Если мы представим сообществу Викисловаря новую функцию таблиц спряжений, мы получим ценные отзывы об использовании функции и лучше поймём профили наших пользователей, что поможет нам при будущих внедрениях.
WE2.2.14 Если мы изучим, как сообщество использует шаблон «Databox» для заполнения шаблонов-карточек с помощью Викиданных, и исследуем, может ли Викифункции способствовать этому процессу, мы сможем определить первый эксперимент по применению Викифункций в шаблонах-карточках.
WE2.2.15 Если мы повысим осведомлённость сообщества о возможности создавать и переводить сообщения об ошибках в Викифункциях, количество полезных сообщений об ошибках увеличится.
WE2.2.16 Если мы продемонстрируем сообществу доступные семантические функции, количество грамматических функций увеличится на 50%.
WE2.2.17 Если мы создадим специальный компонент для просмотра утверждений Викиданных в Викифункциях, пользователям будет легче понимать получаемые данные и они будут чувствовать себя менее перегруженными.
WE2.2.18 Если нам удастся предотвратить 10-кратные скачки потребления памяти, оркестратор сможет лучше обрабатывать объекты Викиданных, что повысит устойчивость Викифункций как платформы для Абстрактной Википедии.
WE2.2.19 Если мы дадим пользователям возможность делиться прямыми ссылками на конкретные вызовы функций — включая их входные данные — участники смогут проще воспроизводить, проверять и обсуждать поведение функций. Это ускорит отладку, улучшит процессы тестирования и поддержит совместное решение проблем внутри сообщества Викифункций.
WE2.3.1 Если мы окончательно примем решение о создании новой вики и вместе с сообществом выберем её название, мы сможем шире проинформировать заинтересованные стороны о запуске этой новой вики и подготовиться к логистике возможного изменения названия продукта.
WE2.3.2 Если мы определим MVP для прототипа Абстрактной вики, включающий базовые возможности для тестирования наших серверных возможностей и систем генерации естественного языка (NLG), и который позволит нам разрабатывать итеративно, мы сможем спланировать и запустить рабочий прототип в третьем квартале.
WE2.3.3 Если мы начнём обсуждать с сообществом и исследовать возможные варианты пользовательского интерфейса для Абстрактной вики, мы сможем продолжить продвижение проекта в третьем квартале.
WE2.4.1 Если мы соберём примеры использования Викиданных и WDQS от команд WMDE и WMF, мы сможем определить продуктовые требования для улучшения инфраструктуры.
WE2.4.2 Если мы создадим единый отчётный вид с ключевыми показателями эффективности (KPI) и действующими целевыми уровнями обслуживания (SLO) для Викиданных и WDQS, мы сможем сформулировать и отслеживать критерии успеха для улучшений технической инфраструктуры, поддерживающей критически важные сценарии использования Викиданных.
WE2.4.3 Если мы сможем оценить и провести сравнительный анализ альтернативных «Blazegraph» хранилищ с использованием реалистичных производственных критериев в течение квартала, мы сможем принять обоснованное данными решение о миграции и составить конкретную дорожную карту с указанием сроков и необходимых ресурсов.
WE3.1.1 Если мы проведём A/B-тест обновлённой версии функции «Вкладки» (Tabbed browsing), мы увидим увеличение многодневного использования среди пользователей Вкладок на 5%.
WE3.1.3 Если мы предложим участникам новый способ просмотра релевантных изображений внутри статей и протестируем его на части незарегистрированных читателей с помощью A/B-теста на нескольких вики, мы зафиксируем не менее 3% кликов по изображению среди тех, кому показана эта функция.
WE3.1.4 Если мы покажем читателям несколько концепций пдля навигации по сети знаний на вики, мы сможем составить приоритетный список идей для дальнейшей разработки.
WE3.1.5 Если мы предоставим веб-читателям возможность просматривать машинно переведённую версию контента Википедии, отсутствующего на их языке, мы узнаем, увеличится ли их активность на сайте (измеряется как рост взаимодействий со страницами на 3%), а также привлечёт ли это новых читателей на локальные языковые версии и потенциально — новых участников. Эксперимент будет проводиться как контролируемый A/B-тест продолжительностью не более 6 месяцев на 13 языковых версиях Википедии с их предварительного согласия, с использованием открытых сервисов машинного перевода, уже доступных редакторам Википедии.
WE3.1.6 Если мы создадим прототип семантического поиска и внутристраничного Q&A (вопрос-ответ), представленный в виде демо-интерфейса, где можно сравнить текущий подход с новыми экспериментальными, то команды, работающие с читателями, смогут качественно оценить, как каждый из подходов работает в разных пользовательских сценариях, и определить пробелы или возможности для улучшения.
WE3.1.7 Если мы изучим существующие исследования о том, как читатели используют инструменты поиска и навигации в Википедии, а также как они находят знания через внешние поисковики, мы сможем предоставить командам, работающим с читателями, не менее трёх практических рекомендаций для создания MVP в области поиска и обнаружения контента, который будет лучше отвечать ожиданиям и потребностям читателей.
WE3.1.8 Если мы протестируем два прототипа семантического поиска (поиск на естественном языке и Q&A) с внешними участниками, мы узнаем, видят ли пользователи ценность в улучшенных поисковых инструментах, и сможем дать командам, работающим с читателями, рекомендацию, как двигаться дальше в разработке MVP поиска и навигации.
WE3.1.9 Если мы покажем 10–20 случайным читателям высокоточную визуальную концепцию интерфейса для поиска контента с помощью семантического поиска, мы получим положительный отклик на эту функцию и уверенность, необходимую для продолжения разработки MVP поиска и навигации, основанного на коротких текстовых отрывках, написанных людьми.
WE3.1.10 Если мы покажем 10 случайным читателям живой прототип новой функции просмотра изображений в немодерируемом пользовательском исследовании, мы выявим как минимум одно улучшение UX для будущих итераций этой функции.
WE3.1.11 Если мы смягчим соответствие ключевых слов в Поиске, мы сможем лучше поддерживать поисковые запросы на естественном языке и позволим продуктовой команде оценить этот функционал, включить его в приоритизацию и дальнейшую работу в области семантического поиска.
WE3.1.14 If we launch an A/B test of a version of the mobile site which introduces navigation that opens all sections by default, we will see early indicators that signal towards an increase in session length (will report on full A/B test results in Q3) T409163
WE3.2.5 Если мы добавим на Android функцию «Итоги года» (Year in Review), которая покажет вклад участника и будет включать сообщение о пожертвованиях, мы стимулируем новые донорские действия и увидим увеличение использования меню приложения на 5% по сравнению с 2024 годом.
WE3.2.6 Если мы сделаем слайды для доноров в «Итогах года» на iOS более интегрированными и персонализированными, количество пожертвований увеличится на 5% по сравнению с 2024 годом.
WE3.3.3 Если мы добавим в Android-приложение хотя бы один разблокируемый аватар для владельцев аккаунтов — который можно заработать, например, сохранив определённое количество статей, — мы увеличим повторные взаимодействия с этой функцией у авторизованных участников на 10% в течение нескольких дней.
WE3.3.4 Если мы предоставим вошедшим в систему читателям возможность сохранять статьи в приватные списки чтения, вовлечённость на сайте вырастет — это проявится как рост внутреннего переходного трафика на 5% среди читателей, использующих эту функцию, и статистически значимое увеличение вовлечённости среди всех пользователей.
WE3.3.6 Если мы сделаем данные о тематике статей доступными через сервис, соответствующий согласованным требованиям к масштабируемости и надёжности, и выполним все необходимые обновления данных, мы создадим техническую основу для будущих персонализированных функций для читателей, зависящих от этих данных.
WE3.3.7 Если мы используем возможности платформы данных для агрегации персонализированных метрик редакторов и информации об их вкладе и предоставим агрегированные данные через надёжные сервисы с определёнными SLO, мы сможем улучшить будущие версии функций «Итоги года» (WE3.3.1) и «Вклад» (Activity Tab, WE3.3.2).
WE3.3.9 Если мы выпустим функцию «Итоги года» на Android и проведём A/B-тест, предлагая активным участникам награду за создание собственного списка чтения, то увидим рост общей удерживаемости приложения на 1% среди тех, кому была предложена награда, по сравнению с теми, кому её не предлагали.
WE3.3.10 Если мы проведём A/B-тест, требующий наличия учётной записи для просмотра персонализированной статистики чтения в «Итогах года», мы увидим увеличение общего коэффициента удержания на 1% для пользователей, от которых требовалось иметь учётную запись, по сравнению с теми, от кого это не требовалось.
WE3.3.11 Если мы проведём A/B-тест улучшенной версии вкладки «Активность» (Activity tab) на iOS, где будут показаны действия пользователя — чтение, редактирование и другие виды участия, — мы увидим рост повторных посещений вкладки на 5% среди авторизованных пользователей по сравнению с предыдущей версией прототипа.
WE3.4.1 Если мы будем двигаться к гибридной модели развёртывания точек присутствия (PoP/CDN), это позволит нам разворачивать как полноценные, так и мини-PoP (физические и облачные) по мере необходимости, создавая основу для будущего прототипа мини-PoP-развёртывания.
WE3.5.1 Если команды продуктов, технологий и фандрайзинга совместно оценят и задокументируют технические подходы к идентификации доноров в наших платформах, мы сможем предложить краткосрочные и долгосрочные решения, которые сбалансируют конфиденциальность, реализуемость и эффективность. Это общее понимание поможет согласовать принятие решений, обеспечит надёжное распознавание доноров на всех платформах и создаст основу для более целевых экспериментов с функциями, связанными с пожертвованиями.
WE3.6.3 Если мы вовлечём сообщества в обсуждение меняющихся потребностей читателей и трансформации природы знаний в интернете, мы сможем выработать общее понимание того, как лучше служить читателям и совместно решить, стоит ли и как тестировать наши различные идеи (в том числе в областях мультимедиа, поиска, навигации и машинного обучения).
WE3.6.4 Если мы исследуем мотивации, поведение и потребности, стоящие за тем, когда, почему и как читатели используют Википедию и другие платформы знаний, мы сможем предложить приоритетные направления и конкретные инициативы для стратегии по работе с потребителями.
WE3.6.5 Если команды продуктов, технологий и фандрайзинга совместно разработают единую стратегию по диверсификации возможностей для пожертвований на платформах и по признанию читателей-доноров, мы сможем установить согласованные цели и метрики, связанные с нашими стратегиями взаимодействия с пользователями и фандрайзинга.
WE3.6.6 Если мы разработаем единую стратегию измерений, мы сможем оценивать эффективность многоуровневой стратегии по работе с потребителями и определить дорожную карту для дальнейшего развития метрик и отчётности.
WE4.1.1 Если мы создадим прототип минимально жизнеспособного процесса для неэкстренных ситуаций и будем поддерживать итерационную обратную связь с участниками, обладающими расширенными правами, то эти группы поддержат расширение внедрения этого процесса.
WE4.1.3 Если мы обновим 7 разделов Википедии (французский, немецкий, испанский, венгерский, итальянский, польский и португальский) к концу октября, мы завершим первый этап внедрения нового юридического нижнего колонтитула (Legal Footer) в соответствии с требованиями DSA.
WE4.1.4 Если мы внедрим MVP Системы отчётов об инцидентах (Incident Reporting System) как минимум на 15 вики, сосредоточив внимание на крупных и сложных сообществах, мы увидим, что сообщество использует систему по назначению, и тем самым продемонстрируем рабочую модель для сообщений о неэкстренных инцидентах.
WE4.1.5 Если мы разработаем блок-схему процесса для сообщений о случаях злоупотреблений на вики, где ещё не выстроены процедуры их обработки, это будет способствовать внедрению Системы отчётов об инцидентах (Incident Reporting System) на таких вики и позволит участникам получить чёткий и действенный путь обращения за поддержкой.
WE4.2.3 Если мы проанализируем данные пилотного тестирования создания учётных записей с использованием hCaptcha, мы поймём, как работает воронка регистрации, насколько эффективны головоломки и оценки hCaptcha, и получим данные, необходимые для принятия решения о дальнейшем внедрении hCaptcha при создании аккаунтов.
WE4.2.5 Если мы проведём исследования, обсудим с сообществами и изучим технические решения, мы сможем определить набор структурированных причин блокировок, которые можно будет использовать на всех вики Фонда Викимедиа.
WE4.2.6 Если мы разработаем возможность развёртывания кластеров на основе OpenSearch на платформе данных (Data Platform), команды по разработке продуктовых функций смогут создавать системы, интегрирующие эту возможность, обладая при этом большей автономией, устойчивостью и изоляцией от других поисковых систем. Первым и основным потребителем этой системы станет сервис IPoid.
WE4.2.7 Если мы внедрим интеграцию hCaptcha Enterprise на нескольких производственных Википедиях в рамках пилотного проекта, мы сможем собрать данные об эффективности и ценности этого решения в контексте защиты от злоупотреблений, обнаружения ботов, удобства использования и доступности.
WE4.2.8 Если мы доведём прокси hCaptcha до готовности к эксплуатации, улучшив его стабильность и наблюдаемость, мы обеспечим более надёжную работу сервиса на производственных Википедиях в первом квартале.
WE4.2.9 Если мы интегрируем SDK hCaptcha в нативные мобильные приложения, оценим пользовательский опыт и возможность включения проверок hCaptcha в API создания аккаунтов, мы получим достаточно информации для принятия решений о дальнейшем внедрении hCaptcha в процесс регистрации.
WE4.2.11 Если мы задействуем hCaptcha для выявления ботов в сценариях редактирования с повышенным риском, мы увидим, что hCaptcha способна снижать уровень автоматизированных злоупотреблений.
WE4.2.16 Если мы проконсультируемся с соответствующими командами Фонда Викимедиа, мы сможем разработать согласованный план по более детальному управлению доступом пользователей к непубличным данным и поддержать внедрение защитных правил, касающихся таких данных.
WE4.2.17 Если мы проанализируем реальные случаи и опросим чекъюзеров, чтобы выявить как минимум два сигнала возможного злоупотребления на основе прототипа истории редактора, команда по безопасности и целостности продукта сможет с большей уверенностью включить эти сигналы в функцию «Рекомендованные расследования» (Suggested Investigations), зная, что они принесут практическую пользу.
WE4.3.2 Если мы внедрим отпечатки JA4H, которые суммируют поведение HTTP-клиентов, мы сможем лучше выявлять и классифицировать бот-трафик.
WE4.4.1 Если мы внедрим улучшения на основе отзывов пилотных проектов и распространим систему временных аккаунтов на все проекты, мы сможем защитить раскрытие личной идентифицируемой информации (IP-адресов) незарегистрированных участников, сделав их доступными менее чем для 0,1% всех зарегистрированных участников.
WE4.4.2 Если мы будем своевременно и чётко информировать соответствующих участников движения (включая вики сообщества и глобальных функционеров), мы сможем внедрить систему на всех оставшихся вики, сократить объём срочной работы и избежать необходимости отката развёртывания.
WE4.4.5 Если мы снизим сложности для патрулирующих при выявлении злоумышленников, использующих временные учётные записи для вандализма, мы сможем предотвратить рост числа актов вандализма, что будет подтверждено отсутствием увеличения показателя откатов на всех вики с временными учётными записями.
WE4.4.6 Если мы выведем из эксплуатации расширение «LiquidThreads», мы снимем блокирующий фактор для развёртывания временных учётных записей во всех проектах, где это расширение используется.
WE4.6.1 Если мы автоматизируем процесс синхронизации учётных записей в Zendesk при сбросе паролей, это снизит нагрузку на команду доверия и безопасности (T&S) и позволит обрабатывать больше запросов на сброс двухфакторной аутентификации.
WE4.6.3 Если мы разрешим всем участникам с подтверждённым адресом электронной почты включать двухфакторную аутентификацию для своих аккаунтов, но не будем активно продвигать это изменение, нагрузка на службу поддержки по восстановлению доступа останется на приемлемом уровне.
WE4.6.4 Если мы продолжим обновлять пользовательский интерфейс системы двухфакторной аутентификации и добавим поддержку passkeys, больше пользователей зарегистрируют несколько факторов аутентификации и будут лучше защищены от потери доступа к аккаунту.
WE4.6.5 Если мы спроектируем и создадим общий фреймворк для определения требований, которым должны соответствовать члены локальных или глобальных групп, мы сможем использовать этот фреймворк для контроля соблюдения текущих политик участниками группы временных просмотрщиков IP-адресов (temporary-account-ip-viewer).
WE4.6.6 Если мы исследуем, как участники с расширенными правами (UWER) зависят от пользовательских скриптов, мы сможем предложить план — поддерживаемый этим сообществом — для проведения одного или нескольких значимых технических изменений, которые реально повысят безопасность системы пользовательских скриптов.
WE4.6.7 Если мы оценим пользовательский опыт и технические изменения, необходимые для того, чтобы выровнять процесс входа в мобильные приложения с веб-платформой, исследуя альтернативные механизмы вроде OAuth, мы сможем определить целесообразность интеграции в интересах создания более безопасного и согласованного опыта для участников.
WE4.6.8 Если мы будем отслеживать влияние форм Zendesk и MediaWiki, созданных в первом квартале, мы сможем предложить технические улучшения для будущих кварталов, которые позволят лучше автоматизировать остальную часть процесса восстановления аккаунтов.
WE5.1.2b Если мы интегрируем несколько методов идентификации и аутентификации разработчиков в API-шлюз, мы сможем назначать каждому запросу соответствующий лимит частоты (rate limit), правильно определяя, из какой группы участников поступает запрос.
WE5.1.3b Если мы проведём пробный запуск ограничения частоты запросов как минимум на трёх маршрутах REST-шлюза, это позволит нам проверить реализуемость ограничения с точки зрения потребления ресурсов и определить начальный набор лимитов, который можно будет применять с минимальным влиянием на участников.
WE5.1.4b Если мы проверим предложенные механизмы сегментации пользователей API на более обширных наборах данных и вручную проанализируем выделенные группы, мы сможем окончательно определить пользовательские когорты, уточнить применяемые методики расчёта и лучше понять их эффективность.
WE5.1.5 Если мы будем сотрудничать с командой MediaWiki Platform по вопросам идентификации трафика и ограничения частоты запросов, мы сможем развернуть тестовое ограничение частоты в рабочей среде, поддержав команду платформы в создании и внедрении этой возможности.
WE5.2.1b Если мы вовлечём потенциальных пользователей нового инструмента REST API Explorer, это поможет выявить ключевые инсайты об удобстве использования и понять, насколько новый дизайн прост в применении и соответствует ментальной модели разработчиков.
WE5.2.2b Если мы направим Action API через центральный API-шлюз, мы сможем начать систематически измерять трафик и шаблоны использования, чтобы получить аналитические данные, которые помогут принимать дальнейшие решения.
WE5.2.4 Если мы внедрим стандартные шаблоны документации для двух API, мы сможем уточнить рекомендации по содержанию, понять, что необходимо владельцам API для их применения, и оценить объём усилий, требуемых для распространения этих стандартов на остальные документы по API Викимедиа.
WE5.2.5 Если мы проведём эксперимент по определению и применению правил линтинга для спецификаций OpenAPI в REST API MediaWiki, мы продемонстрируем способ программного обеспечения соблюдения стилевых руководств API для повышения качества и согласованности API, публикуемых Викимедиа и сообществами.
WE5.3.1 Если мы расширим и упростим руководства по UX-атрибуции, обновив существующие, мы создадим улучшенный базовый набор правил, готовый для внутреннего тестирования и дальнейшей итерационной доработки перед более широким публичным применением.
WE5.3.1b Если мы опубликуем и будем дорабатывать черновые UX-руководства и демо-версии, мы создадим базовый фреймворк, готовый для внутреннего тестирования и последующего итерационного улучшения перед более широким использованием.
WE5.3.2 Если мы подготовим презентацию, демонстрирующую преимущества указания авторства Википедии для сторонних партнёров, использующих контент, и их конечных пользователей, мы сможем поддержать инициативы WME4.1 и WME4.2, обеспечив согласие как минимум одного партнёра по повторному использованию контента принять участие в тематическом исследовании или демо до конца первого квартала.
WE5.4.2b Если мы создадим масштабируемый способ идентификации известных клиентов, мы сможем разрешать исключения из общих лимитов частоты запросов для проверенных ботов и перейти к системному применению наших правил.
WE5.4.5 Если мы начнём применять лимиты частоты запросов, адаптированные под разные классы индивидуальных клиентов, мы снизим нагрузку от массового сканирования (crawling) на нашу инфраструктуру.
WE5.4.6 Если к концу второго квартала мы классифицируем основные N сканеров как известных ботов, мы сможем ограничить объём ресурсов, который они используют.
WE5.4.7 Если мы утвердим стандартизированные наборы разрешённых размеров миниатюр (thumbnails) в нашей медиа-инфраструктуре и заранее создадим самые ресурсоёмкие из них, одновременно ограничив генерации разных размеров изображений, мы снизим нагрузку на инфраструктуру обслуживания медиа.
WE6.1.2 Если мы добавим wikifarms в среду тестирования перед слиянием (pre-merge testing environment), это позволит командам разработчиков, работающим с производственной средой и требующим нескольких вики, тестировать свои изменения изолированно, повысив уверенность перед выпуском и снизив количество ошибок, ускользнувших от тестирования.
WE6.2.1 Если мы пересмотрим и опубликуем чеклист готовности к продакшну (Production Readiness Checklist), который чётко определяет требования к сервису для признания его готовым к работе, а также задачи, выполняемые самостоятельно, мы согласуем ожидания между командами SRE и разработчиками, повысив общую операционную эффективность и масштабируемость.
WE6.2.2 Если мы объявим о создании библиотек на Golang и Node.js, которые автоматизируют множество рутинных задач для разработчиков, они смогут откликнуться, предоставив обратную связь и проявив интерес.
WE6.2.4 Если мы применим и активно поддержим процесс проектного обзора по устойчивости данных (Data Persistence design review), мы сможем выявить проверенные пути в продакшн.
WE6.3.2 Если мы разработаем новые метрики, улучшим инфраструктуру кэша Parsoid и развернём систему как минимум на двух Википедиях из топ-10, мы сформируем критерии производительности для фреймворка надёжности, что поможет подтвердить нашу готовность к внедрению на других крупных вики и продемонстрировать способность работать с большими объёмами трафика.
WE6.3.3 Если мы реализуем ключевые улучшения поддержки языковых вариантов и успешно развернём Parsoid как минимум на трёх языковых вариантах вики во втором квартале, мы выявим и решим основные технические задачи, необходимые для уверенного внедрения на всех остальных вики.
WE6.4.6 Если команда SRE окажет поддержку инженерным командам MediaWiki — через управление мощностями и трафиком, подготовку и обзор конфигурационных изменений, а также совместное расследование и устранение проблем, — мы совместно завершим обновление PHP до версии 8.3 в продакшне во втором квартале и задокументируем набор рекомендаций, которые помогут минимизировать критические зависимости от SRE при будущих обновлениях. T360995
WE6.4.7 Если мы переведём не менее 90% всех участников с глобальным root-доступом на использование аппаратных SSH-ключей для входа на производственные серверы Викимедиа, мы снизим риск серьёзной утечки безопасности в случае компрометации ноутбука.
WE6.4.8 Если команда разработки MediaWiki будет активно отслеживать и устранять проблемы в MediaWiki, связанные с обновлением PHP, это позволит команде SRE завершить обновление PHP 8.3 к ноябрю 2025 года. T360995
Гипотезы по направлению «Сигналы и сервисы данных» (SDS)

[ Ключевые результаты SDS ]

Обсуждение

Краткое наименование гипотезы Формулировка во втором квартале Подробности и обсуждения
SDS1.2.1 Если мы перенесём процесс создания XML-дампов с текущей инфраструктуры «Dumps 1» на конвейер данных, использующий систему MediaWiki Content Pipelines, мы сможем обеспечить выполнение SLO и отключить XML-экспорт на основе «Dumps 1».
SDS1.2.2 Если мы проведём обзор и проверку SLO для MediaWiki Content History и Event Platform / Event Gate, то сможем уточнить клиентов, метрики и заинтересованные стороны, а также выявить возможные улучшения для этих SLO. Это поможет нам устранить пробелы в еженедельных гарантиях стабильной доставки данных.
SDS1.3.1 Если мы внедрим клиентские сигналы и сравним их с серверными логами webrequest, мы сможем выявить дополнительные паттерны поведения ботов, подлежащие классификации.
SDS1.3.2 Если мы возьмём текущее распределение «боты против людей» как базовый уровень и создадим автоматические оповещения при изменениях в этом распределении, мы сократим время обнаружения новых непредвиденных паттернов автоматизированного трафика с недель до минут.
SDS1.3.3 Если мы автоматизируем механизм восстановления данных (backfill) для webrequest и применим его к логам за май, мы сократим время устранения последующих инцидентов с месяцев до дней и решим проблему «всплеска числа просмотров страниц в мае».
SDS1.3.4 Если мы создадим регулярный, систематизированный процесс внутреннего аудита результатов классификации ботов, это повысит доверие к нашим решениям и позволит предвидеть изменения в паттернах трафика, которые не выявляются автоматически.
SDS1.3.5 Если мы проанализируем базовые клиентские сигналы и включим их в наши эвристические методы, мы сможем выявить дополнительные паттерны ботов в Платформе данных (Data Platform).
SDS1.3.6 Если мы импортируем, проанализируем и включим в наши эвристики репутационные данные Spur.us по IP-адресам, мы сможем выявить дополнительные паттерны ботов в Платформе данных (Data Platform).
SDS1.3.7 Если мы импортируем, проанализируем и интегрируем один сигнал с уровня edge (периферийной инфраструктуры), мы также сможем выявить дополнительные паттерны ботов в Платформе данных (Data Platform).
SDS1.4.1 Если мы подтвердим ранее проведённый анализ тенденций внутри экосистемы Викимедиа — просмотров страниц, активности участников, показателей аудитории и трафика, — мы сможем уверенно поддерживать ключевые тезисы, отражающие важнейшие инсайты движения.
SDS1.4.2 Если мы подтвердим ранее проведённый анализ тенденций внутри экосистемы Викимедиа — просмотров страниц, активности участников, показателей аудитории и трафика, — мы сможем уверенно поддерживать ключевые тезисы, отражающие важнейшие инсайты движения.
SDS2.1.1 Если мы будем тесно сотрудничать с командами, проводящими эксперименты, мы узнаем, как сделать систему более самостоятельной в будущем, и какие концептуальные или технические трудности могут при этом возникнуть.
SDS2.1.2 Если мы реализуем улучшенные средства отладки для eventlogging, команды по продуктам смогут быть уверены, что их эксперименты корректно собирают события, что повысит уверенность владельцев экспериментов в достоверности данных.
SDS2.1.3 Если мы улучшим ведение логов и наблюдаемость для системы A/B-тестирования (xLab) и связанных компонентов MediaWiki, мы сможем установить базовые показатели производительности системы и быстрее реагировать на сбои, связанные с экспериментами.
SDS2.1.4 Если мы будем ежемесячно делиться историями и результатами экспериментов по всей организации (на встречах Product Ops, команды дизайнеров и кросс-командных презентациях), это поможет органично повысить использование платформы экспериментов.
SDS2.1.5 Если мы будем информировать участников о том, что их инструмент, созданный в xLab, содержит набор атрибутов, влияющих на категорию риска, это позволит предотвратить избыточный сбор данных и повысит прозрачность в отношении комбинаций атрибутов, требующих проверки с точки зрения конфиденциальности.
SDS2.1.6 Если Команда роста создаст два примера использования в рамках Experiment Lab (один с A/B-тестом для проверки возможностей сегментации участников, и один с долгосрочной инструментализацией для оценки поддержки KPI-подобных метрик), мы сможем оценить, насколько Experiment Lab удовлетворяет требованиям для замены нашей текущей кастомной системы экспериментов в GrowthExperiments.
Гипотезы по направлению «Аудитории будущего» (FA)

[ Ключевые результаты FA ]

Обсуждение

Краткое наименование гипотезы Формулировка во втором квартале Подробности и обсуждения
FA1.1.4 [Продолжение с прошлого финансового года] Если мы создадим новый опыт взаимодействия с Википедией на платформе Roblox, мы узнаем, может ли это стать эффективным способом познакомить молодую аудиторию (поколение Alpha) с нашим брендом.
FA1.1.2 Если мы создадим центральный хаб для новых проектов Википедии на itch.io, то сможем привлечь аудиторию из более чем 50 заинтересованных не-википедистов, которые будут давать нам обратную связь. Это поможет понять, что работает, а что нет, в игровых форматах.
FA2.2.1 Если мы будем инвестировать в развитие комьюнити-менеджмента на платформах с короткими видео, то к концу второго квартала (декабрь 2025 года) мы увидим 30% квартальный рост доли просмотров от новых зрителей на TikTok. Кроме того, на всех платформах для коротких видео (SFV) мы получим в сумме 50 000 вовлечений (лайков и ответных комментариев) под нашими комментариями к стороннему контенту. Это поможет нам повысить узнаваемость и вовлеченность среди аудиторий, с которыми мы сейчас не взаимодействуем.
FA2.2.2 Если мы разработаем и согласуем внутреннюю стратегию и внешние материалы для программы партнёрств с создателями контента (включая описание нашей ценности для авторов, критерии партнёрства, процесс заключения договоров и формат публикации контента на наших и авторских каналах), мы сможем создать устойчивую стратегию по работе с создателями контента, которая поможет нам выходить на новые аудитории в соцсетях с нашим познавательным контентом.
Гипотезы по направлению «Продуктовая и инженерная поддержка» (PES)

[ Ключевые результаты PES ]

Обсуждение

Краткое наименование гипотезы Формулировка во втором квартале Подробности и обсуждения
PES1.1.5 Если мы добавим целевые показатели уровня обслуживания (SLO) для MediaWiki Content History и Викифункций в систему Sloth/Pyrra, то сможем ввести ещё два новых SLO в продакшен.
PES1.1.6 Если мы протестируем Sloth с ретроактивными данными из существующих SLO, мы поймём, что лучше подходит для нашего подхода с фиксированными окнами ошибок — Pyrra, Sloth или другой инструмент. Это также позволит понять, как поддерживать владельцев сервисов в самостоятельном использовании метрик SLO и как применять их при принятии решений.
PES1.2.4 Если мы проведём пилотный процесс ежеквартального обзора пожеланий и сигналов от сообщества с тремя командами в первом квартале, мы вовлечём продакт-менеджеров в интеграцию сигналов от сообщества в их квартальное и годовое планирование.
PES1.2.5 Если мы добавим возможность фильтрации и сортировки пожеланий в расширении Wishlist, в дополнение к уже внедрённым улучшениям (категоризация по тегам и голосование), эти три улучшения увеличат число уникальных участников в Wishlist как минимум на 30%.
PES1.3.3 Если мы создадим как минимум 5 приятных для участников интерактивных элементов на платформе, которые будут срабатывать в ответ на действия участников, мы определим триггеры для портальной страницы и гаджета Birthday Mode. Тестирование удобства покажет, какие из этих элементов формируют положительные ассоциации с брендом. Эта гипотеза ограничена по времени и должна быть завершена к WikiCon North America в конце октября.
PES1.3.4 Если мы создадим иммерсивный сайт, исследующий историю, настоящее и будущее Википедии, в сотрудничестве с сотрудниками отдела коммуникаций (Comms) и ориентированный на онлайн-аудиторию 18–34 лет в целевых регионах кампании, это поможет сформировать более прочную эмоциональную связь с Википедией через социальные сети и другие онлайн-активности. Это внесёт вклад в ключевой результат (KR) отдела коммуникаций — увеличить присутствие бренда на 10 процентных пунктов, а также позволит понять, повышают ли динамичные форматы контента привлекательность бренда.

Q3

The third quarter (Q3) of the WMF annual plan covers January-March 2026.

Wiki Experiences (WE) Hypotheses

[ WE Key Results ]

Обсуждение

Hypothesis shortname Q3 text Details & Discussion
WE1.1.3 If the Editing Team makes an initial set of edit suggestions available within VE via a URL parameter and invites ≥10 newcomers and patrollers to offer feedback about it, we will learn what improvements would need to be made before running a controlled experiment to evaluate the intervention's impact.
WE1.1.4 If we deploy Reference Check at en.wiki through a controlled experiment, we will see a ≥4% increase in the constructive edits new(er) volunteers publish and learn whether there is sufficient support among patrollers and moderators to enable the feature more widely.
WE1.1.12 If we enable ≥3 volunteers to evaluate ≥30 sample edits each, for each of the 10 new languages we are seeking to scale Tone Check to, we will learn how often volunteers agree with model predictions and be able to decide which new wikis to approach about deploying Tone Check to.
WE1.1.14 If we prompt new(er) volunteers to consider the tone they are writing in when an AI model detects them using non-neutral language, then we will see a ≥4% decrease in the percentage of new content edits new(er) volunteers publish that are reverted on the grounds of WP:NPOV (and related policies).
WE1.1.17 If we develop a task generation engine for the Revise Tone structured task, integrate our recent learnings about which content to include or filter out, and provide pipelines that automatically refresh the task list, we'll enable a qualitative evaluation of the tasks generated and an A/B experiment that tests whether this type of task helps newcomer editors to make more constructive edits.
WE1.1.18 If we analyze a pre-predetermined set of leading indicators ~2 weeks after the start of the Revise Tone Structured Task A/B test, we will be able to identify what – if any – facets of the end-to-end experience need to be adjusted or investigated before we can be confident evaluating the impact of the feature.
WE1.1.19 If we enable people on mobile web to edit any article section, regardless of which edit icon they first tap, then the newcomer mobile edit abandonment rate will decrease by #% because they will be able to more more easily locate the content they tapped edit seeking to change.
WE1.1.20 If the Growth team scales the “Add a Link” task to at least 10 additional Wikipedias, then we can complete leading indicator analysis to confirm that the task is performing as expected and identify any wikis that may require further review.
WE1.1.21 If we deploy the new Add-a-Link model version to both newly onboarded wikis and wikis currently using Add-a-Link, then the Growth team will be able to roll out Add-a-Link as a structured task to wikis where it did not previously exist, and wikis that already had the task will receive an updated model with fresher training data and improved offline performance.
WE1.1.22 If we improve the initial “Welcome to Wikipedia” verification email, the percentage of new accounts that verify their email address will increase. This would allow Growth to re-engage these accounts through follow up emails and ensure they receive talk page notifications.
WE1.1.23 If we prompt readily available GenAI models to generate and rank a set of edit suggestions for a diversified sample of 150 English Wikipedia articles, then we will learn what types of editing tasks these generic models can produce at scale and gain a rough, anecdotal understanding of the usefulness of these suggestions. This early signal will help us assess whether some task types could plausibly be generated at scale with generic models (with or without fine-tuning), or whether they would require more specialized approaches - ultimately helping us validate whether pursuing this "single model many suggestions" direction is worthwhile.
WE1.1.24 If we prompt new(er) volunteers pasting text from an external site to confirm whether they wrote the content they are attempting to add, then we will see a ≥4% increase in the percentage of new content edits new(er) volunteers publish that are reverted on the grounds of WP:COPYVIO (and related policies).
WE1.2.6 If we develop a goal-setting feature via Event Registration, then more collaborations will be created via Event Registration.
WE1.3.3 If we launch an experiment to surface a moderator dashboard to newer editors, 10% of contributors who visit it do so two weeks in a row.
WE1.3.4 If we deploy the Revert Risk filter to 150+ additional Wikipedias that currently lack damaging/goodfaith models, then we will see an increase in moderator patrol counts for contributors who use the personal moderator dashboard compared to those who don't get access to the dashboard.
WE1.5.1 If we implement a dashboard to explore 7 contributor metrics and standardize the calculation of at least one metric using dbt then we can enable contributor product teams to self-serve metric insights and develop a standard for storing metric calculation logic.
WE1.5.3 If Data Engineering productionizes a data product of edit types by the end of Q3, then the 6 moderator actions that are "Complicated" to measure will become "Simple", allowing Movement Insights to define a monthly active moderator metric as a next step.
WE1.5.4 If we produce a prototype dashboard with active moderator metrics that are currently available, then we will be able to produce a full dashboard by end of Q4.
WE1.6.1 If we introduce custom watchlist labels, we expect the labels to be used by 5% of users with more than 100 pages on their watchlist in the first month.
WE2.2.13 If we socialize the availability of the conjugation table function with the Wiktionary community, we will gather early signals about editor understanding and usability that can guide future improvements.
WE2.2.20 If we roll Wikifunctions out to wikis that have Parsoid enabled, we will be able to continue testing whether the system remains performant and usable in increasingly broad rollouts.
WE2.2.21 If we allow a limited set of reentrant functions in the evaluator, it will be possible to increase reliance on evaluated implementations, thereby leveraging the most performant part of the backend.
WE2.2.22 If we write an explicit interpreter for the composition language, the orchestrator will be more performant, and further performance-enhancing features will be easier to implement.
WE2.2.23 If we enable contributors to reuse whole composition blocks across functions, we will reduce repetitive work and significantly speed up the creation of new implementations, especially for similar linguistic functions.
WE2.2.24 If we define a clear documentation structure and entry points, function creators will more easily find relevant guidance and experience less friction when creating functions.
WE2.2.25 If we systematically identify the biggest friction points in the function creation experience, we can surface a small set of high-impact improvements that make creating and iterating on functions more efficient.
WE2.2.26 If we introduce a lightweight, local reference solution (via pop-ups) for Abstract Wikipedia, we can establish an initial citation mechanism to inform whether more complex solutions are necessary.
WE2.3.4 If we build and release an initial version of the Abstract Wikipedia platform, we can demonstrate the technical feasibility of the ecosystem working across multiple languages.
WE2.3.5 If we engage with a small number of under-resourced Wikipedia language communities with a concrete example of abstract content, we can validate whether content created outside their local wiki is acceptable and identify conditions needed for adoption.
WE2.3.6 If we design how Abstract Wikipedia content is surfaced and presented within local Wikipedias, and how local communities make integration decisions, we can socialize the proposal, reach agreement, and confidently plan Q4 development work.
WE2.5.1 If we deploy the Blazegraph candidate replacement in eqiad and augment existing evaluation work with production WDQS traffic-replay analysis, then we will confirm that the new backend performs comparably, supports real-world SPARQL queries, and is ready for limited live-traffic exposure once the surrounding ecosystem (UI, monitoring, onboarding, and real-time index update pipeline) is prepared.
WE2.5.2 If we define access guidelines for the Wikidata platform, we will better be able to control the load put on WDQS servers at the time of our backend migration.
WE2.5.3 If we define a cohort of user personas to test our new backend system, we will be prepared for the pilot and subsequent phases of the Blazegraph cutover.
WE2.5.4 If we produce a migration plan in a single document, we will be able to align upon and drive the execution of all aspects of the migration.
WE2.5.5 If we optimize the Wikidata Revert Risk model for low-latency inference and deploy it in a stable, scalable manner on LiftWing, then the Wikimedia Enterprise team will be able to integrate revert risk signals into their product pipeline, enabling customers to receive timely, high-quality model outputs.
WE3.1.8 If we evaluate 2 semantic search prototypes (natural language search, Q&A) with external participants, we can learn whether users see value in improved search tools, and provide the Readers teams with a recommendation on how to move forward with a search and discovery MVP.
WE3.1.12 If we collect a benchmark dataset consisting of a set of representative queries and annotations of relevant search results, we will be able to perform offline (i.e. without user studies) search evaluation of the quality of search results of different search models.
WE3.1.15 If we test hybrid search MVPs that blend keyword, natural-language, and meaning-based queries, in the Android app, we will rapidly identify the approach and design patterns that increases total search engagement by 10% without a negative impact on satisfaction, latency, or retention
WE3.1.16 If we define requirements for a Q&A model, we will produce model outputs to share with the community for feedback that we can incorporate into a production experiment.
WE3.1.17 If Search provides a production-ready (stable, performant) vector search infrastructure which supports semantic query processing — including a MediaWiki endpoint, then ML and Research will be able to generate embeddings and integrate their models with the system, enabling the MVP’s embedding-powered retrieval.
WE3.1.18 If we deploy a Qwen3 embeddings inference service that is compatible with our existing OpenSearch stack, then Mobile Apps can experiment with generating article-chunk and query embeddings through Qwen3, which should outperform the embeddings produced by OpenSearch’s built-in models.
WE3.3.6 If we make article topic inference data available via a service that meets agreed-upon scalability and availability requirements, plus any necessary data backfills, then we will have established the technical foundation necessary to support upcoming personalized reader experiences that depend on this data.
WE3.4.1 If we work towards a hybrid point of presence (PoP/CDN) deployment, it will allow us to bring up both full PoPs and mini PoPs (physical and cloud) as required, laying the foundation for a prototype mini PoP deployment in the future.
WE3.5.2 If we offer donors a badge acknowledging their status, at least 70% of donors who opt-in will report positive sentiment on a linked survey.
WE3.6.5 If Product & Technology and Fundraising collaborate on a shared strategy to diversify on-platform donation opportunities and steward and recognize readers who donate, we will set clear, aligned goals and metrics tied to our consumer and fundraising strategies.
WE3.6.6 If we develop a unified measurement strategy, we will enable evaluation of the consumers’ multi-year strategy and define a roadmap to guide metric development and reporting capabilities.
WE3.6.7 If we run a secondary A/A test on retention rate for logged-out users, we will begin to establish seasonal trends for retention rate that we can use for future quarters
WE3.6.8 If we systematically compare the information seeking needs and behaviors of 1) new and infrequent English Wikipedia readers and non-readers with those of 2) current English Wikipedia readers by simultaneously surveying both populations, we will be able to identify key insights about the demographic characteristics, online information needs, and online platforms used by these audiences, identifying potential opportunities for growing our readership as well as potential threats to our existing readership.
WE3.8.1 If we add additional modules to the activity tab and scale it to all users, we’ll see a 5% increase in overall iOS app account creation compared to before release
WE3.9.1 If we update the Wikipedia iOS app’s visual foundations, component defaults, and navigation behaviours to align with Apple’s Liquid Glass design language—while clearly defining design and behaviour for high-priority fallbacks across OS versions—then downstream engineering implementation will be clearer, lower-risk, and the app will feel more platform-native when Apple forces user switchover
WE3.10.1 If we user test a design prototype of the Explore Feed built with lightweight personalization, clear freshness cues, and repeatable Wikipedia-native patterns (e.g., topical rabbit holes, time-bound highlights, and interactive elements), casual reader participants will report understanding of the proposed feed’s purpose, reach an “aha” moment faster, and show a stronger intent for daily use. The visual design we recommend moving forward with will be described as digestible and aligned with the Wikimedia movement.
WE4.1.3 If we update 6 Wikipedias (English, French, German, Spanish, Italian, Polish) by the end of Q2, we will complete phase 1 of the new Legal Footer roll-out in response to DSA requirements.
WE4.2.5 If we conduct research, consult with communities, and investigate technical solutions, we will be able to define a set of structured block reasons that can be used across all WMF wikis.
WE4.6.8 If we monitor the impact of the Zendesk and MediaWiki forms we built in Q1, then we can propose technical interventions for future quarters that would better automate the rest of the account recovery process.
WE5.1.3c If we roll out rate limiting to all APIs routed through the gateway, we will be able to reduce the number of anonymous API requests that reach our backend infrastructure, by limiting requests based on user classes that give higher limits to authenticated and community users.
WE5.1.5 If we improve the sustainability and reliability of our OAuth 2.0 implementation, we will be able to convince more developers to use OAuth and support the migration of the Wikipedia mobile apps, by increasing confidence that it can be relied upon for high profile applications.
WE5.1.5b If we improve the developer experience for creating and managing OAuth 2.0 clients, we will be able to increase the number of applications that use OAuth 2.0, by deprecating OAuth 1.0 for new applications and promoting OAuth 2.0 as the preferred option for API authentication.
WE5.2.2c If we reroute all APIs currently going through the API Gateway through the common gateway, we will be able to fully deprecate the historic API Gateway and ensure consistency for all community facing Wikimedia HTTP/web APIs
WE5.2.6 If we introduce access controls to the sitemap API to only allow trusted bots, we can improve strategic alignment and reduce the risk of abusive scraping.
WE5.2.8 If we create dedicated API modules for all API extensions and self-contained functionality within MediaWiki Core, we will enable enforcement for higher quality documentation with independent management and versioning.
WE5.2.9 If we have better separation of concerns for API registration and spec definition processes, we will simplify the complexity of API management and create a better developer experience for API authors.
WE5.2.10 If we conduct a listening tour specifically focused on v2 API consolidation and feature gaps, we will be able to move more quickly with a v2 implementation.
WE5.2.11 If we experiment and establish processes for standardizing documentation currently in the API Portal, we can consolidate sources of information and improve documentation consistency.
WE5.3.1b If we publish and iterate on the draft UX guidelines and demos, we will establish a core framework ready to be internally tested and iteratively refined to be prepared for broader public use.
WE5.3.2b If we establish a partner pilot program to experiment with Wikimedia attribution, we can show mutually beneficial impacts of attribution by reusers to drive engagement and contributions to Wikimedia.
WE5.4.6 If by the end of Q2 we've classified the top N spiders as known bots, we can constrain the amount of resources they're using.
WE5.4.8 If we start enforcing rate limits tailored to different classes of individual clients for media files, we will reduce the burden of crawling on our infrastructure.
WE5.4.9 If we add ip-reputation data on residential proxies to our bot detection, it will improve our ability to block scrapers
WE5.4.10 If we stop allowing generation of non-standard thumbnail sizes, it will reduce the strain on our backend media serving infrastructure
WE5.4.11 If we identify two high-confidence signals from the December 2025 scraping/DDoS incidents and deliver them to SRE, then SRE will be able to develop more effective automated mitigation rules for future similar incidents.
WE5.4.12 If we are able to attest where and from whom a request for an image is originated, we can make more informed decisions about rate-limiting them
WE6.1.2 If we add wikifarms to a pre-merge testing environment this will enable development teams building against production who require multiple wikis to test their patches in isolation giving them greater pre-production confidence and result in fewer defect escapes.
WE6.1.3 If we resolve the top 5 flaky Selenium tests over the next 90 days, we will increase developer confidence in automated browser testing as a valuable part of the pre-deployment workflow.
WE6.2.4 If we apply, and actively support the Data Persistence design review, we may identify paved pathways to production
WE6.2.5 By collaborating with the SLO group and gathering feedback from teams currently working with them, will help us not only identify gaps and improvements for the Production Readiness checklist, but also adapt it in such a way to directly facilitate SLO adoption and onboarding
WE6.2.6 By piloting the production readiness checklist on the hCaptcha proxy service against launch and high-importance items, we will identify untracked technical debt and create a visible work backlog, which will demonstrate the framework's value, while shaping a repeatable process for consistent adoption across services.
WE6.2.7 By collaboratively refining the production readiness checklist with SRE input and contributions, we will ensure it addresses real operational needs, build shared ownership, and create a practical tool that teams see value in adopting.
WE6.2.8 By analysing feedback from our collaboration with the SLO group, hCaptcha proxy pilot, and SRE collaboration, we will identify which checklist items and process steps require clearer guidance or supporting resources, and determine the next steps for streamlining the framework to make adoption achievable before the December break.
WE6.2.9 If we adopt node.js service-utils, we will be able to release, in a tested way, either of: service-mesh routing or OpenTelemetry publishing.
WE6.3.2 If we develop new metrics, improve Parsoid's cache infrastructure, and deploy on two "top-ten" wikipedias, we will develop performance criteria for the confidence framework, which will help validate our readiness for deployment to other large wikis and demonstrate our ability to handle high-traffic volumes at scale.
WE6.3.3 If we implement critical Language Variant support improvements and successfully deploy Parsoid to at least 3 Language Variant wikis in Q2, we will identify and resolve the key technical challenges necessary to confidently roll out to all remaining Language Variant wikis.
WE6.3.4 If we QA, identify, triage, and fix bugs within the reading experience across platforms for Parsoid Read Views, we will maintain the quality of the reading experience and unblock further scaling across wikis
WE6.3.5 If we target a Time To First Byte (TTFB) metric of <= 110% of legacy for parser cache hits and <= 150% of legacy for parser cache misses, we can deploy to all Wikipedias except for Chinese and English by the end of Q3 with no performance complaints. This will help validate our readiness for deployment on English Wikipedia, preparing us to handle high-traffic volumes at scale by understanding our cache capacity.
WE6.4.4 If we unify our domains by serving all page views on MediaWiki sites through a canonical domain, then we will reduce platform complexity and SEO risks by eliminating the mobile-subdomain redirect. Completion is measured by decreasing redirects for mobile visits on canonical domains from 100% to 0%.
WE6.4.7 If we migrate at least 90% of all users with global root access to use a hardware-backed SSH key for accessing Wikimedia production servers, we will reduce the risk that a compromised laptop will cause a severe security breach.
WE6.4.8 If the MediaWiki Engineering Team actively monitors and fixes issues in MediaWiki related to the PHP upgrade, this will enable the SRE team to complete the production PHP 8.3 upgrade by November 2025.
Signals & Data Services (SDS) Hypotheses

[ SDS Key Results ]

Обсуждение

Hypothesis shortname Q3 text Details & Discussion
SDS1.5.1 If we create a regular, operationalized internal audit process for bot classification outputs, we will build trust in our solutions and anticipate changes in traffic patterns that are not automatically detected.
SDS1.5.2 If we deploy a Test Kitchen instrument with 100% sampling and a request identifier, we'll be able to capture all requests regardless of whether or not they sent client-side events and analyze them for bot behavior.
SDS1.5.3 If we analyze the basic client-side signal and incorporate it into our heuristics, we will detect additional bot patterns in the Data Platform.
SDS2.2.4 If Product Safety and Integrity reviews GrowthBook and FerretDB, we will be able to identify, then mitigate and/or address any material risks before production rollout.
SDS2.2.5 If we update Test Kitchen JS and PHP SDKs with methods to log experiment exposure, we will not need to treat all events as exposure events, which will improve performance of experiment assignment queries in GrowthBook and yield more accurate experiment results.
SDS2.4.2 If we safely expand traffic enrolment through monitored stress testing, we will increase statistical power for Reader team experiments, shortening experiment timelines and improving decision confidence.
Future Audience (FA) Hypotheses

[ FA Key Results ]

Обсуждение

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

[ PES Key Results ]

Обсуждение

Hypothesis shortname Q3 text Details & Discussion
PES1.3.5 If we build community configuration for Easter Eggs, and leverage Reader Experience full time for code review, we’ll be able to launch on Feb 15 and track impact of the project.
PES1.3.6 If we create bespoke social media posts for 25 Years of Wikipedia (25YoW), we can achieve similar success with social impressions as Comms’ existing templates, and prove we can support Comms’ by increasing their capacity. Benchmarking will be off of Truth Collective posts about the same project.
PES1.4.1 If we meet with 4-5 teams that are not primarily using Codex (including, but not limited to, teams primarily using OOUI), we will be able to document blockers to those teams adopting Codex for current and future projects.
PES1.4.2 If we make Codex PHP easier to use and stable enough to do a 1.0 release, then teams will adopt Codex PHP for server-generated UIs. This will increase Codex PHP usage from 3 projects to 5.
PES1.5.1 If we upgrade Sloth from a prototype to a replacement for Pyrra, by onboarding existing services, we can converge on a unified set of SLO dashboards, refine our alerts, and streamline the SLO onboarding experience.
PES1.5.2 If we continue to onboard SLI metrics for Wikifunctions and MediaWiki Content History, and check metrics for WikiData Query Service and EditCheck, we will debug issues with both dashboard reporting and service-owner engagement on loud-but-unaddressed SLO reports.

Q4

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

Wiki Experiences (WE) Hypotheses

[ WE Key Results ]

Обсуждение

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

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

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

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

[ SDS Key Results ]

Обсуждение

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

[ PES Key Results ]

Обсуждение

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

[ FA Key Results ]

Обсуждение

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

Совместное планирование (январь 2025 года)

Обновление января 2025 года.

Portrait of Selena

В годовом плане изложены цели и стремления Фонда Викимедиа на предстоящий год. Мы стремимся создать план, который будет одновременно коллективным, амбициозным и реалистичным. Ежегодно мы приглашаем участников делиться своими идеями, целями и конкретными предложениями для формирования плана. Мы собираем эти предложения различными способами: через беседы с сообществами, списки пожеланий от сообществ, такие как серия бесед на Викискладе, на конференциях и через вики-страницы, как эта.

Планируя работу на период с июля 2025 по июнь 2026 года, мы размышляем над тем, как наилучшим образом реализовать наше долгосрочное видение с учётом стремительных изменений в мире, интернете и их влияния на нашу миссию создания и распространения свободных знаний.

Как я уже говорила в прошлом году, нам необходимо сфокусироваться на нашем уникальном преимуществе: способности предоставлять достоверную информацию в условиях растущей дезинформации и недостоверного контента в интернете и на платформах, конкурирующих за внимание новых поколений. Это означает выполнение нашей миссии по сбору и распространению всех человеческих знаний через преодоление информационных пробелов, возникающих из-за неравенства, дискриминации и предвзятости. Наш контент должен сохранять актуальность и востребованность в условиях трансформации интернета под влиянием искусственного интеллекта и иммерсивных технологий. Кроме того, нам необходимо обеспечить устойчивое финансирование Движения, разработав единую стратегию для наших продуктов и фандрайзинга, гарантирующую долгосрочную поддержку нашей работы.

Для определения приоритетных направлений на следующий год мы сформулировали ключевые вопросы и тщательно проанализировали оптимальное распределение наших ограниченных ресурсов для достижения максимального эффекта.

Если вас интересуют конкретные функции или услуги, разрабатываемые Отделом продуктов и технологий на основе указанных приоритетов, в марте вы сможете предоставить обратную связь по конкретным целям и ключевым результатам. (Вот цели и ключевые результаты текущего годового плана для справки.)

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

Мы постоянно собираем информацию по этим вопросам различными методами: через обсуждения в сообществе, сбор данных, исследовательские интервью и другие каналы. Мы не впервые исследуем эти вопросы — над многими из них работа уже ведётся! Мы возвращаемся к этим вопросам и продолжаем их изучение, поскольку они остаются для нас приоритетными на текущем этапе планирования.

Вопросы:

  • Метрики и данные
    • Какие метрики и данные могли бы повысить эффективность вашей редакторской деятельности? Вспомните примеры статистики по редактированию, чтению или организационной работе, которая помогла бы вам лучше планировать время и определять приоритетные задачи. Это может касаться как вашей личной активности, так и работы других участников.
  • Редактирование
    • Что приносит вам наибольшее удовлетворение в процессе редактирования? Какие аспекты этой работы вызывают наибольшие трудности и разочарование?
    • Мы хотим, чтобы участники получали больше отзывов и признания за свою работу, чтобы не было ощущения, что никто не замечает усилий, которые они вкладывают в вики. Какие формы признания и отзывов мотивируют вас продолжать редактирование?
    • Учитывая масштаб вики-проектов, редакторам бывает сложно определить приоритетные направления своей ежедневной работы. Какие инструменты или информация помогли бы вам эффективнее распределять время? Насколько полезным было бы создание персонализированного пространства для поиска новых возможностей, управления задачами и оценки своего вклада?
    • Мы хотим усовершенствовать механизмы совместной работы в вики-среде, чтобы участникам было проще находить друг друга и работать над проектами вместе – будь то работа над текущими задачами, участие в вики-марафонах, в вики-проектах или парное редактирование. Как, по-вашему, мы могли бы помочь большему количеству участников найти друг друга и работать вместе?
  • Чтение/обучение
    • Скорость загрузки вики-страниц существенно различается в зависимости от региона. В каких регионах, по вашему мнению, оптимизация производительности наиболее необходима?
    • Как сделать контент Википедии более привлекательным для нового поколения читателей? Мы уже изучали возможности внедрения интерактивного контента и видео, а в текущем году сосредоточились на диаграммах и новых способах представления существующего контента. Как можно развивать это направление, используя имеющийся контент инновационными способами, характерными для Викимедиа?
  • Модераторы
    • Какие изменения могли бы стимулировать более активное участие сообщества в выполнении ключевых волонтёрских функций, таких как патрулирование и администрирование?
    • Какая информация или контекст относительно правок или пользователей могли бы облегчить или ускорить принятие решений по патрулированию или администрированию?
  • Внешние тенденции
    • Какие значимые изменения вы наблюдаете за пределами Викимедиа? Это могут быть тенденции в технологиях, образовании или способах получения знаний.
    • В каких еще онлайн-сообществах вы участвуете помимо Викимедиа? Чему мы можем научиться из инструментов и процессов, используемых на этих платформах?
    • Как вы применяете инструменты искусственного интеллекта в работе с проектами Викимедиа и за их пределами? Какие возможности ИИ кажутся вам наиболее полезными?
  • Викисклад
    • Какие решения следует принять совместно с сообществом Викисклада для обеспечения устойчивого развития проекта и его вклада в формирование энциклопедических знаний?
  • Викиданные
    • Как бы вы хотели, чтобы Викиданные развивались в будущем? Как они могут быть наиболее полезны для создания достоверного энциклопедического контента?

–– Selena Deckelmann

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