Годовой план Фонда Викимедиа/2024-2025/Ключевые результаты по продуктам и технологиям
Данный документ отображает первую часть ежегодного процесса планирования 2024—2025 гг. для Отдела продуктов и технологий Фонда Викимедиа. Он описывает «цели и ключевые результаты» (OKR) для данного отдела. Это дальнейшее развитие структуры рабочих портфелей (называемых «корзинами»), которая была основана в прошлом году.
.jpg)
В ноябре я вместе с вами обсуждала наиболее критический, по моему мнению, вопрос, стоящий перед движением Викимедиа: как мы можем гарантировать, что Википедия и проекты Викимедиа прослужат многим поколениям? Я хочу поблагодарить каждого, кто потратил время на серьезное рассмотрение этого вопроса и ответил мне напрямую. Теперь, после того как я нашла немного времени для обдумывания ваших ответов, я поделюсь с вами тем, что узнала.
Во-первых, не существует универсальной причины, по которой волонтеры вносят свой вклад. Чтобы лелеять многие поколения волонтеров, мы должны лучше понимать все множество причин, по которым люди тратят свое время на наших проектах. Далее, мы должны фокусироваться на том, что делает нас отличными от других: на нашей способности предоставлять достоверный контент в то время, когда дезинформация и некорректная информация распространяются в интернете и на платформах, борясь за внимание следующих поколений. Это также включает в себя обеспечение выполнения нашей миссии по сбору и предоставлению всему миру суммы всех накопленных человечеством знаний путем расширения охвата недостающей информации, что может быть вызвано неравенством, дискриминацией или предвзятостью. Наш контент также должен приносить пользу и сохранять жизнеспособность в развивающемся интернете, направляемом искусственным интеллектом и расширенными услугами. Также мы должны найти пути устойчивого субсидирования нашего движения путем формирования стратегии для наших продуктов и доходов, чтобы мы могли финансировать эту работу в долгосрочной перспективе.
Данные идеи будут отражены в годовом плане Фонда Викимедиа на период 2024—2025 гг., первую часть которого я сегодня направляю вам в виде проекта целей для нашей работы по продуктам и технологиям. Аналогично прошлому году наш годовой план будет целиком фокусироваться на технологических потребностях нашей аудитории и наших платформ — нам потребуются ваши отзывы для понимания того, что мы уделяем внимание действительно важным проблемам. Эти цели основываются на идеях, которые мы получили от членов сообщества через Обсуждение:2024, через списки рассылки и страницы обсуждений, а также на мероприятиях сообщества, посвящённых стратегии по продуктам и технологиям на следующий год. Вы можете ознакомиться с полным списком предполагаемых целей далее внизу.
«Цель» — это директивное направление высокого уровня, формирующее облик продуктовых и технологических проектов, которые мы планируем на следующий финансовый год. Они намеренно заданы широко, отражая направление нашей стратегии и, что немаловажно, задачи, которые, по нашему мнению, следует особо выделить из всей совокупности рабочих вопросов в следующем году. Мы публикуем это сейчас, чтобы члены сообщества могли повлиять на наше предварительное обсуждение, прежде чем бюджеты и количественные цели на следующий год будут зафиксированы.
Обратная связь
Одной из областей, по которой мы особенно нуждаемся в обратной связи, является наша работа, сгруппированная по направлению «Восприятие вики». «Восприятие вики» — это показатель того, как эффективно мы выполняем свои задачи, совершенствуемся и создаем инновации, и того, как люди непосредственно используют вики-проекты как участники, потребители или благотворители. Это включает в себя работу по поддержке наших ключевых технологий и возможностей, а также обеспечение наших способностей по улучшению опыта редакторов-волонтеров, в особенности пользователей с расширенными правами, посредством более совершенной функциональности и инструментов, перевода на другие языки и обновления платформ.
Вот несколько размышлений по итогам недавних дискуссий по планированию, а также и вопросов для вас, которые могут помочь нам усовершенствовать наши идеи:
- Участие в качестве волонтеров на проектах Викимедиа должно приносить удовлетворение. Мы также думаем, что опыт сотрудничества онлайн должен быть основой того, что побуждает волонтеров приходить снова. Что же является необходимым для волонтеров, чтобы ощутить удовлетворение от редактирования и более эффективно работать вместе для создания контента, заслуживающего доверия?
- Достоверность нашего контента является частью уникального вклада Викимедиа в мировой прогресс, а также и тем, что побуждает людей приходить на нашу платформу и использовать ее содержимое. Что мы можем привнести для стимулирования более быстрого роста объема достоверного контента, в то же время оставаясь в рамках стандартов качества, заданных сообществами на каждом проекте?
- Чтобы поддерживать актуальность и конкурировать с другими большими онлайн-платформами, Фонду Викимедиа необходимо, чтобы новое поколение потребителей ощущало связь с нашим контентом. Что мы можем сделать, чтобы наше содержимое было более доступным для обнаружения и взаимодействия с точки зрения читателей и благотворителей?
- В эпоху распространения онлайн-злоупотреблений, мы должны обеспечить защиту для наших сообществ, платформ и системы обслуживания. Мы также сталкиваемся со все возрастающими обязательствами по соблюдению норм, где мировые политические деятели стремятся задавать рамки конфиденциальности, идентификации и обмена информацией в интернете. Какие усовершенствования наших способностей по противодействию злоупотреблениям помогут нам ответить на эти вызовы?
- MediaWiki, программное обеспечение, позволяющее Википедии функционировать, потребует постоянной поддержки в течение следующей декады, чтобы обеспечить создание, модерацию, хранение, обнаружение и потребление открытого содержимого на многих языках в больших масштабах. Какие решения и усовершенствования платформ мы можем принять для обеспечения устойчивости MediaWiki?
Цели
В настоящий момент публикуются результаты планирования высокого уровня ‒ «Цели».
Следующий уровень — «Ключевые результаты» (KR) для каждой утвержденной цели показаны внизу.
Лежащие в основе каждого ключевого результата «Предположения» также опубликованы ниже и будут обновляться на соответствующих вики-страницах проектов/команд в течение всего года по мере накопления практического опыта.
| Цели по Восприятию Вики (WE) | ||||
|---|---|---|---|---|
| Цель | Область применения | Цель | Обоснование цели | Ответственный исполнитель |
| WE1 | Восприятие участников | Как опытные, так и новые участники объединяются вместе онлайн для создания достоверной энциклопедии с большей степенью легкости и меньшей степенью разочарования. | Чтобы Википедия была полна жизни в течение многих лет, наша деятельность должна осуществляться таким образом, чтобы лелеять многие поколения волонтеров и предоставлять людям возможности для публикации того, что они хотят. Разные поколения волонтеров требуют разных инвестиций ‒ более опытным участникам требуется, чтобы их наделенные полномочиями рабочие процессы оптимизировались и исправлялись, в то время как новоявленным участникам требуются новые способы редактирования, понятные им. Во всех этих поколениях, все участники хотят иметь возможность поддерживать связь и взаимодействовать друг с другом для выполнения наиболее значимой работы. С учетом этой цели мы будем вносить усовершенствования в критические рабочие процессы опытных участников, снижать барьеры для конструктивного вклада новичков, а также инвестировать в способы, посредством которых волонтеры смогут находить друг друга и общаться в рамках общих интересов. | Marshall Miller |
| WE2 | Энциклопедический контент | Сообществам предоставляется поддержка для эффективного восполнения пробелов в знаниях посредством инструментов и систем поддержки с возможностью более простого доступа, адаптации и усовершенствования при обеспечении роста объема достоверного энциклопедического контента. | Энциклопедический контент может расти в объеме и улучшаться посредством постоянной вовлеченности и инноваций. Инструменты и ресурсы (как технические, так и другие), используемые участниками для выполнения их задач, могут стать более доступными для обнаружения и более надежными. Поддержка данных инструментов со стороны Фонда Викимедиа должна улучшиться за счет усовершенствования функциональности в рамках коротких циклов. В виду последних тенденций генерации контента при помощи ИИ и изменения поведения пользователей, мы также изучим предпосылки для значительных изменений (например, Викифункции), которые будут способствовать масштабному росту в области создания и повторного использования контента. Механизмы для изучения пробелов в знаниях должны быть более доступны для обнаружения и планирования. Ресурсы, способствующие росту объема энциклопедического контента, включая родственные проекты, такие как Библиотека Википедии, а также и кампании, должны быть лучше интегрированы в рабочие процессы участников. В то же время методы, используемые для роста, должны иметь защитные механизмы от возрастающих угроз для обеспечения доверия к процессам, оставаясь верными основным принципам энциклопедического содержимого, принятым на проектах Викимедиа.
Аудитория: редакторы, переводчики |
Runa Bhattacharjee |
| WE3 | Восприятие потребителей (читателей и СМИ) | Википедия получает новое поколение потребителей, открывающих для себя приоритетное направление для обнаружения энциклопедического контента, взаимодействия и создания с ним долговременной связи. | Цели:
Удержание существующих и новых поколений потребителей и благотворителей. Повышение актуальности для существующих и новых поколений потребителей посредством облегчения обнаружения контента и взаимодействия с ним. Работа с различными платформами по адаптации нашего опыта и существующего содержимого, чтобы энциклопедический контент исследовался и управлялся новым поколением потребителей и благотворителей. |
Olga Vasileva |
| WE4 | Доверие и безопасность | Усовершенствование нашей инфраструктуры, инструментов и процессов для превентивной подготовки к защите сообществ, платформы и наших обслуживающих систем от различных типов масштабных и направленных злоупотреблений при соблюдении требований развивающейся регуляторной среды. | Некоторые аспекты наших способностей по противодействию злоупотреблениям требуют обновления. Борьба со злоупотреблениями на основе IP-адреса становится менее эффективной; нескольким административным инструментам требуются усовершенствования в области эффективности; нам также требуется сформулировать единую стратегию по борьбе с масштабными злоупотреблениями, использующую различные признаки и механизмы противодействия (капчи, блокировки и т.д.) в совокупности. В течение этого года мы начнем работать над наиболее значительными проблемами в этой области. Далее, эти инвестиции в защиту от злоупотреблений должны быть уравновешены инвестициями в понимание и улучшение состояния сообщества, некоторые аспекты которого включены в различные руководящие требования. | Suman Cherukuwada |
| WE5 | Платформа знаний I (эволюция платформы) | Развитие платформы MediaWiki и ее интерфейсов для более полного удовлетворения ключевых потребностей Википедии. | Платформа MediaWiki была разработана для создания, модерации, хранения, обнаружения и потребления открытого контента на многих языках в больших масштабах. Во второй год Платформы знаний мы более внимательно рассмотрим систему и начнем работу по улучшению платформы для эффективного удовлетворения ключевых потребностей проектов Викимедиа в течение следующей декады, начав с Википедии. Это включает в себя продолжение работ по определению платформы производства знаний, повышение устойчивости платформы, фокусировку на системе расширений/интерфейсов для ясной и упорядоченной разработки функциональностей, а также продолжение инвестиций в обмен знаниями и предоставление людям возможностей участвовать в проекте MediaWiki. | Birgit Müller |
| WE6 | Платформа знаний II (средства разработчика) | Технический персонал и разработчики-волонтеры имеют в наличии инструменты, необходимые для эффективной поддержки проектов Викимедиа. | Мы продолжим начатые работы по усовершенствованию (и масштабированию) рабочих процессов разработки, тестирования и развертывания в продуктовой инфраструктуре Викимедиа и дополним это понятие включив средства для инструментальных разработчиков. Мы также нацелены на повышение наших способностей в плане ответов на часто задаваемые вопросы в контексте рабочих процессов разработки/инженерии и их участников, а также и на предоставление актуальных данных для информированного принятия решений. Частично эта работа включает в себя изучение практик (или отсутствие таковых), которые в настоящий момент являются проблемными для нашей экосистемы. | Birgit Müller |
| Цели по Сигналам и сервисам данных (SDS) | ||||
|---|---|---|---|---|
| Цель | Область применения | Цель | Обоснование цели | Ответственный исполнитель |
| SDS1 | Общие идеи | Наши решения по вопросам поддержки миссии и движения Викимедиа основываются на высокоуровневых метриках и глубоком понимании. | Для эффективного и действенного развития технологий, поддержки волонтеров и отстаивания политики, защищающей и расширяющей доступ к знаниям, нам требуется понимание экосистемы Викимедиа и ориентация на примеры успеха. Что означает использование общего набора метрик, которые являются надежными, понятными и своевременно доступными. Это также означает выявление исследований и знаний, помогающих нам понять суть в основе наших измерений. | Kate Zimmerman |
| SDS2 | Экспериментальная платформа | Менеджеры по продуктам могут быстро, легко и уверенно измерить эффект от внедрения функциональностей продукта. | Для обеспечения и ускорения принятия решений по вопросам разработки функциональностей продуктов на основе данных, менеджерам по продуктам требуется экспериментальная платформа, в которой они смогут описывать функциональности, выбирать типы взаимодействия с аудиториями и измерять результаты. Сокращение времени от запуска до анализа является критичным, так как оптимизация сроков обучения ускорит проведение экспериментов и, в конечном итоге, инновации. Ручная работа и ситуативные подходы к измерениям были признаны барьерами, снижающими скорость. При идеальном сценарии менеджеры по продуктам могут перейти от запуска эксперимента к обнаружению результатов с минимальным ручным вмешательством инженеров и аналитиков или вообще без такового. | Tajh Taylor |
| Цели по Аудиториям будущего (FA) | ||||
|---|---|---|---|---|
| Цель | Область применения | Цель | Обоснование цели | Ответственный исполнитель |
| FA1 | Тестирование гипотез | Предоставление рекомендаций Фонду Викимедиа по вопросам стратегических инвестиций, помогающих нашему движению работать с новыми аудиториями в изменяющемся интернете, которые основываются на экспериментальных знаниях, уточняющих наше понимание процесса обмена и потребления знаний в сети. | В силу постоянных изменений в технологиях и онлайн-поведении пользователей (например, рост предпочтений в получении информации посредством социальных приложений, популярность коротких образовательных видео, развитие генеративного ИИ), перед движением Викимедиа стоят вызовы, связанные с привлечением и удержанием читателей и участников. Эти изменения также порождают возможности работы с новыми аудиториями посредством создания и продвижения информации новыми способами. Тем не менее мы как движение не имеем четкой и информированной картины относительно выгод и компромиссов от различных потенциальных стратегий, которые мы можем принять для решения проблем или использования новых возможностей. Например, должны ли мы...
Для того чтобы движение Викимедиа стало проектом на многие поколения, мы будем проверять гипотезы для лучшего понимания и выработки рекомендаций – как для Фонда Викимедиа, так и для движения Викимедиа – относительно перспективных стратегий привлечения и удержания аудиторий будущего. |
Maryana Pinchuk |
| Цели по Продуктовой и инженерной поддержке (PES) | ||||
|---|---|---|---|---|
| Цель | Область применения | Цель | Обоснование цели | Ответственный исполнитель |
| PES1 | Эффективность работы | Улучшить работу Фонда в плане ускорения, оптимизации затрат и повышения эффективности. | В рамках своей обычной работы наши сотрудники делают большой вклад, чтобы наши процессы были быстрее, оптимальнее по затратам и эффективнее. Данная цель выделяет конкретные инициативы, которые (а) приведут к значительным достижениям в области ускорения, оптимизации и повышения эффективности и (b) обеспечат скоординированные усилия по изменению формальных и неформальных практик в Фонде.
В сущности, ключевые результаты, включенные в эту цель, являются самыми сложными и самыми благоприятными улучшениями, которые мы можем привнести в этом году в области операционной эффективности работы применительно к нашим продуктам и технологиям. |
Amanda Bittaker |
Ключевые результаты
«Ключевые результаты» (KR) для каждой конечной цели приведены здесь. Они соответствуют каждой из целей, указанных выше.
Лежащие в основе «Гипотезы» для каждого KR опубликованы ниже на этой странице и будут обновляться на соответствующих вики-страницах проекта/команды в течение года по мере извлечения уроков.
| Ключевые результаты по Вики-опыту (WE)
[ Цели ] | |||
|---|---|---|---|
| Вкратце о ключевом результате | Текст ключевого результата | Контекст ключевого результата | Владелец |
| WE1.1 | Разработать или улучшить общий рабочий процесс, который поможет вкладчикам с общими интересами общаться друг с другом и вносить вклад совместно. | Мы считаем, что пространства для сообщества и взаимодействие в вики, делают людей счастливее и продуктивнее в качестве вкладчиков. Кроме того, пространства для сообщества помогают внедрять и наставлять новичков, улучшают способы внесения вклада и помогают устранить недостатки в знаниях. Однако существующие ресурсы, инструменты и пространства, поддерживающие взаимодействие людей в вики-пространствах, находятся на низком уровне и не отвечают тем вызовам и потребностям большинства редакторов, у которых сегодня оно есть. Между тем, работа команды по «кампаниям» продемонстрировала, что многие организаторы стремятся внедрять и экспериментировать новые инструменты со структурированными рабочими процессами, которые помогают им в работе с сообществом. По этим причинам, мы хотим сосредоточиться на поощрении чувства сопричастности среди участников вики. | Ilana Fried |
| WE1.2 | Конструктивная активация: Широкое внедрение вмешательств, которые, как было показано, в совокупности вызывают относительное увеличение на 10% (в годовом исчислении) на мобильном вебе и относительное увеличение на 25% (в годовом исчислении) для iOS-новичков, которые публикуют ≥1 конструктивную правку в основном пространстве имён на мобильных устройствах, согласно измерениям контролируемых экспериментов.
Note: this KR will be measured on a per platform basis. |
Нынешний опыт редактирования полной страницы требует слишком много контекста, терпения, проб и ошибок, чтобы большинство новичков смогли внести конструктивный вклад. Чтобы поддержать новое поколение добровольцев, мы увеличим количество и доступность небольших, структурированных и более ориентированных на конкретные задачи рабочих процессов редактирования (например, Проверка правки и Структурированные задачи).
Примечание: Базовые показатели будут установлены только к концу четвертого квартала текущего фискального года, после чего наш целевой процентный показатель KR (ключевой результат) также будет установлен. |
Peter Pelberg |
| WE1.3 | Повысить удовлетворённость пользователей по 4 модерированным продуктам на 5 п.п. у каждого. | Редакторы, с расширенными правами, используют широкий спектр существующих функций, расширений, инструментов и кодов для выполнения задач модерирования в проектах Викимедиа. В этом году мы хотим сосредоточиться на улучшении этих инструментов, а не для проектов по созданию новых функций в этой области. В течение года мы планируем внедрить ряд продуктов и хотим внести существенные улучшения в каждый из них. Таким образом, мы надеемся улучшить качество модерирования контента в целом.
Мы определим базовые показатели для общих инструментов модератора, на которые мы можем ориентироваться в этом рабочем потоке, чтобы определить рост удовлетворённости каждым инструментом. Список пожеланий сообщества будет существенным фактором, способствующим принятию решения о приоритетах для этого KR. |
Sam Walton |
| WE2.1 | К концу второго квартала организаторы, участники и организации будут иметь 3 доступные и релевантные отправные точки для расширения охвата содержимого в ключевых тематических областях, а именно: гендер (здоровье женщин, биографии женщин) и география (биоразнообразие). | Цель этих KR (ключевых результатов) — улучшить освещение темы и сократить существующие пробелы в знаниях. Мы установили, что сообщества получают выгоду от эффективных инструментов в сочетании с кампаниями, которые направлены на повышение качества содержимого в наших проектах. В этом году мы хотим сосредоточиться на усовершенствовании существующих инструментов и экспериментах с новыми способами определения приоритетов в ключевых тематических областях, которые устраняют пробелы в знаниях. | Purity Waigi & Fiona Romeo |
| WE2.2 | Внедрение и тест двух рекомендация к концу второго квартала, как социальной, так и технической, для поддержки внедрения языков в небольших языковых сообществах, с оценкой для анализа отзывов сообщества. | Википедия существует примерно на 300 языках. И все же есть гораздо больше языков, на которых говорят миллионы людей, но на которых нет Википедии или вообще нет Вики-сайтов. Это препятствует реализации нашего видения: «каждый человек обладает свободным доступом ко всем накопленным человечеством знаниям». Инкубатор Викимедиа - это место, где потенциальные вики-проекты на новых языках могут быть созданы, написаны, протестированы и подтверждены тем, что они достойны размещения на ресурсах Фонда Викимедиа. Инкубатор был запущен в 2006 году с ввидением на то, что его пользователи будут обладать предварительными знаниями в области редактирования Вики. Эта проблема усугубляется тем фактом, что этот процесс, как предполагается, в основном выполняется людьми, которые являются новичками и наименее опытными в нашем движении. Хотя с тех пор редактирование вики-проектов Викимедиа значительно улучшилось, Инкубатор не получал этих обновлений из-за технических ограничений. В настоящее время на то, чтобы вики-проект вышел из Инкубатора, уходит несколько недель, и каждый год создается всего около 12 вики-проектов, что свидетельствует о существенном ограничении.
Существующие исследования и материалы выявили технические проблемы на каждом этапе создания языкового проекта, в том числе, при добавлении новых языков в Инкубатор, сложности при разработке и проверке контента, а также медленный процесс создания вики-сайта, когда язык выходит из Инкубатора. Каждый этап является медленным, более ручным и сложным, что указывает на необходимость улучшения. Решение этой проблемы позволит быстрее и проще создавать вики-сайты на новых языках и позволит большему числу людей делиться знаниями. Различные стороны, существующие исследования и ресурсы выявили предлагаемые рекомендации, как социальные, так и технические. В этом ключевом результате предлагается протестировать две рекомендации, как социальные, так и технические, и оценить отзывы от сообщества. |
Satdeep Gill & Mary Munyoki |
| WE2.3 | К концу второго квартала, две новые функции помогут вкладчикам добавить исходные материалы, соответствующие основным принципам проекта, а 3-5 партнеров предоставят исходные материалы, которые устранят языковые и географические пробелы. | Чтобы расширить доступ к качественным исходным материалам, необходимым для устранения стратегических пробелов в контенте, мы будем:
|
Fiona Romeo & Alexandra Ugolnikova |
| WE2.4 | К концу второго квартала, включить «Викифункции» в test2wiki, чтобы обеспечить более масштабируемый способ наполнения новым содержимым. | Чтобы эффективно сократить пробелы в наших знаниях, нам необходимо усовершенствовать рабочие процессы, способствующие масштабируемому увеличению количества качественного контента, особенно в небольших языковых сообществах. | Amy Tsay |
| WE2.5 | By the end of Q4, support organizers, contributors, and institutions to increase the coverage of quality content in key topic areas i.e. Gender (women's health, women's biographies), and Geography (biodiversity) by 138 articles through experiments. | A direct followup to WE2.1, this KR is about improving topic coverage towards reducing existing knowledge gaps. We’ve established that communities benefit from effective tools paired with campaigns targeted at increasing the quality of content in our projects. This year we want to focus on improving existing tools and experimenting with new ways of prioritizing key topic areas that address knowledge gaps. |
Purity Waigi & Satdeep Gill |
| WE3.1 | Разместить два управляемых, доступных и ориентированных на сообщество процесса опыта просмотра и обучения на конкретные вики-сайты, с целью увеличения числа удержанных пользователей на 5%, которые вышли из системы. | Этот ключевой результат направлен на то, чтобы привлечь внимание нового поколения читателей к нашему веб-сайту, позволить им установить прочную связь с Википедией, предоставляя читателям возможность легче находить интересующий их контент и узнавать из него. Это будет включать в себя изучение и разработку новых, персонализированных и управляемых сообществом возможностей просмотра и обучения (например, каналы с актуальным контентом, рекомендации и предложения по тематическому контенту, возможности изучения контента, управляемые сообществом, и т.д.).
Мы планируем начать с этого финансового года серию экспериментов с просмотром веб-страниц, чтобы определить, над какими из них мы хотели бы работать для последующего использования в производстве и на какой платформе (веб, приложения или в обеих). Затем мы сосредоточимся на масштабировании этих экспериментов и тестировании их эффективности с точки зрения увеличения удержания в работе. Наша цель к концу года — запустить как минимум два проекта на соответствующих вики-проектах и точно измерить 5%-ное увеличение числа читателей, участвующих в этих проектах. Чтобы добиться оптимальной эффективности в достижении этого показателя, нам потребуется возможность «A/B» тестирования с участием пользователей, вышедших из системы, а также инструментов, способный измерять удержание читателей. Нам также могут потребоваться новые «API» или сервисы, необходимые для представления рекомендаций и других механизмов контроля. |
Olga Vasileva |
| WE3.2 | Увеличить на 50% количество донаций через точки связи, помимо ежегодных баннеров и обращений по электронной почте на каждой платформе. | Наша цель — обеспечить разнообразие в источниках дохода, учитывая при этом наших существующих доноров. Основываясь на отзывах и данных, мы хотим увеличить количество пожертвований, выходящих за рамки методов, на которые Фонд опирался в прошлом, в частности, на ежегодных рекламных кампаний посредством банеров. Мы хотим показать, что, инвестируя в более интегрированный донорский опыт, мы можем поддерживать нашу работу и расширять наши возможности, предоставляя альтернативу донорам и потенциальным донорам, которые не реагируют на призывы банеров. 50 % — это первоначальная оценка, основанная на снижении видимости кнопки «пожертвования» в Веб версии проектов в результате включения «Вектор 2022» и увеличении количества пожертвований в рамках тестового проекта «2023—2024 финансовых годов» в аппликации Википедии для улучшения взаимодействия с донорами (пожертвования увеличилось на 50,1 %). Оценка этого показателя в разбивке по платформам поможет нам понять тенденции развития платформ и определить, следует ли применять различные тактики в будущем, основываясь на различиях в поведении аудитории платформы. | Jazmin Tanner |
| WE3.3 | К концу второго квартала 2024–2025 года добровольцы начнут преобразовывать устаревшие графики в новое расширение графиков в рабочих статьях Википедии. | The Graph extension has been disabled for security reasons since April 2023, leaving readers unable to view many graphs that community members have invested time and energy into over the last 10 years. Data visualization plays a role in creating engaging encyclopedic content, so in FY 2024-25, we will build a new secure service to replace the Graph extension that will handle the majority of simple data visualization use cases on Wikipedia article pages. This new service will be built in an extensible way to support more sophisticated use cases if WMF or community developers choose to do so in the future. We will know we’ve achieved success when community members are successfully converting legacy graphs and publishing new graphs using the new service. We will determine which underlying data visualization library to use and which graph types to support during the initial phase of the project. |
Christopher Ciufo |
| WE3.4 | Develop the capability model to improve website performance through smaller scale cache site deployments that take one month to implement while maintaining technical capabilities, security and privacy. |
The Traffic team is responsible for maintaining the Content Delivery Network (CDN). This layer caches frequently accessed content, pages, etc, in memory and on disk. This reduces the time it takes to process requests for users. The second bit is storing content closer to the user in a physical sense. That reduces the time it takes for data to reach the user (latency). Last year, we enabled one site in Brazil meant to reduce latency in the Southern American region. Setting up new data centers would be great but it is expensive, time consuming, and requires a lot of work to get done – for example, last year’s work spanned the full year. We would love to have centers in Africa and Southeast Asia, and we would love to have them all around the world. Our hypothesis is to spin up smaller sites in other places around the world where traffic is lower. These would require fewer servers, of not more than four or five servers. This reduces our cost. It would still help us reduce latency for users in these regions, while being more lightweight in terms of time and effort to maintain them. |
Kwaku Ofori |
| WE3.5 | By the end of Q3 2024-25, interested volunteers from any Wikipedia can create charts and the task force successfully hands off maintenance to the Reader Experiences group. |
The Chart extension is live in production and enabled for a select list of pilot wikis (itwiki, svwiki, hewiki). The goal of the pilot is to uncover early bugs and usability issues before we scale up the rollout to more wikis. The project mandate includes providing a successor to the graph extension on all wikis, and there is more work to enable that. The task force is also temporary, meaning the maintenance and any future feature development need to be handed off when the project winds down. |
Chris Ciufo |
| WE4.1 | К третьему кварталу подготовить предложение по трем мерам противодействия домогательствам и вредоносному контенту, основанное на данных и соответствующее меняющейся нормативной среде. | Обеспечение безопасности и благополучия пользователей является основной обязанностью онлайн платформ. Во многих юрисдикциях действуют законы и регуляции, которые требуют от онлайн платформ принимать меры против домогательств, кибербулинга и другого вредоносного контента. Несоблюдение этих требований может привести к юридической ответственности платформ и санкциям регулирующих органов.
На данный момент мы не очень хорошо представляем себе, насколько серьезны эти проблемы и каковы их причины. Мы в значительной степени полагаемся на неофициальные данные и ручные процессы, которые подвергают нас как юридическим рискам, так и другим далеко идущим последствиям: недооценке проблемы, обострению ущерба, нанесению ущерба репутации и подрыву доверия пользователей. Нам необходимо сформировать устойчивую культуру оценки случаев домогательств и вредоносного контента и активно внедрять меры противодействия. |
Madalina Ana |
| WE4.2 | Разработать к третьему кварталу как минимум два сигнала для использования в рабочих процессах по борьбе со злоупотреблениями, чтобы повысить точность действий в отношении злоумышленников. | Вики-проекты в значительной степени полагаются на блокировку IP адресов, как на механизм предотвращения вандализма, спама и злоупотреблений. Но IP адреса становятся все менее полезными в качестве стабильных идентификаторов отдельных лиц, а блокировка IP адресов оказывает непреднамеренное негативное воздействие на добросовестных пользователей, которые используют тот же IP адрес, что и злоумышленники. Сочетание снижения стабильности IP адресов и нашей сильной зависимости от блокировки IP адресов приводит к снижению точности и эффективности поиска злоумышленников в сочетании с увеличением уровня сопутствующего ущерба для добросовестных пользователей. Поэтому мы хотим видеть противоположную ситуацию: снижение уровня сопутствующего ущерба и повышение точности мер по смягчению последствий, направленных против злоумышленников.
Чтобы лучше поддерживать работу функционеров по борьбе со злоупотреблениями и предоставить базовые функции для повторного использования в существующих (напр., «CheckUser», “Special:Block») и новых инструментах, в этом ключевом результате мы предлагаем изучить способы надежной связи лиц с его действиями (смягчение последствий использования нескольких учетных записей) и объединить существующие сигналы (например, IP адреса, история учетной записи, атрибуты запросов), чтобы обеспечить более точную идентификацию действий злоумышленников. |
Kosta Harlan |
| WE4.3 | Снизить эффективность крупномасштабных атак на 50%, если измерять время, необходимое нам для адаптации наших мер и объем трафика, который мы можем поддерживать при моделировании. | Развитие интернета, включая рост числа крупномасштабных ботнетов и участившиеся атаки, привели к тому, что наши традиционные методы ограничения масштабных злоупотреблений системой устарели. Такие атаки могут сделать наши сайты недоступными, перегрузив нашу инфраструктуру запросами, или подорвать способность нашего сообщества бороться с масштабным вандализмом. Это также создает неоправданную нагрузку на наших редакторов с расширенными правами и наше техническое сообщество.
Нам срочно необходимо улучшить нашу способность автоматически обнаруживать, противостоять и уменьшать или останавливать такие атаки. Чтобы оценить наши улучшения, мы не можем полагаться исключительно на частоту/интенсивность реальных атак, поскольку мы зависели бы от внешних действий и было бы трудно получить четкую количественную картину нашего прогресса. Настроив несколько имитируемых атак различного характера/сложности/продолжительности на нашу инфраструктуру и проводя их квартально, мы сможем протестировать наши новые мера противодействия, не подвергаясь атаке, так и объективно отчитываться о наших улучшениях. |
Giuseppe Lavagetto |
| WE4.4 | Launch temp accounts to 100% of all wikis. | Temporary accounts are a solution for complying with various regulatory requirements around the exposure of IPs on our platform on various surfaces. This work involves updating many products, data pipelines, functionary tools, and various volunteer workflows to cope with the existence of an additional type of account. | Madalina Ana |
| WE5.1 | К концу третьего квартала завершить как минимум 5 мер, направленных на повышение устойчивости платформы. | Устойчивое развитие платформы «MediaWiki» для нас это постоянное достижение, важное для нашей способности измерять, повышать или избегать снижения удовлетворенности разработчиков и расширять наше техническое сообщество. Это трудно измерить и зависит от технических и социальных факторов. Однако мы обладаем негласной информацией о конкретных областях улучшений, которые имеют стратегическое значение для устойчивого развития. Запланированные мероприятия могут помочь повысить устойчивость и удобство обслуживания платформы или избежать ее деградации. Мы планируем оценить результаты этой работы в четвертом квартале и подготовить рекомендации по достижению целей устойчивого развития в будущем. Примерами мер по обеспечению устойчивости являются: упрощение сложных областей кода, которые являются ключевыми для «MediaWiki», но лишь несколько людей знает, как это работает; расширение использования инструментов анализа кода для повышения качества нашей кодовой базы; оптимизация таких процессов, как расфасовка и создание. | Mateus Santos |
| WE5.2 | Определить ко второму кварталу и завершить к четвертому одно или несколько интервенций по развитию программных интерфейсов экосистемы «MediaWiki», чтобы обеспечить независимую, простую и устойчивую разработку функций. | Основная цель ключевого результата 5.2 — улучшить и прояснить взаимодействие между основной платформой «Mediawiki» и её расширениями, внешним видом и другими частями. Наша цель — внести функциональные улучшения в архитектуру «Mediawiki», которые обеспечат практическую модульность и удобство обслуживания, что упростит разработку расширений, а также повысит требования, вытекающие из более широкого видения продукта «Mediawiki». Работа также направлена на информирование о том, что должно существовать (или нет) в ядре, расширениях или интерфейсах между ними. Год будет разделен на два этапа: 5-месячный этап исследований и экспериментов, который послужит основой для второго этапа, на котором будут осуществлены конкретные меры. | Jonathan Tweed |
| WE5.3 | К концу второго квартала завершить одну инициативу по сбору данных и один эксперимент по повышению производительности, чтобы проинформировать о последующих изменениях в продукте и платформе и использовать возможности, открывающиеся благодаря моделированию страницы «MediaWiki», как композиции структурированных фрагментов. | Основная цель здесь - дать разработчикам и менеджерам по продуктам возможность использовать новые возможности платформы «MediaWiki» для осуществления текущих и будущих потребностей в энциклопедическом контенте, предлагая новые продукты, которые в настоящее время трудно осуществить, а также повышая производительность и устойчивость платформы.
В частности, на уровне платформы «MediaWiki» мы хотим изменить модель обработки «MediaWiki» от рассмотрения страницы как монолитной единицы к рассмотрению страницы как совокупности структурированных элементов контента. Основанные на «Parsoid» модели чтение контента, интеграция Викиданных и Викифункций в вики-проекты — все это безусловные шаги в этом направлении. В рамках этого проекта мы хотим более целенаправленно экспериментировать и собирать данные для обоснования будущих мер, основанных на этих новых возможностях, чтобы гарантировать, что мы сможем достичь желаемого эффекта от инфраструктуры и продукта. |
Subramanya Sastry |
| WE5.4 | Execute the MediaWiki release with a new process that synchronizes with PHP upgrades by Q4. | The MediaWiki software platform relies on regular updates to the next PHP version to remain secure and sustainable, which is a pain point in our process and important for the modernization of our infrastructure. At the same time, we regularly release new versions of the MediaWiki software, which e.g. translatewiki.net depends on, the platform used to translate software messages for the Wikimedia projects. Synchronizing the PHP upgrades with the release process ensures we are not staying behind on PHP versions. This will improve the maintenance and security of the MediaWiki platform and developers’ experience. |
Mateus Santos |
| WE6.1 | Решить 5 вопросов, чтобы обеспечить эффективность и обоснованные решения по рабочим процессам и услугам разработчиков и инженеров и сделать соответствующие данные доступными к концу четвертого квартала. | «Все неоднозначно» — частый ответ на вопросы типа «какие хранилища используются для материалов Викимедиа». В этом ключевом результате мы рассмотрим некоторые из наших «вечнозеленых» ответов в области производительности и опыта инженеров — повторяющиеся вопросы, которые кажутся простыми, но на которые трудно ответить, вопросы, на которые мы можем ответить, но данные недоступны и требуют специальных ответов от экспертов в данной области, или вопросы, на которые сложно ответить по причине недостатка в процессе или по другим причинам. Мы определим, что означает «решение» для каждого из вопросов: для некоторых это может означать просто сделать доступными существующие точные данные. Для решения других вопросов потребуется больше времени на исследования и разработку. Главная цель всей работы — сократить время, разные приемы и усилия, необходимые для получения информации о ключевых аспектах работы разработчиков и дать нам возможность усовершенствовать рабочие процессы и услуги инженеров и разработчиков. | [TBD] |
| WE6.2 | К четвертому кварталу усовершенствовать существующий проект и провести как минимум два эксперимента, направленных на создание удобных в обслуживании целевых сред, что позволит нам перейти к безопасной полунепрерывной доставке. | Разработчики и пользователи полагаются на бета-кластер Викимедии (beta), которая позволяет выявлять ошибки до того, как они повлияют на пользователей в процессе разработки. Со временем, возможности бета-тестирования расширились и вступили в противоречие — они слишком разнообразны, чтобы уместиться в общей среде. Мы усовершенствуем одну из существующих альтернативных сред и проведем эксперименты, направленные на замену единственной высокоприоритетной задачи тестирования, которая в настоящее время выполняется в бета-версии, на поддерживаемую альтернативную среду, которая лучше соответствует потребностям каждого варианта использования. | Tyler Cipriani |
| WE6.3 | Develop a Toolforge sustainability scoring framework by Q3. Apply it to improve at least one critical platform aspect by Q4 and inform longer-term strategy. | «Toolforge», ключевая платформа для инструментов, созданных добровольцами Викимедиа, играет решающую роль во всем, от редактирования, до борьбы с вандализмом. Наша цель - повысить удобство использования «Toolforge», снизить барьеры для внесения вклада, улучшить практику сообщества и способствовать соблюдению установленных правил. С этой целью ко второму кварталу мы внедрим систему оценки устойчивости платформы «Toolforge», уделяя особое внимание техническим и социальным аспектам. Используя эту систему в качестве базы, мы стремимся улучшить один из ключевых технических факторов на 50%. | Slavina Stefanova |
| Ключевые результаты по Сигналам и Услугам Данных (SDS)
[ Цели ] | |||
|---|---|---|---|
| Вкратце о ключевом результате | Текст ключевого результата | Контекст ключевого результата | Владелец |
| SDS1.1 | Руководители двух программ или инициатив, основанных на ключевых результатах, подготовили широко распространяемую документацию, объясняющую логическую связь между работой их команды и влиянием на один или несколько ключевых показателей Фонда. | Наши основные организационные показатели служат основой для оценки прогресса Фонда в достижении своей целей. Так как мы выделяем ресурсы на программы и разрабатываем рабочие процессы, ориентированные на достижение ключевых результатов, эти показатели должны определять, как мы связываем эти инвестиции с общими целями Фонда, определенными в годовом плане. Работа над этим ключевым результатом подтверждает, что Фонд в целом находится на ранней стадии своей способности количественно связывать воздействие всех запланированных мер с высокоуровневыми или ключевыми показателями. Для достижения этой конечной цели, данный проект направлен на разработку процесса, с помощью которого мы делимся логическими и теоретическими связами между нашими инициативами и нашими показателями высокого уровня. На практике это означает партнерство с владельцами инициатив по всему Фонду, чтобы понять, как результаты их работы на уровне проекта связаны с нашими основными показателями на уровне Фонда и влияют на них. Для обеспечения последовательности и точности документирования потенциального воздействия работы будут использоваться такие методы составления руководств воздействия и упражнения, как «Теория изменения карт» и построение причинно-следственных графов. Для достижения этого ключевого результата нам также потребуется разработать вспомогательные материалы, которые помогут владельцам инициатив разобраться в организационных показателях и понять, как создавать теории изменений, связанные с их работой. |
Omari Sefu |
| SDS1.2 | Ответить на 3 стратегических вопроса открытого исследования к декабрю 2024 года, чтобы подготовить рекомендацию или проинформировать лиц при годовом планировании на 2025—2026 финансовый год. | В экосистеме Викимедиа существует множество открытых вопросов для исследований и ответы на некоторые из них являются стратегическими для Фонда Викимедиа или аффилиаций. Ответы на эти вопросы могут послужить основой для разработки будущих продуктов или технологий или могут помочь в принятии решений/адвокатировании в области политики. Хотя на некоторые из этих вопросов можно ответить, используя только исследовательский или инженерно-технический опыт, учитывая социально-техническую природу проектов Викимедиа, получение достоверной информации часто требует межкомандного сотрудничества для сбора данных, создания контекста, взаимодействия с пользователем, тщательного планирования экспериментов и многого другого. С помощью этого ключевого результата, мы стремимся использовать некоторые из наших ресурсов в качестве приоритетных для ответа на один или несколько таких вопросов.
Работа в рамках этого ключевого результата включает в себя определение приоритетности списка стратегических открытых вопросов, а также проведение экспериментальной работы по поиску ответа на X из них (в настоящее время оценено как на 2). Идеальный тип вопросов, которые мы рассматриваем при этом ключевом результате - это вопросы, ответы на которые могут помочь многим другим командам или группам работать (лучше? информированно) над продуктом, технологией или политикой. Мы планируем, что работа при этом ключевом результате будет дополнять следующие обзоры:
|
Leila Zia |
| SDS1.3 | Сократить среднее время, необходимое конкретным лицам как минимум на 50% для понятия и отслеживания потоков данных по трем основным показателям | Требуется для соблюдения стандартов Управления Данными.
Проследить преобразование и источник наборов данных сложно и требует знания различных хранилищ и систем. Мы должны упростить понятие того, как данные передаются по нашим системам, чтобы конкретные лица ответственные за данные могли работать в режиме самообслуживания. Эта работа будет поддерживать рабочие процессы, в которых данные преобразуются и используются для аналитики, функций, API и обеспечения качества данных. Будет продолжена работа над ключевыми результатами, посвященный документированию показателей. |
Luke Bowmaker |
| SDS2.1 | К концу второго квартала, мы сможем оказать поддержку одной команде разработчиков в оценке функции или продукта с помощью базового A/B тестирования, что сократит их время на сбор данных о взаимодействии с пользователем на 50%. | Мы считаем, что использование общих инструментов позволит улучшить процесс принятия решений командами по разработке продуктов на основе данных, повысить эффективность и производительность, а также усовершенствовать стратегию и инновации в области продуктов.
Создание UX и технических систем для авторизованных участников позволяет нам двигаться к долгосрочной цели поддержки A/B-тестов для неавторизованных участников, пока ведётся работа по оценке осуществимости SDS 2.3. Мы рассмотрим, как использовать базовые данные о времени, затрачиваемом командой на взаимодействие с пользователем и улучшим их на 50%. Мы также рассмотрим, как мы можем использовать эти преимущества в более полном контексте для всех продуктовых команд. Мы ожидаем узнать, как мы можем улучшить опыт, а также определить и расставить приоритеты в улучшении возможностей на основе отзывов от команды разработчиков и результатов SDS 2.2. |
Virginia Poundstone |
| SDS2.2 | К концу второго квартала у нас будут 3 основных показателя для анализа экспериментов (A/B тесты), которые помогут проверить гипотезы о продукте/функциях, связанных с ключевыми результатами на 2024—2025 финансовый год. | Когда у менеджера по продукту (или же дизайнера) возникает гипотеза о том, что продукт/функция решит проблему/потребность пользователей или организации, то эксперимент — это способ проверить эту гипотезу и узнать о потенциальном эффекте своей идеи на показатели. Результаты эксперимента информируют менеджера по продукту и помогают ему принять решение о том, какие действия предпринять дальше (отказаться от этой идеи и попробовать другую гипотезу, продолжить разработку, если эксперимент проводился на ранней стадии «жизненного цикла» разработки, или предоставить продукт/функцию большему числу пользователей). Менеджеры по продуктам должны быть в состоянии принять такое решение с уверенностью, подкрепленное фактами, которым они доверяют и которые понимают.
Главным препятствием для этого является то, что команды разработчиков в настоящее время формулируют свои гипотезы с использованием показателей, специфичных для конкретного проекта, которые требуют конкретной поддержки аналитиков для определения, измерения, анализа и составления отчетов по ним. Переход на набор основных показателей для формулирования всех проверяемых гипотез о продукте/функции позволил бы упростить:
Мы думаем, что набор существенных показателей, которые широко понятны и последовательно используются, а также основаны на отраслевых стандартах и на которых можно влиять, также повысит информационную грамотность организации и будет способствовать развитию культуры анализа, экспериментирования и обучения. Мы сосредоточиваемся на существенных показателях, которые (1) необходимы для наилучшего измерения и оценки успешности/влияния продуктов/функций, связанных с двумя вики–проектами KRs – WE3.1 и WE1.2, и (2) отражают или сопоставляются со стандартными отраслевыми показателями, используемыми в веб аналитике. |
Mikhail Popov |
| SDS2.3 | Deploy a unique agent tracking mechanism to our CDN which enables the A/B testing of product features with anonymous readers. | Without such a tracking mechanism, it is not reasonable to implement A/B testing of product features with anonymous readers.
This is basically a milestone-based result to create a new technical capability that others can build measurable things on top of. The key priority use-case will be A/B testing of features with anonymous readers, but this work also enables other important future things, which may create follow-on hypotheses later in WE4.x (for request risk ratings and mitigating large-scale attacks) and for metrics/research about unique device counts as their resourcing and priorities allow. |
Brandon Black |
| Ключевые результаты по Будущей аудитории (FA)
[ Цели ] | |||
|---|---|---|---|
| Вкратце о ключевом результате | Текст ключевого результата | Контекст ключевого результата | Владелец |
| FA1.1 | В результате экспериментальных исследований и рекомендаций по Будущей Аудотории, к концу третьего квартала в проекте годового плана на следующий год будет присутствовать по крайней мере одна цель или ключевой результат, принадлежащий команде, не относящейся к Будущей Аудотории. | С 2020 года, Фонд Викимедиа отслеживает внешние тенденции, которые могут повлиять на нашу способность обслуживать будущии поколения потребителей и вкладйиков знаний и оставаться развивающимся движением за свободные знания для будущих поколений. Будущая Аудитория или небольшая научно-исследовательская группа, будет:
|
Maryana Pinchuk |
| Ключевые результаты по Продуктовой и инженерной поддержке (PES)
[ Цели ] | |||
|---|---|---|---|
| Вкратце о ключевом результате | Текст ключевого результата | Контекст ключевого результата | Владелец |
| PES1.1 | Культура обзора: В ходе ежеквартального опроса постепенно повышать оценку физического состояния персонала, связанных с нашей работой, согласованием, руководством и здоровьем команды. | Культура обзора — это культура разработки продукта, основанная на более коротких циклах итерации, обучения и адаптации. Это означает, что наша организация может устанавливать годовые цели, но то, что мы делаем для достижения этих целей, будет меняться и адаптироваться в течение года, по мере того, как мы будем учиться. Формирование культуры обзора состоит из двух компонентов: процессов и поведения. В данном обзоре основное внимание уделяется последнему. Изменения в поведении могут способствовать росту и укреплению нашей культуры обзора. Это включает изменения в индивидуальных привычках и распорядке дня по мере того, как мы переходим к более итеративной разработке продукта. Этот ключевой результат будет основан на самоотчетах об изменениях в поведении отдельных сотрудников и измерении результирующих изменений в настроениях сотрудников, если таковые имеются. | Amy Tsay |
| PES1.2 | К концу второго квартала новый «список о пожеланиях сообщества» лучше связывает идеи и запросы движения с деятельностью Фонда в области P+T: идеи из списка невыполненных пожеланий рассматриваются в рамках планов на 2024—2025 финансовый год, Фонд выполнил 10 небольших пожеланий и сотрудничает с добровольцами, чтобы определить 3+ областей возможностей на 2025—2026 финансовый год. | «Опрос о пожеланиях сообщества» представляет собой узкую срез движения; в нём участвуют около тысяч человек, большинство из которых являются вкладчиками или администраторами. Люди часто обходят стороной список пожеланий, отправляя запросы на новые функции и отчеты об ошибках через Фабрикатор, где трудно распознать запросы от Фонда Викимедиа или сообщества. Для участников «Опрос о пожеланиях» — это отдача с минимальным расходом времени и отдачей. Люди по-прежнему используют список пожеланий, поскольку считают, что это единственный способ привлечь внимание к существенным ошибкам и улучшениям функций или возможность дать сигнал о необходимости более широких стратегических возможностей. Пожелания часто излагаются в виде решений, а не проблем. Решения могут показаться разумными на бумаге, но не обязательно учитывая техническую сложность или последствия для стратегии движения.
Масштаб и объем пожеланий иногда превышают возможности Технического отдела Фонда или отдельной команды, что усугубляет разочарование, приводит к «Запросам комментариев» и призывам отменить Список пожеланий. В то время как члены сообщества предпочитают использовать Список пожеланий для получения идей для проектов, команды Фонда изучают Список пожеланий и другие процессы приема заявок для определения приоритетов, отчасти потому, что пожелания несвоевременны для ежегодного планирования и их трудно включить в дорожные карты/OKR. Будущий опрос о пожеланиях сообщества должен стать мостом между сообществом и Фондом, где сообщества будут вносить структурированный вклад, чтобы мы могли принимать меры и этим радовать добровольцев. Мы создаем новый процесс заявок для любого зарегистрированного добровольца, который может оставить свое пожелание 365 дней в году. Желающие могут сообщить или выделить ошибку, запросить улучшение или предложить новую функцию. Любой желающий может прокомментировать, провести воркшоп или поддержать его, чтобы повлиять на расстановку приоритетов. Фонд не будет классифицировать пожелания на «слишком большие» или «слишком маленькие». Пожелания, которые тематически связаны с более широкой проблемой, могут повлиять на годовое планирование и на составление планов для команд Фонда, предлагая стратегические направления и возможности. Пожелания будут видны участникам движения на информационной панели, которая классифицирует пожелания по проекту, продукту/проблемной области и типу пожелания. Фонд будет своевременно реагировать на пожелания и сотрудничать с сообществом для их категоризации и определения приоритетов. Мы будем сотрудничать с викимедийцами, чтобы определить и расставить приоритеты в трех областях для улучшения, включенных в Годовой План Фонда на 2025-2026 годы, которые должны повысить уровень принятия и выполнения важных пожеланий. Мы будем отмечать четко сформулированные пожелания сообщества разработчиков-добровольцев и команд Фонда, что приведет к большей вовлеченности команды и разработчиков и большему количеству выполненных пожеланий, что приведет к удовлетворению сообщества. Исполнение большего числа пожеланий повышает уровень удовлетворенности участников, их эффективность и удержание в проектах, что должно привести к более качественным правкам, более качественному контенту и увеличению числа читателей. |
Jack Wheeler |
| PES1.3 | Провести и завершить два эксперимента с использованием существующих исследовательских продуктов/функций, которые предоставят нам данные/идеи о том, как мы развиваем Википедию как источника знаний для наших нынешних потребителей и добровольческой аудитории в первом и втором кварталах. Завершить и поделиться полученными знаниями и рекомендациями для потенциального внедрения в будущем OKR работы в блок «Вики-опыта» до конца 3-го квартала. | Эта работа соответствует задаче «Будущая Аудитория», но вместо этого направлена на выявление возможностей для увеличения и углубления вовлеченности нашей существующей аудитории (пользователей и вкладчиков Википедии) путем более оперативного тестирования большего количества идей для продуктов на платформе.
Оно дано в PES1, поскольку является источником энергии и мультипликатором, позволяя отдельным лицам и командам «уже» посвятить время хакерству/экспериментам над сторонними проектами, чтобы привлечь внимание к более многообещающим функциям. Вместо того, чтобы откладывать эти сторонние проекты в иссякающий ящик (не очень эффективное использование наших ограниченных ресурсов), этот ключевой результат предоставляет возможность для реализации некоторых из этих идей в более крупных APP с помощью проверенных экспериментов, что позволяет более эффективно использовать время сотрудников и мотивировать их к креативности и продуктивности. Управляя больше таких небольших и коротких проектов, мы также расширяем спектр наших «ставок», чтобы получать больше знаний и опробовать идеи, которые могут преобразовать Википедию в соответствии с меняющимися потребностями и ожиданиями нашей нынешней аудитории. Это сделает нашу работу более результативной и быстрой, поскольку поможет фонду достичь правильной цели за короткое время. |
Rita Ho |
| PES1.4 | Узнать, как: устанавливать, отслеживать и принимать решения по SLO (цели обеспечения уровня обслуживания). Выбрать хотя бы один новый элемент для определения SLO по мере его выпуска. Сотрудничать с соответствующей командой (как правило, с командой Продукта, командой разработчиков, SRE), чтобы определить SLO. Продумать и задокументировать руководство того, какие выпуски должны содержать SLO в будущем и как их устанавливать. | Будущий ключевой результат:
Настроить процесс и элементарные инструменты для настройки и мониторинга SLO для новых выпусков. Квартально составлять отчеты и использовать их для принятия решений о том, когда следует (а когда нет) расставлять приоритеты в работе по исправлению чего-либо. Поделиться отчетом с сообществом. Почему: Мы пока еще не знаем, когда нам нужно расставить приоритеты в работе, чтобы что-то исправить. И у нас много кода. Поскольку объем работ продолжает расти, возникает все больше ситуаций, когда нам, возможно, придется выбирать между решением проблем или сосредоточением на инновациях, и все больше неопределенности в отношении того, когда нам следует это делать. Кроме того, сотрудникам и сообществу неясно, каков уровень нашей поддержки/приверженности над надежности и производительности для всех различных функций, с которыми они взаимодействуют. Если мы определим ожидаемый уровень обслуживания, мы сможем узнать, когда нам следует выделять ресурсы на это или нет. |
Mark Bergsma |
| PES1.5 | Define ownership and commitments (including SLOs) on services and learn how to track, report and make decisions as a standard and scalable practice by trialing it in 3 teams across senior leaders in the department. | After collaboratively defining an SLO for the EditCheck feature as part of PES1.5, we will now trial and learn from using the SLO in practice to help prioritisation of reliability work. We will also document roles and responsibilities for ownership of code/services, allowing us to make clear shared commitments on the level of ongoing support. We will try to use these as practices in 3 teams across the department. | Mark Bergsma |
Гипотезы
The hypotheses below are the specific things we are doing each quarter to address the associated key results above.
Each hypothesis is an experiment or stage in an experiment we believe will help achieve the key result. Teams make a hypothesis, test it, then iterate on their findings or develop an entirely different new hypothesis. You can think of the hypotheses as bets of the teams’ time–teams make a small bet of a few weeks or a big bet of several months, but the risk-adjusted reward should be commensurate with the time the team puts in. Our hypotheses are meant to be agile and adapt quickly. We may retire, adjust, or start a hypothesis at any point in the quarter.
To see the most up-to-date status of a hypothesis and/or to discuss a hypothesis with the team please click the link to its project page below.
К1
The first quarter (Q1) of the WMF annual plan covers July-September.
| Wiki Experiences (WE) Hypotheses
[ WE Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| WE1.1.1 | If we expand the Event List to become a Community List that includes WikiProjects, then we will be able to gather some early learnings in how to engage with WikiProjects for product development. | |
| WE1.1.2 | If we identify at least 15 WikiProjects in 3 separate Wikipedias to be featured in the Community List, then we will be able to advise Campaigns Product in the key characteristics needed to build an MVP of the Community List that includes WikiProjects. | |
| WE1.1.3 | If we consult 20 event organizers and 20 WikiProject organizers on the best use of topics available via LiftWing, then we can prioritize revisions to the topic model that will improve topical connections between events and WikiProjects. | |
| WE1.2.1 | If we build a first version of the Edit Check API, and use it to introduce a new Check, we can evaluate the speed and ease with other teams and volunteers could use the API to create new Checks and Suggested Edits. | |
| WE1.2.2 | If we build a library of UI components and visual artefacts, Edit Check’s user experience can extend to accommodate Structured Tasks patterns. | |
| WE1.2.3 | If we conduct user tests on two or more design prototypes introducing structured tasks to newcomers within/proximate to the Visual Editor, then we can quickly learn which designs will work best for new editors, while also enabling engineers to assess technical feasibility and estimate effort for each approach. | mw:Growth/Constructive activation experimentation |
| WE1.2.4 | If we train an LLM on detecting "peacock" behavior, then we can learn if it can detect this policy violation with at least >70% precision and >50% recall and ultimately, decide if said LLM is effective enough to power a new Edit Check and/or Suggested Edit. | |
| WE1.2.5 | If we conduct an A/B/C test with the alt-text suggested edits prototype in the production version of the iOS app we can learn if adding alt-text to images is a task newcomers are successful with and ultimately, decide if it's impactful enough to implement as a suggested edit on the Web and/or in the Apps. | mw:Wikimedia Apps/iOS Suggested edits project/Alt Text Experiment |
| WE1.3.1 | If we enable additional customisation of Automoderator's behaviour and make changes based on pilot project feedback in Q1, more moderators will be satisfied with its feature set and reliability, and will opt to use it on their Wikimedia project, thereby increasing adoption of the product. | mw:Automoderator |
| WE1.3.2 | If we are able interpret subsets of wishes as moderator-related focus areas and share these focus areas for community input in Q1-Q2, then we will have a high degree of confidence that our selected focus area will improve moderator satisfaction, when it is released in Q3. | |
| WE2.1.1 | If we build a country-level inference model for Wikipedia articles, we will be able to filter lists of articles to those about a specific region with >70% precision and >50% recall. | m:Research:Language-Agnostic Topic Classification/Countries |
| WE2.1.2 | If we build a proof-of-concept providing translation suggestions that are based on user-selected topic areas, we will be set up to successfully test whether translators will find more opportunities to translate in their areas of interest and contribute more compared to the generic suggestions currently available. | mw: Translation suggestions: Topic-based & Community-defined lists |
| WE2.1.3 | If we offer list-making as a service, we’ll enable at least 5 communities to make more targeted contributions in their topic areas as measured by (1) change in standard quality coverage of relevant topics on the relevant wiki and (2) a brief survey of organizer satisfaction with topic area coverage on-wiki. | |
| WE2.1.4 | If we developed a proof of concept that adds translation tasks sourced from WikiProjects and other list-building initiatives, and present them as suggestions within the CX mobile workflow, then more editors would discover and translate articles focused on topical gaps. By introducing an option that allows editors to select translation suggestions based on topical lists, we would test whether this approach increases the content coverage in our projects. | mw:Translation suggestions: Topic-based & Community-defined lists |
| WE2.2.1 | If we expand Wikimedia's State of Languages data by securing data sharing agreements with UNESCO and Ethnologue, at least one partner will decide to represent Wikimedia’s language inclusion progress in their own data products and communications. On top of being useful to our partner institutions, our expanded dataset will provide important contextual information for decision-making and provide communities with information needed to identify areas for intervention. | |
| WE2.2.2 | If we map the language documentation activities that Wikimedians have conducted in the last 2 years, we will develop a data-informed baseline for community experiences in onboarding new languages. | |
| WE2.2.3 | If we provide production wiki access to 5 new languages, with or without Incubator, we will learn whether access to a full-fledged wiki with modern features such as those available on English Wikipedia (including ContentTranslation and Wikidata support, advanced editing and search results) aids in faster editing. Ultimately, this will inform us if this approach can be a viable direction for language onboarding for new or existing languages, justifying further investigation. | mw:Future of Language Incubation |
| WE2.3.1 | If we make two further improvements to media upload flow on Commons and share them with community, the feedback will be positive and it will help uploaders make less bad uploads (with the focus on copyright) as measured by the ratio of deletion requests within 30 days of upload. This will include defining designs for further UX improvements to the release rights step in the Upload Wizard on Commons and rolling out an MVP of logo detection in the upload flow. | |
| WE2.4.1 | If we build a prototype of Wikifunctions calls embedded within MediaWiki content, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2. | phab:T261472 |
| WE2.4.2 | If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2 (see hypothesis 1). | phab:T363391 |
| WE2.4.3 | If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful. | phab:T282926 |
| WE3.1.1 | Designing and qualitatively evaluating three proofs of concept focused on building curated, personalized, and community-driven browsing and learning experiences will allow us to estimate the potential for increased reader retention (experiment 1: providing recommended content in search and article contexts, experiment 2: summarizing and simplifying article content, experiment 3: making multitasking easier on wikis. | |
| WE3.1.3 | If we develop models for remixing content such as a content simplification or summarization that can be hosted and served via our infrastructure (e.g. LiftWing), we will establish the technical direction for work focused on increasing reader retention through new content discovery features. | |
| WE3.1.4 | If we analyze the projected performance impact of hypothesis WE3.1.1 and WE3.1.2 on the Search API, we can scope and address performance and scalability issues before they negatively affect our users. | |
| WE3.1.5 | If we enhance the search field in the Android app to recommend personalized content based on a user's interest and display better results, we will learn if this improves user engagement by observing whether it increases the impression and click-through rate (CTR) of search results by 5% in the experimental group compared to the control group over a 30-day A/B test. This improvement could potentially lead to a 1% increase in the retention of logged out users. | phab:T370117 |
| WE3.2.1 | If we create a clickable design prototype that demonstrates the concept of a badge representing donors championing article(s) of interest, we can learn if there would be community acceptance for a production version of this method for fundraising in the Apps. | Fundraising Experiment in the iOS App |
| WE3.2.2 | Increasing the prominence of entry points to donations on the logged-out experiences of the web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% Year over Year | phab:T368765 |
| WE3.2.3 | If we make the “Donate” button in the iOS App more prominent by making it one click or less away from the main navigation screen, we will learn if discoverability was a barrier to non banner donations. | |
| WE3.3.1 | If we select a data visualization library and get an initial version of a new server-rendered graph service available by the end of July, we can learn from volunteers at Wikimania whether we’re working towards a solution that they would use to replace legacy graphs. | |
| WE4.1.1 | If we implement a way in which users can report potential instances of harassment and harmful content present in discussions through an incident reporting system, we will be able to gather data around the number and type of incidents being reported and therefore have a better understanding of the landscape and the actions we need to take. | |
| WE4.2.1 | If we explore and define Wikimedia-specific methods for a unique device identification model, we will be able to define the collection and storage mechanisms that we can later implement in our anti-abuse workflows to enable more targeted blocking of bad actors. | phab:T368388 |
| WE4.2.9 | If we provide contextual information about reputation associated with an IP that is about to be blocked, we will see fewer collateral damage IP and IP range blocks, because administrators will have more insight into potential collateral damage effects of a block. We can measure this by instrumenting Special:Block and observing how behavior changes when additional information is present, vs when it is not. | WE4.2.9 Talk page |
| WE4.2.2 | If we define an algorithm for calculating a user account reputation score for use in anti-abuse workflows, we will prepare the groundwork for engineering efforts that use this score as an additional signal for administrators targeting bad actors on our platform. We will know the hypothesis is successful if the algorithm for calculating a score maps with X% precision to categories of existing accounts, e.g. a "low" score should apply to X% of permanently blocked accounts | WE4.2.2 Talk page |
| WE4.2.3 | If we build an evaluation framework using publicly available technologies similar to the ones used in previous attacks we will learn more about the efficacy of our current CAPTCHA at blocking attacks and could recommend a CAPTCHA replacement that brings a measurable improvement in terms of the attack rate achievable for a given time and financial cost. | |
| WE4.3.1 | If we apply some machine learning and data analysis tools to webrequest logs during known attacks, we'll be able to identify abusive IP addresses with at least >80% precision sending largely malicious traffic that we can then ratelimit at the edge, improving reliability for our users. | phab:T368389 |
| WE4.3.2 | If we limit the load that known IP addresses of persistent attackers can place on our infrastructure, we'll reduce the number of impactful cachebusting attacks by 20%, improving reliability for our users. | |
| WE4.3.3 | If we deploy a proof of concept of the 'Liberica' load balancer, we will measure a 33% improvement in our capacity to handle TCP SYN floods. | |
| WE4.3.4 | If we make usability improvements and also perform some training exercises on our 'requestctl' tool, then SREs will report higher confidence in using the tool. | phab:T369480 |
| WE4.4.1 | If we run at least 2 deployment cycles of Temp Accounts we will be able to verify this works successfully. | |
| WE5.1.1 | If we successfully roll out Parsoid Read Views to all Wikivoyages by Q1, this will boost our confidence in extending Parsoid Read Views to all Wikipedias. We will measure the success of this rollout through detailed evaluations using the Confidence Framework reports, with a particular focus on Visual Diff reports and the metrics related to performance and usability. Additionally, we will assess the reduction in the list of potential blockers, ensuring that critical issues are addressed prior to wider deployment. | |
| WE5.1.2 | If we disable unused Graphite metrics, target migrating metrics using the db-prefixed data factory and increase our outreach efforts to other teams and the community in Q1, then we would be on track to achieve our goal of making Graphite read-only by Q3 FY24/25, by observing an increase of 30% in migration progress. | |
| WE5.1.3 | If we implement a canonical url structure with versioning for our REST API then we can enable service migration and testing for Parsoid endpoints and similar services by Q1. | phab:T344944 |
| WE5.1.4 | If we complete the remaining work to mitigate the impact of browsers' anti-tracking measures on CentralAuth autologin and move to a more resilient authentication infrastructure (SUL3), we will be ready to roll out to production wikis in Q2. | |
| WE5.1.5 | If we increase the coverage of Sonar Cloud to include key MediaWiki Core repos, we will be able to improve the maintainability of the MediaWiki codebase. This hypothesis will be measured by spliting the selected repos into test and control groups. These groups will then be compared over the course of a quarter to measure impact of commit level feedback to developers. | |
| WE5.2.1 | If we make a classification of the types of hooks and extension registry properties used to influence the behavior of MediaWiki core, we will be able to focus further research and interventions on the most impactful. | Simplify feature development |
| WE5.2.2 | If we explore a new architecture for notifications in MW core and Echo, we will discover new ways to provide modularity and new ways for extensions to interact with core. | Simplify feature development |
| WE5.3.1 | If we instrument parser and cache code to collect template structure and fine-grained timing data, we can quantify the expected performance improvement which could be realized by future evolution of the wikitext parsing platform. | T371713 |
| WE5.3.2 | On template edits, if we can implement an algorithm in Parsoid to reuse HTML of a page that depends on the edited template without processing the page from scratch and demonstrate 1.5x or higher processing speedup, we will have a potential incremental parsing solution for efficient page updates on template edits. | T363421 |
| WE5.4.1 | If the MediaWiki engineering group is successful with release process accountability and enhances its communication process by the end of Q2 in alignment with the product strategy, we will eliminate the current process that relies on unplanned or volunteer work and improve community satisfaction with the release process. Measured by community feedback on the 1.43 LTS release coupled with a significant reduction in unplanned staff and volunteer hours needed for release processes. | |
| WE5.4.2 | If we research and build a process to more regularly upgrade PHP in conjunction with our MediaWiki release process we will increase speed and security while reducing the complexity and runtime of our CI systems, by observing the success of PHP 8.1 upgrade before 1.43 release. | |
| WE6.1.1 | If we design and complete the initial implementation of an authorization framework, we’ll establish a system to effectively manage the approval of all LDAP access requests. | |
| WE6.1.2 | If we research available documentation metrics, we can establish metrics that measure the health of Wikimedia technical documentation, using MediaWiki Core documentation as a test case. | mw:Wikimedia Technical Documentation Team/Doc metrics |
| WE6.1.3 | If we collect insights on how different teams are making technical decisions we are able to gather good practices and insights that can enable and scale similar practices across the organization. | |
| WE6.2.1 | If we publish a versioned build of MediaWiki, extensions, skins, and Wikimedia configuration at least once per day we will uncover new constraints and establish a baseline of wallclock time needed to perform a build. | mw:Wikimedia Release Engineering Team/Group -1 |
| WE6.2.2 | If we replace the backend infrastructure of our existing shared MediaWiki development and testing environments (from apache virtual servers to kubernetes), it will enable us to extend its uses by enabling MediaWiki services in addition to the existing ability to develop MediaWiki core, extensions, and skins in an isolated environment. We will develop one environment that includes MediaWiki, one or more Extensions, and one or more Services. | wikitech:Catalyst |
| WE6.2.3 | If we create a new deployment UI that provides more information to the deployer and reduce the amount of privilege needed to do deployment, it will make deployment easier and open deployments to more users as measured by the number of unique deployers and number of patches backported as a percentage of our overall deployments. | Wikimedia Release Engineering Team/SpiderPig |
| WE6.2.4 | If we migrate votewiki, wikitech and commons to MediaWiki on Kubernetes we reap the benefits of consistency and no longer need to maintain 2 different infrastructure platforms in parallel, allowing to reduce the amount of custom written tooling, making deployments easier and less toilous for deployers. This will be measured by a decrease in total deployment times and a reduction in deployment blockers. | задача T292707 |
| WE6.2.5 | If we move MultiVersion routing out of MediaWiki, we 'll be able to ship single version MediaWiki containers, largely cutting down the size of containers allowing for faster deployments, as measured by the deployment tool. | SingleVersion MW: Routing options |
| WE6.3.1 | By consulting toolforge maintainers about the least sustainable aspects of the platform, we will be able to gather a list of potential categories to measure. | |
| WE6.3.2 | By creating a "standard" tool to measure the number of steps for a deployment we will be able to assess the maximal improvement in the deployment process. | |
| WE6.3.3 | If we conduct usability tests, user interviews, and competitive analysis to explore the existing workflows and use cases of Toolforge, we can identify key areas for improvement. This research will enable us to prioritize enhancements that have the most significant impact on user satisfaction and efficiency, laying the groundwork for a future design of the user interface. | |
| Signals & Data Services (SDS) Hypotheses
[ SDS Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| SDS 1.1.1 | If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics. | |
| SDS1.2.2 | If we study the recruitment, retention, and attrition patterns among long-tenure community members in official moderation and administration roles, and understand the factors affecting these phenomena (the ‘why’ behind the trends), we will better understand the extent, nature, and variability of the phenomenon across projects. This will in turn enable us to identify opportunities for better interventions and support aimed at producing a robust multi-generational framework for editors. | phab:T368791 |
| SDS1.2.1 | If we gather use cases from product and feature engineering managers around the use of AI in Wikimedia services for readers and contributors, we can determine if we should test and evaluate existing AI models for integration into product features, and if yes, generate a list of candidate models to test. | phab:T369281 |
| SDS1.3.1 | If we define the process to transfer all data sets and pipeline configurations from the Data Platform to DataHub we can build tooling to get lineage documentation automatically. | |
| SDS 1.3.2 | If we implement a well documented and understood process to produce an intermediary table representing MediaWiki Wikitext History, populated using the event platform, and monitor the reliability and quality of the data we will learn what additional parts of the process are needed to make this table production ready and widely supported by the Data Platform Engineering team. | |
| SDS2.1.2 | If we investigate the data products current sdlc, we will be able to determine inflection points where QTE knowledge can be applied in order to have a positive impact on Product Delivery. | |
| SDS2.1.3 | If the Growth team learns about the Metrics Platform by instrumenting a Homepage Module on the Metrics Platform, then we will be prepared to outline a measurement plan in Q1 and complete an A/B test on the new Metrics platform by the end of Q2. | |
| SDS2.1.4 | If we conduct usability testing on our prototype among pilot users of our experimentation process, we can identify and prioritize the primary pain points faced by product managers and other stakeholders in setting up and analyzing experiments independently. This understanding will lead to the refinement of our tools, enhancing their efficiency and impact. | |
| SDS2.1.5 | If we design a documentation system that guides the experience of users building instrumentation using the Metrics Platform, we will enable those users to independently create instrumentation without direct support from Data Products teams, except in edge cases. | phab:T329506 |
| SDS2.2.1 | If we define a metric for logged-out mobile app reader retention, which is applicable for analyzing experiments (A/B test), we can provide guidance for planning instrumentation to measure retention rate of logged out readers in the mobile apps and enable the engineering team to develop an experiment strategy targeting logged out readers. | |
| SDS2.2.2 | If we define a standard approach for measuring and analyzing conversion rates, it will help us establish a collection of well-defined metrics to be used for experimentation and baselines, and start enabling comparisons between experiments/projects to increase learning from these. | |
| SDS2.2.3 | If we define a standard way of measuring and analyzing clickthrough rate (CTR) in our products/features, it will help us design experiments that target CTR for improvement, standardize click-tracking instrumentation, and enable us to make CTR available as a target metric to users of the experimentation platform. | |
| SDS2.3.1 | If we conduct a legal review of proposed unique cookies for logged out users, we can determine whether there are any privacy policy or other legal issues which inform the community conversation and/or affect the technical implementation itself. | |
| Future Audiences (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| FA1.1.1 | If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform. | m:Future Audiences/Experiment:Add a Fact |
| Product and Engineering Support (PES) Hypotheses
[ PES Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| PES1.1.1 | If the P&T leadership team syncs regularly on how they’re guiding their teams towards a more iterative software development culture, and we collect baseline measurements of current development practices and staff sentiment on how we work together to ship products, we will discover opportunity areas for change management. The themes that emerge will enable us to build targeted guidance or programs for our teams in coming quarters. | |
| PES1.2.2 | If the Moderator Tools team researches the Community Wishlist and develops 2+ focus areas in Q1, then we can solicit feedback from the Community and identify a problem that the Community and WMF are excited about tackling. | |
| PES1.2.3 | If we bundle 3-5 wishes that relate to selecting and inserting templates, and ship an improved feature in Q1, then CommTech can take the learnings to develop a Case Study for the foundation to incorporate more "focus areas" in the 2025-26 annual plan. | |
| PES1.3.1 | If we provide insights to audiences about their community and their use of Wikipedia over a year, it will stimulate greater connection with Wikipedia – encouraging greater engagement in the form of social sharing, time spent interacting on Wikipedia, or donation. Success will be measured by completing an experimental project that provides at least one recommendation about “Wikipedia insights” as an opportunity to increase onwiki engagement. | Wikipedia user insights |
| PES1.3.2 | If we create a Wikipedia-based game for daily use that highlights the connections across vast areas of knowledge, it will encourage consumers to visit Wikipedia regularly and facilitate active learning, leading to longer increased interaction with content on Wikipedia. Success will be measured by completing an experimental project that provides at least one recommendation about gamification of learning as an opportunity to increase onwiki engagement. | Wikipedia games |
| PES1.3.3 | If we develop a new process/track at a Wikimedia hack event to incubate future experiments, it will increase the impact and value of such events in becoming a pipeline for future annual plan projects, whilst fostering greater connection between volunteers and engineering/design staff to become more involved with strategic initiatives. Success will be measured by at least one PES1.3 project being initiated and/or advanced to an OKR from a foundation-supported event. | Incubator space |
| PES1.4.1 | If we draft an SLO with the Editing team releasing Edit Check functionality, we will begin to learn and understand how to define and track user-facing SLOs together, and iterate on the process in the future. | |
| PES1.4.2 | If we define and publish SLAs for putting OOUI into “maintenance mode”, growth of new code using OOUI across Wikimedia projects will stay within X% in Q1. | |
| PES1.4.3 | If we map ownership using the proposed service catalog for known owned services in Q1, we will be able to identify significant gaps in service catalog as it helps in solving the SLO culture by the end of the year. | |
К2
The second quarter (Q2) of the WMF annual plan covers October-December.
| Wiki Experiences (WE) Hypotheses
[ WE Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| WE1.1.1 | If we expand the Event list to become a Community List that includes WikiProjects, then we will be able to gather some early learnings in how to engage with WikiProjects for product development. | Campaigns/Foundation Product Team/Event list |
| WE1.1.2 | If we launch at least 1 consultation focused on on-wiki collaborations, and if we collect feedback from at least 20 people involved in such collaborations, then we will be able to advise Campaigns Product on the key characteristics needed to develop a new or improved way of connecting. | Campaigns/WikiProjects |
| WE1.1.3 | If we consult 20 event organizers and 20 WikiProject organizers on the best use of topics available via LiftWing, then we can prioritize revisions to the topic model that will improve topical connections between events and WikiProjects. | |
| WE1.1.4 | If we integrate CampaignEvents into Community Configuration in Q2, then we will set the stage for at least 5 more wikis opting to enable extension features in Q3, thereby increasing tool usage. | |
| WE1.2.2 | If we build a library of UI components and visual artifacts, Edit Check’s user experience can extend to accommodate Structured Tasks patterns. | |
| WE1.2.5 | If we conduct an A/B/C test with the alt-text suggested edits prototype in the production version of the iOS app we can learn if adding alt-text to images is a task newcomers are successful with and ultimately, decide if it's impactful enough to implement as a suggested edit on the Web and/or in the Apps. | |
| WE1.2.6 | If we introduce new account holders to the “Add a Link” Structured Task in Wikipedia articles, we expect to increase the percentage of new account holders who constructively activate on mobile by 10% compared to the baseline. | |
| WE1.3.1 | If we enable additional customisation of Automoderator's behaviour and make changes based on pilot project feedback in Q1, more moderators will be satisfied with its feature set and reliability, and will opt to use it on their Wikimedia project, thereby increasing adoption of the product. | mw:Moderator Tools/Automoderator |
| WE1.3.3 | If we improve the user experience and features of the Nuke extension during Q2, we will increase administrator satisfaction of the product by 5pp by the end of the quarter. | mw:Extension:Nuke/2024 Moderator Tools project |
| WE2.1.3 | If we offer list-making as a service, we’ll enable at least 5 communities to make more targeted contributions in their topic areas as measured by (1) change in standard quality coverage of relevant topics on the relevant wiki and (2) a brief survey of organizer satisfaction with topic area coverage on-wiki. | |
| WE2.1.4 | If we developed a proof of concept that adds translation tasks sourced from WikiProjects and other list-building initiatives, and present them as suggestions within the CX mobile workflow, then more editors would discover and translate articles focused on topical gaps. By introducing an option that allows editors to select translation suggestions based on topical lists, we would test whether this approach increases the content coverage in our projects. |
|
| WE2.1.5 | If we expose topic-based translation suggestions more broadly and analyze its initial impact, we will learn which aspects of the translation funnel to act on in order to obtain more quality translations. | |
| WE2.2.4 | If we provide production wiki access to 5 new languages, with or without Incubator, we will learn whether access to a full-fledged wiki with modern features such as those available on English Wikipedia (including ContentTranslation and Wikidata support, advanced editing and search results) aids in faster editing. Ultimately, this will inform us if this approach can be a viable direction for language onboarding for new or existing languages, justifying further investigation. | |
| WE2.2.5 | If we move addwiki.php to core and customize it to Wikimedia, we will improve code quality in our wiki creation system making it testable and robust, and we will make it easy for creators of new wikis and thereby make significant steps towards simplifying wiki creation process. | phab:T352113 |
| WE2.3.2 | If we make two further improvements to media upload flow on Commons and share them with community, the feedback will be positive and it will help uploaders make less bad uploads (with the focus on copyright) as measured by the ratio of deletion requests within 30 days of upload. This will include release of further UX improvements to the release rights step in the Upload Wizard on Commons and automated detection of external sources. | |
| WE2.3.3 | If the BHL-Wikimedia Working Group creates Commons categories and descriptive guidelines for the South American and/or African species depicted in publications, they will make 3,000 images more accessible to biodiversity communities. (BHL = Biodiversity Heritage Library) |
|
| WE2.4.1 | If we build a prototype of Wikifunctions calls embedded within MediaWiki content and test it locally for stability, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2. | phab:T261472 |
| WE2.4.2 | If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2, as stated in Hypothesis 1. | phab:T363391 |
| WE2.4.3 | If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful. | phab:T282926 |
| WE3.1.3 | If we develop models for remixing content such as a content simplification or summarization that can be hosted and served via our infrastructure (e.g. LiftWing), we will establish the technical direction for work focused on increasing reader retention through new content discovery features. | Research |
| WE3.1.6 | If we introduce a personalized rabbit hole feature in the Android app and recommend condensed versions of articles based on the types of topics and sections a user is interested in, we will learn if the feature is sticky enough to result in multi-day usage by 10% of users exposed to the experiment over a 30-day period, and a higher pageview rate than users not exposed to the feature. | Rabbit Holes |
| WE3.1.7 | If we run a qualitative experiment focused on presenting article summaries to web readers, we will determine whether or not article summaries have the potential to increase reader retention, as proxied by clickthrough rate and usage patterns | |
| WE3.1.8 | If we build one feature which provides additional article-level recommendations, we will see an increase in clickthrough rate of 10% over existing recommendation options and a significant increase in external referrals for users who actively interact with the new feature. | |
| WE3.2.2 | Increasing the prominence of entry points to donations on the logged-out experiences of the Vector web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY. | mw:Readers/2024 Reader and Donor Experiences |
| WE3.2.3 | If we make the “Donate” button in the iOS App more prominent by making it one click or less away from the main navigation screen, we will learn if discoverability was a barrier to non banner donations. | Navigation Refresh |
| WE3.2.4 | If we update the contributions page for logged-in users in the app to include an active badge for someone that is an app donor and display an inactive state with a prompt to donate for someone that decided not to donate in app, we will learn if this recognition is of value to current donors and encourages behavior of donating for prospective donors, informing if it is worth expanding on the concept of donor badges or abandoning it. | Private Donor Recognition Experiment |
| WE3.2.5 | If we create a Wikipedia in Review experiment in the Wikipedia app, to allow users to see and share personalized data about their reading, editing, and donation habits, we will see 2% of viewers donate on iOS as a result of this feature, 5% click share and, 65% of users rating the feature neutral or satisfactory. | Personalized Wikipedia Year in Review |
| WE3.2.7 | Increasing the prominence of entry points to donations on the logged-out experiences of the Minerva web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY. | |
| WE3.3.2 | If we develop the Charts MVP and get it working end-to-end in production test wikis, at least two Wikipedias + Commons agree to pilot it before the code freeze in December. | |
| WE3.4.1 | If we were to explore the feasibility by doing an experiment of setting up smaller PoPs in cloud providers like Amazon, we can expand our data center map and reach more users around the world, at reduced cost and increased turn-around time. | |
| WE4.1.2 | If we deploy at least one iteration of the Incident Reporting System MVP on pilot wikis, we will be able to gather valuable data around the frequency and type of incidents being reported. | Incident Reporting System |
| WE4.2.1 | If we explore and define Wikimedia-specific methods for a unique device identification model, we will be able to define the collection and storage mechanisms that we can later implement in our anti-abuse workflows to enable more targeted blocking of bad actors. | |
| WE4.2.9 | If we provide contextual information about reputation associated with an IP that is about to be blocked, we will see fewer collateral damage IP and IP range blocks, because administrators will have more insight into potential collateral damage effects of a block. We can measure this by instrumenting Special:Block and observing how behavior changes when additional information is present, vs when it is not. | |
| WE4.2.2 | If we define an algorithm for calculating a user account reputation score for use in anti-abuse workflows, we will prepare the groundwork for engineering efforts that use this score as an additional signal for administrators targeting bad actors on our platform. We will know the hypothesis is successful if the algorithm for calculating a score maps with X% precision to categories of existing accounts, e.g. a "low" score should apply to X% of permanently blocked accounts. | |
| WE4.2.3 | If we build an evaluation framework using publicly available technologies similar to the ones used in previous attacks we will learn more about the efficacy of our current CAPTCHA at blocking attacks and could recommend a CAPTCHA replacement that brings a measurable improvement in terms of the attack rate achievable for a given time and financial cost. | |
| WE4.3.1 | If we apply some machine learning and data analysis tools to webrequest logs during known attacks, we'll be able to identify abusive IP addresses with at least >80% precision sending largely malicious traffic that we can then ratelimit at the edge, improving reliability for our users. | |
| WE4.3.3 | If we deploy a proof of concept of the 'Liberica' load balancer, we will measure a 33% improvement in our capacity to handle TCP SYN floods. | |
| WE4.3.5 | By creating a system that spawns and controls thousands of virtual workers in a cloud environment, we will be able to simulate Distributed Denial of Service (DDoS) attacks and effectively measure the system's ability to withstand, mitigate, and respond to such attacks. | |
| WE4.3.6 | If we integrate the output of the models we built in WE 4.3.1 with the dynamic thresholds of per-ip concurrency limits we've built for our TLS terminators in WE 4.3.2, we should be able to increase our ability to neutralize automatically attacks with 20% more volume, as measured with the simulation framework we're building. | |
| WE4.3.7 | If we roll out a user-friendly web application that enables assisted editing and creation of requestctl rules, SREs will be able to mitigate cachebusting attacks in 50% less time than our established baseline. | |
| WE4.4.2 | If we deploy Temporary Accounts to a set of small-to-medium sized projects, we will be able to the functionality works as intended and will be able to gather data to inform necessary future work. | Trust and Safety Product/Temporary Accounts |
| WE5.1.1 | If we successfully roll out Parsoid Read Views to all Wikivoyages by Q1, this will boost our confidence in extending Parsoid Read Views to all Wikipedias. We will measure the success of this rollout through detailed evaluations using the Confidence Framework reports, with a particular focus on Visual Diff reports and the metrics related to performance and usability. Additionally, we will assess the reduction in the list of potential blockers, ensuring that critical issues are addressed prior to wider deployment. | |
| WE5.1.3 | If we reroute the endpoints currently exposed under rest_v1/page/html and rest_v1/page/title paths to comparable MW content endpoints, then we can unblock RESTbase sunsetting without disrupting clients in Q1. | |
| WE5.1.4 | If we complete the remaining work to mitigate the impact of browsers' anti-tracking measures on CentralAuth autologin and move to a more resilient authentication infrastructure (SUL3), we will be ready to roll out to production wikis in Q2. | |
| WE5.1.5 | If we increase the number of relevant SonarCloud rules enabled for key MediaWiki Core repositories and refine the quality of feedback provided to developers, we will optimize the developer experience and enable them to improve the maintainability of the MediaWiki codebase in the future. This will be measured by tracking developer satisfaction levels and whether test group developers feel the tool is becoming more useful and effective in their workflow. Feedback will be gathered through surveys and direct input from developers to evaluate the perceived impact on their confidence in the tool and the overall development experience. | |
| WE5.1.7 | If we represent all content module endpoint responses (10 in total) in our MediaWiki REST API OpenAPI spec definitions, we will be able to implement programmatic validation to guarantee that our generated documentation matches the actual responses returned in code. | |
| WE5.1.8 | If we introduce support for endpoint description translation (ie: does not include actual object definitions or payloads) into our generated MediaWiki REST API OpenAPI specs, we can lay the foundation to support Wikimedia’s expected internationalization standards. | |
| WE5.2.3 | If we conduct an experiment to reimplement at least [1-3] existing Core and Extension features using a new Domain Event and Listener platform component pattern as an alternative to traditional hooks, we will be able to confirm our assumption of this intervention enabling simpler implementation with more consistent feature behavior. | |
| WE5.3.3 | If we instrument both parsers to collect availability of prior parses and timing of template expansions, and to classify updates and dependencies, we can prioritize work on selective updates (Hypothesis 5.3.2) informed by the quantification of the expected performance benefits. | |
| WE5.3.4 | If we can increase the capability of our prototype selective update implementation in Parsoid using the learnings from the 5.3.1 hypothesis, we can leverage more opportunities to increase the performance benefit from selective update. | |
| WE5.4.1 | If the MediaWiki engineering group is successful with release process accountability and enhances its communication process by the end of Q2 in alignment with the product strategy, we will eliminate the current process that relies on unplanned or volunteer work and improve community satisfaction with the release process. Measured by community feedback on the 1.43 LTS release coupled with a significant reduction in unplanned staff and volunteer hours needed for release processes. | |
| WE5.4.2 | If we research and build a process to more regularly upgrade PHP in conjunction with our MediaWiki release process we will increase speed and security while reducing the complexity and runtime of our CI systems, by observing the success of PHP 8.1 upgrade before 1.43 release. | |
| WE6.1.3 | If we collect insights on how different teams are making technical decisions we are able to gather good practices and insights that can enable and scale similar practices across the organization. | |
| WE6.1.4 | If we research solutions for indexing the code of all projects hosted in WMF’s code repositories, we will be able to pick a solution that allows our users to quickly discover where the code is located whenever dealing with incident response or troubleshooting. | |
| WE6.1.5 | If we test a subset of draft metrics on an experimental group of technical documentation collections, we will be able to make an informed decision about which metrics to implement for MediaWiki documentation. | Wikimedia Technical Documentation Team/Doc metrics |
| WE6.2.1 | If we publish a versioned build of MediaWiki, extensions, skins, and Wikimedia configuration at least once per day we will uncover new constraints and establish a baseline of wallclock time needed to perform a build. | mw:Wikimedia Release Engineering Team/Group -1 |
| WE6.2.2 | If we replace the backend infrastructure of our existing shared MediaWiki development and testing environments (from apache virtual servers to kubernetes), it will enable us to extend its uses by enabling MediaWiki services in addition to the existing ability to develop MediaWiki core, extensions, and skins in an isolated environment. We will develop one environment that includes MediaWiki, one or more Extensions, and one or more Services. | wikitech:Catalyst |
| WE6.2.3 | If we create a new deployment UI that provides more information to the deployer and reduce the amount of privilege needed to do deployment, it will make deployment easier and open deployments to more users as measured by the number of unique deployers and number of patches backported as a percentage of our overall deployments. | mw:SpiderPig |
| WE6.2.5 | If we move MultiVersion routing out of MediaWiki, we 'll be able to ship single version MediaWiki containers, largely cutting down the size of containers allowing for faster deployments, as measured by the deployment tool. | https://docs.google.com/document/d/1_AChNfiRFL3VdNzf6QFSCL9pM2gZbgLoMyAys9KKmKc/edit |
| WE6.2.6 | If we gather feedback from QTE, SRE, and individuals with domain specific knowledge and use their feedback to write a design document for deploying and using the wmf/next OCI container, then we will reduce friction when we start deploying that container. | T379683 |
| WE6.3.4 | If we enable the automatic deployment of a minimal tool, we will be able to evaluate the end to end flow and set the groundwork to adding support for more complex tools and deployment flows. | phab:T375199 |
| WE6.3.5 | By assessing the relative importance of each sustainability category and its associated metrics, we can create a normalized scoring system. This system, when implemented and recorded, will provide a baseline for measuring and comparing Toolforge’s sustainability progress over time. | phab:T376896 |
| WE6.3.6 | If we conduct discovery, such as target user interviews and competitive analysis, to identify existing Toolforge pain points and improvement opportunities, we will be able to recommend a prioritized list of features for the future Toolforge UI. | Phab:T375914 |
| Signals & Data Services (SDS) Hypotheses
[ SDS Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| SDS 1.1.1 | If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics. | |
| SDS1.2.1.B | If we test the accuracy and infrastructure constraints of 4 existing AI language models for 2 or more high-priority product use-cases, we will be able to write a report recommending at least one AI model that we can use for further tuning towards strategic product investments. | Phab:T377159 |
| SDS1.2.2 | If we study the recruitment, retention, and attrition patterns among long-tenure community members in official moderation and administration roles, and understand the factors affecting these phenomena (the ‘why’ behind the trends), we will better understand the extent, nature, and variability of the phenomenon across projects. This will in turn enable us to identify opportunities for better interventions and support aimed at producing a robust multi-generational framework for editors. | Learn more. |
| SDS1.2.3 | If we combine existing knowledge about moderators with quantitative methods for detecting moderation activity, we can systematically define and identify Wikipedia moderators. | T376684 |
| SDS1.3.1.B | If we integrate the Spark / DataHub connector for all production Spark jobs, we will get column-level lineage for all Spark-based data platform jobs in DataHub. | |
| SDS1.3.2.B | If we implement a frequently run Spark-based MariaDB MW history data querying job, reconciliate missing events and enrich them, we will provide a daily updated MW history wikitext content data lake table. | |
| SDS2.1.1 | If we create an integration test environment for the proposed 3rd party experimentation solution, we can collaborate practically with Data SRE, SRE, QTE, and Product Analytics to evaluate the solution’s viability within WMF infrastructure in order to make a confident build/install/buy recommendation. | mw:Data Platform Engineering/Data Products/work focus |
| SDS2.1.3 | If the Growth team learns about the Metrics Platform by instrumenting a Homepage Module on the Metrics Platform, then we will be prepared to outline a measurement plan in Q1 and complete an A/B test on the new Metrics platform by the end of Q2. | |
| SDS2.1.4 | If we conduct usability testing on our prototype among pilot users of our experimentation process, we can identify and prioritize the primary pain points faced by product managers and other stakeholders in setting up and analyzing experiments independently. This understanding will lead to the refinement of our tools, enhancing their efficiency and impact. | |
| SDS2.1.5 | If we design a documentation system that guides the experience of users building instrumentation using the Metrics Platform, we will enable those users to independently create instrumentation without direct support from Data Products teams, except in edge cases. | задача T329506 |
| SDS2.1.7 | If we provide a function for user enrollment and a mechanism to capture and store CTR events to a monotable in a pre-declared event stream we can ship MPIC Alpha in order to launch an basic split A/B test on logged in users. | |
| SDS2.2.2 | If we define a standard approach for measuring and analyzing conversion rates, it will help us establish a collection of well-defined metrics to be used for experimentation and baselines, and start enabling comparisons between experiments/projects to increase learning from these. | |
| SDS2.3.1 | If we conduct a legal review of proposed unique cookies for logged out users, we can determine whether there are any privacy policy or other legal issues which inform the community conversation and/or affect the technical implementation itself. | |
| Future Audiences (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| FA1.1.1 | If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform. | Experiment:Add a Fact |
| Product and Engineering Support (PES) Hypotheses
[ PES Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| PES1.2.4 | If we research the Task Prioritization focus area in the Community Wishlist in early Q2, we will be able to identify and prioritize work that will improve moderator satisfaction, which we can begin implementing in Q3. | |
| PES1.2.5 | If we are able to publish and receive community feedback on 6+ focus areas in Q2, then we will have confidence in presenting at least 3+ focus areas for incorporation in the 2025-26 annual plan. | |
| PES1.2.6 | By introducing favouriting templates, we will improve the number of templates added via the template dialog by 10%. | |
| PES1.3.4 | If we create an experience that provides insights to Wikipedia Audiences about their community over the year, it will stimulate greater connection with Wikipedia – encouraging engagement in the form of social sharing, time spent interacting on Wikipedia, or donation. | |
| PES1.4.1 | If we draft an SLO with the Editing team releasing Edit Check functionality, we will begin to learn and understand how to define and track user-facing SLOs together, and iterate on the process in the future. | |
| PES1.4.2 | If we define and publish SLAs for putting OOUI into “maintenance mode”, growth of new code using OOUI across Wikimedia projects will stay within X% in Q1. | |
| PES1.4.3 | If we map ownership using the proposed service catalog for known owned services in Q1, we will be able to identify significant gaps in service catalog as it helps in solving the SLO culture by the end of the year. | |
| PES1.5.1 | If we finalize and publish the Edit Check SLO draft, practice incorporating it in regular workflows and decisions, and draft a Citoid SLO, we’ll continue learning how to define and track user-facing and cross-team SLOs together. | |
| PES1.5.2 | If we clarify and define in writing a document with set of roles and responsibilities of stakeholders throughout the service lifecycle, this will enable teams to make informed commitments in the Service Catalog, including SLOs | |
К3
The third quarter (Q3) of the WMF annual plan covers January-March.
| Wiki Experiences (WE) Hypotheses
[ WE Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q3 text | Details & Discussion |
| WE1.1.3 | If we consult 20 event organizers and 20 WikiProject organizers on the best use of topics available via LiftWing, then we can prioritize revisions to the topic model that will improve topical connections between events and WikiProjects. | |
| WE1.1.5 | If we implement at least 2 methods to discover the Collaboration List, then we will increase pageviews of the Collaboration List, thereby allowing more people to discover events and WikiProjects that interest them | |
| WE1.1.6 | If we identify and then contact 20 affiliates and/or groups connected to wikis that have high organizer activity in Q2, we can build advocacy networks that will set the stage for the extension being enabled on 3 more wikis by the end of Q3. | |
| WE1.1.7 | If we add at least 2 improvements to the Collaboration List for events, then at least 50% of surveyed respondents will find the Collaboration List to be more useful in finding events than before the changes were made. | |
| WE1.2.5 | If we conduct an A/B/C test with the alt-text suggested edits prototype in the production version of the iOS app we can learn if adding alt-text to images is a task newcomers are successful with and ultimately, decide if it's impactful enough to implement as a suggested edit on the Web and/or in the Apps. | |
| WE1.2.7 | If we deploy the Multi-Check sidebar (desktop) at all wikis where the Reference Check is available, we will unlock our ability to present multiple Edit Checks within a new "mid-edit" moment without negatively impacting the quality of new content edits newcomers publish. | |
| WE1.2.9 | If we surface the ‘Add a Link’ Structured Task to new account holders who are reading Wikipedia articles through an A/B test on pilot wikis, then we expect to increase the percentage of these people who constructively activate on mobile by 10% compared to the control group. | |
| WE1.2.10 | If the Structured Content team improves the code health of the Article-level Image Suggestions data pipeline to meet 90% of code deduplication, article and section level image suggestion separation on the index level; and adapt the image suggestion evaluation tool to be able to get baselines for quality of suggestions for target wikis, then the “Add an Image” task can be released to newcomers on additional Wikipedias. This will enable the Growth team to pursue a follow-up hypothesis focused on increasing constructive activation across at least 10 additional Wikipedias. | |
| WE1.2.11 | If we release the “Add a Link” Structured Task to at least 5% percent of newcomers on English Wikipedia, then newcomers with access to this structured task will demonstrate a constructive activation rate on mobile that is 10% percent higher than the baseline, as measured through an A/B test. | |
| WE1.3.3 | If we improve the user experience and features of the Nuke extension during Q2, we will increase administrator satisfaction of the product by 5pp by the end of the quarter. | |
| WE1.3.4 | If we improve the user experience and features of Recent Changes, we will increase administrator satisfaction of the product by 5pp. | |
| WE1.5.1 | If we create a strategy brief by February 2025, including a prioritized strategy and trade-offs, we can use it as one of the main inputs for APP25/26. | |
| WE1.5.2 | If we develop a unified measurement strategy, we will enable evaluation of the multi-year product strategy for contributors and set the landscape for prioritization of next steps in metric development and reporting | |
| WE2.1.5 | If we expose topic-based translation suggestions more broadly and analyze its initial impact, we will learn which aspects of the translation funnel to act on in order to obtain more quality translations. | |
| WE2.1.6 | If we offer list-making as a service, we’ll enable at least 5 communities to make more targeted contributions in their topic areas as measured by (1) change in standard quality coverage of relevant topics on the relevant wiki and (2) a brief survey of organizer satisfaction with topic area coverage on-wiki. | |
| WE2.1.7 | "If we developed a proof of concept that adds translation tasks sourced from WikiProjects and other list-building initiatives, and present them as suggestions within the CX mobile workflow, then more editors would discover and translate articles focused on topical gaps. By introducing an option that allows editors to select translation suggestions based on topical lists, we would test whether this approach increases the content coverage in our projects. |
|
| WE2.2.4 | If we document the pre-incubator, incubator, and post-incubator journeys for the five pilot wikis with quantitative and qualitative data, we will be able to better support new languages in the future. | |
| WE2.4.4 | If we develop a live proof-of-concept, using MediaWiki’s async content processing pipeline, for the first use case of Wikifunctions in Wikipedia, we will be ready to switch it on in the new year for the Dagbani community. | |
| WE2.6.1 | If we propagate the integration of Wikifunctions from Test2Wiki to a small production Wikipedia with the MVP user experience, we will see the feature used organically without being reverted. | |
| WE2.6.2 | If we make it possible to translate sentences in Wikifunctions from something “abstract” like a function, we will see an organic increase of at least 5 multilingual functions that generate natural language sentences. This is a milestone towards building an Abstract Wikipedia. | |
| WE3.1.6 | If we introduce a personalized rabbit hole feature in the Android app and recommend condensed versions of articles based on the types of topics and sections a user is interested in, we will learn if the feature is sticky enough to result in multi-day usage by 10% of users exposed to the experiment over a 30-day period, and a higher pageview rate than users not exposed to the feature. | |
| WE3.1.8 | (Q2-Q3, web) If we build one feature which provides additional article-level recommendations, we will see an increase in clickthrough rate of 10% over existing recommendation options and a significant increase in external referrals for users who actively interact with the new feature. | |
| WE3.1.9 | If we create a daily-use Wikipedia-based trivia game in the Android app, logged-out readers who engage with this feature will open the app on multiple days within a 20-day period at a rate at least 5% higher than those who do not engage with the feature. | |
| WE3.1.10 | If we develop and test design prototypes for tabbed browsing in the Wikipedia iOS app, we will gain and incorporate actionable insights on usability, while also enabling engineers to assess technical feasibility of different approaches, building a solid foundation for adding Tabs to the app in Q4. | |
| WE3.1.11 | If we make the article search bar more prominent, we will increase the number of users who initiate searches by 8%, possibly leading to a 1% increase in search retention rate for logged out users. | |
| WE3.2.3 | If we make the “Donate” button in the iOS App more prominent by making it one click or less away from the main navigation screen, we will learn if discoverability was a barrier to non banner donations. | |
| WE3.2.4 | If we update the contributions page for logged-in users in the app to include an active badge for someone that is an app donor and display an inactive state with a prompt to donate for someone that decided not to donate in app, we will learn if this recognition is of value to current donors and encourages behavior of donating for prospective donors, informing if it is worth expanding on the concept of donor badges or abandoning it. | |
| WE3.2.7 | Increasing the prominence of entry points to donations on the logged-out experiences of the Minerva web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY. | |
| WE3.2.8 | If we make improvements to the personalised and collective content of the iOS apps’ Year in Review, and scale its availability, we will learn if this is an effective fundraising method. | |
| WE3.4.1 | If we were to explore the feasibility by doing an experiment of setting up smaller PoPs in cloud providers like Amazon, we can expand our data center map and reach more users around the world, at reduced cost and increased turn-around time. | |
| WE3.5.1 | If we make it possible for Commons Data namespace pages to be categorized and surface their usage across wikis, Commons admins will have the minimum tools they need to manage the increased usage of the Data namespace, ensuring we can sustainably scale up deployment to all wikis | |
| WE3.5.2 | If we improve test coverage and documentation for Charts, we will be comfortable handing off maintenance and future feature development [to reading engineering, contractors, and volunteers], allowing us to wind down the project and task force. | |
| WE3.5.3 | If we seed the Community Wishlist with Charts features we know volunteers have asked for that are out of scope for the MVP, there will be a central place for volunteers and staff to discuss future Charts-related work, allowing the future maintainers to manage expectations and source input for annual planning | |
| WE4.1.3 | If we deploy the Incident Reporting System MVP to x more wikis (representative sample) we will be able to gather valuable data that will help us identify patterns of harmful conduct across wikis | |
| WE4.1.4 | If we engage stakeholders across key departments in structured discussions, we can collaboratively define a shared vision and realistic scope for the Incident Reporting System, aligned with organizational priorities and compliance requirements, providing valuable insights to inform annual planning. | |
| WE4.2.11a | If we define a terminology and thresholds for revert risk scores across wikis, we will make it possible to use revert risk scores in a wider range of user facing anti-abuse tools. This hypothesis impacts the WE4.2 KR by doing the background work necessary to build upon revert risk scores. | |
| WE4.2.20 | Implement a trial enablement which will gather data on the efficacy of the new CAPTCHA on enabled wikis at preventing sockpupppet account creation and bot-based spam edits to measure the efficacy and value of a production rollout of the new technology | |
| WE4.2.15 | If we analyze attributes of blocked user accounts on multiple wikis, we will identify patterns across these accounts and assign weights based on the relative importance of each attribute on block rates to use in calculating a user account reputation score. The success of this hypothesis would be measured by whether we are successful in defining a formula for multiplying attributes of an account to provide an account reputation score that maps to blocked users. | |
| WE4.2.10 | If we add two more data points to the client hints collection pipeline, we will have more entropy to better identify sockpuppets and potential ban evasion. We will know we are successful when we are able to use the client hints data to identify X% of confirmed sock puppets on en:Wikipedia:Sockpuppet investigations. Or when we are able to use the collected data to identify Y% of suspected ban invasion pair. This hypothesis directly contributes to the KR by providing new signals (browser canvas fingerprint, list of fonts) that will allow CheckUsers to more precisely target sockpuppets and accounts attempting to evade bans. | |
| WE4.2.14b | "If we introduce IP reputation data variables in AbuseFilter variables, we will enable mitigations that can reduce the amount of submissions of vandalism, spam and abuse. Context:This directly contributes to the KR goal by introducing a new signal (IP reputation) to allow for more precision in mitigations (only actions matching the variable are impacted). We could measure the impact of this hypothesis by examining the volume of reverted edits on wikis before/after the variables are introduced. (Other ideas?) We would initially introduce variables like “is likely a VPN” or “is likely a proxy”. We could also consider exposing other variables, depending on discussions in T354599: Make IP reputation available as a variable in AbuseFilter." |
|
| WE4.2.14a | If we analyze IP reputation data associated with problematic editing activity and user accounts, we will be able to prioritize a set of IP reputation facets that can be provided as variables in AbuseFilter. This analysis would then be used by WE4.2.14b later Q3 to build out the variables in AbuseFilter, along with specific guidance about what mitigations would be reasonable to use alongside a given set of IP reputation variables. For example, the recommended mitigation for one IP reputation variable might be to block edits outright, while the recommended mitigation for a different IP reputation variable might be to tag the edit for further review, or to show a CAPTCHA. | |
| WE4.2.18a | If we design and build a clickable component to display public data related to user account reputation to functionaries, we will be able to learn if this is useful to them by observing the number of repeat usages of the tool | |
| WE4.3.3b | If we deploy a proof of concept of the 'Liberica' load balancer, we will measure a 33% improvement in our capacity to handle TCP SYN floods | |
| WE 4.3.6b | If we integrate the output of the models we built in WE 4.3.1 with the dynamic thresholds of per-ip concurrency limits we've built for our TLS terminators in WE 4.3.2, we should be able to increase our ability to neutralize automatically attacks with 20% more volume, as measured with the simulation framework we're building. | |
| WE 4.3.8 | If we deploy the liberica load balancers to all datacenters, we will increase the capacity to handle TCP SYN floods by 33% everywhere | |
| WE 4.3.9 | If we establish and follow a verified procedure for the regular testing of large-scale abuse scenarios, then we will consistently measure and improve our ability to respond effectively to such incidents. | |
| WE 4.3.10 | If we define a policy for review and maintenance of requestctl rules, we will keep the system understandable and manageable over time | |
| WE 4.3.11 | If we can identify patterns and separate web scrapping from general traffic, we will be able to create reporting systematically to reduce the traffic and maintain sustainability of our serving infrastructure. | |
| WE 4.4.3 | If we improve the interface of the iOS app, we will be able to clearly communicate how temporary accounts work to users as they edit without logging in, and the iOS app will be prepared for the imminent release of temporary accounts to all projects. | |
| WE 4.4.4 | If we update the data models in the data lake, and the corresponding data pipelines and dashboards, to accurately represent the new user account types, we'll be able to provide accurate analytics reporting related to activities of corresponding user types. | |
| WE 4.4.5 | If we resolve all remaining product, design and legal blockers for the engineering work that needs to be done before the major pilots deployment, we will be able to complete the engineering work on time for the next round of pilot deployment. | |
| WE5.1.9 | If we enable Parsoid on Incubator and all newly created Wikis by Q2, we’ll further ensure sustainability by not allowing the number of wikis that run on the legacy parser to grow. We will measure the success of this rollout through detailed evaluations using the Confidence Framework reports, with a particular focus on Visual Diff reports and the metrics related to performance and usability. Additionally, we will assess the reduction in the list of potential blockers, ensuring that critical issues are addressed prior to wider deployment. | |
| WE5.1.11 | The Observability team aims to sunset graphite by enabling read-only mode and disabling new metric ingest by the end of Q3 FY2024/2025. To achieve this goal, the team has set a 90% coverage target of converting the remaining dashboard and retiring legacy metrics and panels that point to graphite metrics. | |
| WE5.1.12 | If we release an interactive documentation sandbox for MediaWiki REST APIs, it will introduce a repeatable pattern for low maintenance, high quality API documentation while making the APIs easier to adopt for developers around the world. This will ensure that our API documentation is fully up to date, testable, and localized for generations of developers, while reducing the maintenance cost and increasing sustainability for API publishers. | |
| WE5.1.13 | If we roll out SUL3 for all existing accounts and new account creation across all wikis, we will ensure compatibility with browser anti-tracking measures and improve security, by moving authentication to a dedicated domain that requires user interaction and further prevents XSS vulnerabilities. | |
| WE5.2.5 | If we model at least one more page state change (e.g. PageDelete) as a PHP event and drive further adoption of in-process domain events across MediaWiki components and extensions currently utilizing event-like hooks, then we will build confidence in events as a platform sustainability pattern by improving component boundaries, improving interface flexibility, and reducing high risk boilerplate code. | |
| WE5.2.6 | If we explore designing an architecture for serializing and broadcasting events generated within MediaWiki core, we will create a foundation for offering first class event support that will enable us to consume events outside of the originating MediaWiki PHP process (e.g. JobQueue, EventBus). This will make MediaWiki data more reusable beyond the MediaWiki platform. | |
| WE5.2.7 | If we identify and align on a set of domains that can be used for MediaWiki platform events by the end of Q3, we will have an initial map of core component boundaries and can improve consistency across MediaWiki interfaces by utilizing the same domains for the MediaWiki REST API modules. | |
| WE5.2.8 | If we clearly define the concept of extension interfaces in the MediaWiki documentation, we can make it easier to develop new functionality on top of MediaWiki and provide a clearer path for defining new extension interfaces, such as Domain Events. We will measure this by identifying places in the documentation where extension interfaces are presented as “extension types” and replacing 100% of those instances. | |
| WE5.4.3 | If we enable developers with PHP8.1 MediaWiki images and infrastructure for testing them on Kubernetes, they will be able to validate and certify them to be deployed to production. If we also develop infrastructure for progressive traffic migration and use it to safely migrate production to 8.1, this helps MediaWiki drop unsupported PHP versions in the upcoming May release. Success will be observed by the ability to ramp up production traffic to PHP 8.1 instances. | |
| WE5.4.4 | If we decouple the legacy dumps processes from their current bare-metal hosts and instead run them as workloads on the DSE Kubernetes cluster, this will bring about demonstrable benefit to the maintainability of these data pipelines and facilitate the upgrade of PHP to version 8.1 by using shared mediawiki containers. | |
| WE5.4.6 | If the beta cluster is configured to run MediaWiki with PHP 8.1 then the Data Platform Engineering group and their SRE team will be able to validate whether the existing dumps code functions correctly, or whether any significant functional changes would be required. | |
| WE5.5.1 | If, by the end of January, we are able to measure and monitor Wikimedia hosted dumps traffic using log data, we will have clarity on how users are consuming the different dumps formatting options and access points. This will unblock additional metrics for overall consumption across streams, and improve our understanding of what users care about in terms of recency, data completion, and structure, so that we can tailor the overall API strategy accordingly. | |
| WE5.5.2 | If, by the end of Q3, we create a consolidated view of developer personas and use cases collected through a listening and discovery tour, then we will uncover lesser understood gaps and opportunities in this space. This will leverage existing work completed by stakeholder teams in their respective areas (eg: Dumps, WME), in addition to creating new insights by conducting interviews with WMF staff, technical volunteers, and high impact content reuse partners (eg: WME customers and prospects). | |
| WE6.1.7 | If we review the user feedback, decide on a code search and code browsing solution, deploy it to the production infrastructure as an officially supported service and enable indexing of both existing and new repositories from both code tracking systems, we will increase the scope of code that is indexed and searchable and simplify the process of locating code in day to day operations as well as during incident response. | |
| WE6.1.8 | If we analyze the documentation metrics scores from our test dataset, we can evaluate the usefulness and effectiveness of the draft metrics, collect feedback, and provide actionable insights for implementing automated metrics computation | |
| WE6.1.9 | If we transition 5 additional access groups to management within the Identity Management system, it will enhance access governance by improving efficiency, significantly reducing TOIL and improving the onboarding experience for incoming Wikimedia staff and new members of the technical communities. | |
| WE6.2.2 | If we replace the backend infrastructure of our existing shared MediaWiki development and testing environments (from apache virtual servers to kubernetes), it will enable us to extend its uses by enabling MediaWiki services in addition to the existing ability to develop MediaWiki core, extensions, and skins in an isolated environment. We will develop one environment that includes MediaWiki, one or more Extensions, and one or more Services. | |
| WE6.2.3 | If we create a new deployment UI that provides a web interface for deployments that is open to existing deployers it will allow backporters to have a shared view of deployments in progress and provide greater visibility for deployments in progress. | |
| WE6.2.5 | If we publish a planning doc to move single-version routing out of MediaWiki and gather comments from stakeholders on the implementation, then we will reduce friction during implementation. | |
| WE6.2.6 | If we gather feedback from QTE, SRE, and individuals with domain specific knowledge and use their feedback to write a design document for deploying and using the wmf/next OCI container, then we will reduce friction during when we start deploying that container. | |
| WE6.2.7 | If we make a deployment web UI available behind our single sign-on system and open it to the Wikimedia development community it will increase the number of backport deployers. | |
| WE6.2.8 | Continuing on the capabilities of Catalyst to deliver pre-merge test environments of MediaWiki and its extensions & skins on Kubernetes, if we facilitate deployments of pre-merge patches for MediaWiki services, by running pre-merge tests for Wikifunctions, then contributors will be able test more MediaWiki projects with stable, well-defined, isolated test environments. | |
| WE6.2.9 | If we test the proposed MediaWiki routing implementation with a single wiki, we will have proven the plan works and can proceed with an accelerated rollout to other wikis and we will be able to route a single version container to Wikimedia’s wiki hosting infrastructure. | |
| WE6.3.7 | By establishing detailed measurement criteria and evolution guidelines for our sustainability framework, we will create an actionable scoring system for platform improvements. | |
| WE6.3.8 | Engaging with prospective users to explore Toolforge UI’s early design prototype will help us uncover improvement opportunities and risks to be addressed in a follow-up iteration. | |
| Signals & Data Services (SDS) Hypotheses
[ SDS Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q3 text | Details & Discussion |
| SDS1.1.1 | If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics. | |
| SDS1.1.2 | If we assess the impact of the new South American data center (MAGRU) on our relevance metric (unique devices), we will be able to produce a report that provides insights into the return on investment of current and future data center investments. | |
| SDS1.3.1.B | If we integrate the Spark / DataHub connector for all production Spark jobs, we will get column-level lineage for all Spark-based data platform jobs in DataHub. | |
| SDS1.3.2.B | If we implement a frequently run Spark-based MariaDB MW history data querying job, reconciliate missing events and enrich them, we will provide a daily updated MW history wikitext content data lake table. | |
| Future Audiences (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q3 text | Details & Discussion |
| FA1.1.1 | If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform. | |
| Product and Engineering Support (PES) Hypotheses
[ PES Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q3 text | Details & Discussion |
| PES1.1.2 | If we choose three main areas in which to highlight efforts being made to improve our culture of review, and communicate about them in the right channels, we will see improvements in the responses for iterative development, decision-making, and collaboration in the next culture survey (Jan 2025). | |
| PES1.1.3 | If we send a revised culture survey, we will identify areas where we can provide support to managers to continue strengthening our culture of review. | |
| PES1.3.5 | If we create a Wikipedia-based game for daily use that highlights the connections across vast areas of knowledge, it will encourage consumers to visit Wikipedia regularly and facilitate active learning, leading to increased interaction with content on Wikipedia and longer session lengths. | |
| PES1.3.6 | If we apply lessons from the first Sprinthackular to a second event focused on improving prototyping tools and processes, at least one Sprinthackular project will show enough value and promise that it can be integrated into the APP. We'll also be able to develop a repeatable Sprinthackular framework that other teams will recognize that they can adopt to explore any focus area! | |
| PES1.5.1 | (Starting Oct 1) If we finalize and publish the Edit Check SLO draft, practice incorporating it in regular workflows and decisions, and draft a Citoid SLO, we’ll continue learning how to define and track user-facing and cross-team SLOs together. | |
| PES1.5.2 | (Starting Oct 1) If we clarify and define in writing a document with set of roles and responsibilities of stakeholders throughout the service lifecycle, this will enable teams to make informed commitments in the Service Catalog, including SLOs | |
Разъяснение блоков
Вики-опыт
Цель этого раздела — эффективно предоставлять, улучшать и внедрять инновации в вики-опыт, которые позволяют распространять свободные знания по всему миру. Этот «блок» соответствует рекомендациям #2 по Стратегии Движения (Улучшение Пользовательского Опыта) и #3 (Обеспечение Безопасности и Инклюзивности). Наша аудитория включает в себя всех, кто сотрудничает на наших веб-сайтами, а также читателей и других потребителей свободных знаний. Мы поддерживаем веб-сайт, входящий в топ-10 мировых сайтов, и многие другие важные свободные культурные ресурсы. Требования к производительности и времени безотказной работы этих систем не уступают требованиям крупнейших технологических компаний мира. Мы предоставляем пользовательские интерфейсы для вики, переводы, API для разработчиков (и многое другое!), а также вспомогательные приложения и инфраструктуру, которые формируют надежную платформу для совместной работы добровольцев по распространению свободных знаний по всему миру. Наши цели из этого «блока» должны позволить нам усовершенствовать наши основные технологии и возможности, убедиться, что мы постоянно совершенствуем опыт редакторов-добровольцев и редакторов с расширенными правами наших проектов, улучшить работу всех технических участников, работающих над улучшением интерфейса вики, и обеспечить лучший опыт для читателей и потребителей свободных знаний по всему миру. ы будем делать это с помощью продукта и технологий, а также с помощью исследований, коммуникаций и маркетинга. Мы ожидаем, что в этом «блоке» у нас будет не больше пяти целей.
Знания создаются людьми! И в результате наш годовой план будет сосредоточен на контенте, а также на людях, которые вносят свой вклад в создание контента, и на тех, кто получает к нему доступ и читает его.
Наша цель — разработать операционный план, основанный на существующей стратегии, главным образом на наших гипотезах о участнике, потребителе и «колесо». Основным изменением в этих целях является акцент на содержательной части «колеса» и изучение того, что может понадобиться от нас нашим редакторам с расширенными правами сейчас, с целью определения показателей здоровья сообщества в будущем.
Сообщения и Служба Данных
Чтобы соответствовать рекомендациям Стратегии Движения по «Обеспечение равенства во время принятии решений» (Рекомендация #4), «Улучшение Пользовательского Опыта» (Рекомендация #2) и «Оценка, Итерация и Адаптация» (Рекомендация #10), лица, принимающие решения по всему Движению Викимедиа, должны иметь доступ к надежным, актуальным и своевременным данным, моделям, аналитическим материалам и инструментам, которые могут помочь им оценить влияние (как реализованное, так и потенциальное) своей работы и работы своих сообществ, что позволит им принимать более эффективные стратегические решения.
В блоке «Сообщения и Служба Данных» мы определили четыре основные аудитории для анализа данных: сотрудники Фонда Викимедиа, аффилиации Викимедиа, разработчики, которые повторно используют наш контент, и исследователи Викимедиа, и мы определяем приоритеты и удовлетворяем потребности этих аудиторий в данных и аналитической информации. Наша работа будет охватывать целый ряд мероприятий: определение пробелов, разработка показателей, построение каналов передач для вычисления показателей и разработка путей исследования данных и сообщений, которые помогут лицам, принимающим решения, более эффективно и счастливо взаимодействовать с данными и аналитическими данными.
Будущая аудитория
.svg)
Цель этого «блока» изучить стратегии расширения за пределы нашей существующей аудитории читателей и участников, стремясь по-настоящему охватить всех в мире в качестве важнейшей инфраструктуры экосистемы свободных знаний. Этот блок соответствует рекомендации #9 по Стратегии Движения (Инновации в области свободных знаний). Все больше и больше людей получают информацию в формах, которые отличаются от нашего традиционного предложения веб-сайта со статьями: люди используют голосовых помощников, проводят время за просмотром видео, используют с искусственный интеллект и многое другое. В этом «блоке» мы предложим и проверим гипотезы о потенциальном долгосрочном будущем экосистемы свободных знаний и о том, как мы будем ее важнейшей инфраструктурой. Мы будем делать это с помощью отдела продукта и технологий, а также с помощью исследований, сотрудничества и маркетинга. По мере того, как мы определяем перспективные будущие положения, уроки, извлеченные из этого раздела, будут влиять на последующие годовые планы и расширяться в блоках #1 и #2, направляя наши предложения продуктов и технологий туда, где они должны быть, чтобы служить тем, кто ищет знания в будущем. Наши задачи в этом блоке должны побуждать нас экспериментировать и исследовать, поскольку мы ориентированы на видении будущего свободных знаний.
Добавочные блоки
У нас также есть два других «добавочного блока», которые состоят из областей критических функций, которые должны существовать в основе для поддержки наших основных операций, и некоторые из которых у нас общие с любой организацией, занимающейся разработкой программного обеспечения. Эти «добавочные блоки» не будут иметь собственных задач высшего уровня, но будут вносить вклад в достижение целей высшего уровня других групп и поддерживать их. Они являются:
- Базовая инфраструктура. В этом блоке представлены команды, которые поддерживают и развивают наши центры обработки данных, наши вычислительные платформы и платформы хранения данных, сервисы для их эксплуатации, инструменты и процессы, обеспечивающие работу наших общедоступных сайтов и сервисов.
- Продуктовые и инженерные услуги. В эту категорию входят команды, которые работают «в масштабе», предоставляя услуги другим командам, которые повышают производительность и оперативность этих команд.