ウィキメディア財団年次計画/2024-2025/製品&技術OKR類

This page is a translated version of the page Wikimedia Foundation Annual Plan/2024-2025/Product & Technology OKRs and the translation is 45% complete.

Outdated translations are marked like this.

当文書はウィキメディア財団製品技術部門の2024年-2025年次予算の手順のうちパート1に当たります。当部門草稿の「目的と主な成果」（OKRs＝objectives and key results）の提示を趣旨とします。昨年度に始めた 作業のポートフォリオを引き継いでいます（通称「バケット」）。

ウィキメディア運動の直面する最も差し迫った問題として私が信じるところに関して、去る11月、私どもでは広く皆さんと対話しました。すなわち、ウィキペディアをはじめウィキメディアの全プロジェクトは多世代にわたる存在であると、私たちはどのようにすれば保証できるでしょうか？時間を割いてこの質問を真剣に検討して、直接、私に答えてくださった皆さんに感謝申したく、また皆さんの回答にじっくりと目を通しましたので、私の方からも学んだことを共有しようと考えました。

第一にボランティアの皆さんがなぜ貢献するか、理由はひとつに絞れません。複数世代のボランティア育成には、人々がなぜ私たちのプロジェクトに時間を費やしてくれるのか、多くの理由をもっと掘り下げて理解するべきです。次に、私たちがどんな点で他と差別化されているか焦点を当てるべきです。インターネット上やプラットフォーム上では新世代の観衆の注目を集めようと先を争うあまり、偽情報や偽情報が蔓延していても、私たちには信頼できるコンテンツを提供する能力があります。一例として、もし情報の欠落が不公平や差別や偏見に根ざしていた可能性があるなら、私たちは人類の知識の総和を集めて世界に届けるという使命のため、それらをも拾い上げ確実に使命を果たそうとしています。インターネットは、人工知能と豊富な経験値によってめまぐるしく変化していきますが、私たちのコンテンツはその中できちんと機能し、その重要性を保つ必要があります。最後にこの活動に対する資金供給を長く保つには、製品と収益を横断する共通戦略を築き、長命な資金提供の方法を見つけなければなりません。

これらのアイデアは2024年-2025年のウィキメディア財団年次計画に反映する予定であり、本日、皆さんとその最初の部分を共有したく、製品・技術の取り組み目標の草案の形でお見せします。昨年と同様、私たちの年次計画は全体として観衆とプラットフォームの技術面のニーズを中心に据えているのですが、果たして焦点を当てた課題が正しいかどうか、皆さんのフィードバックをお待ちしています。この数ヵ月を費やして話し合い：2024やメーリング・リスト、トークページやコミュニティのイベントなどの場で、今後1年間の製品・技術戦略に関してコミュニティの皆さんからアイデアを聴き集めており、それに基づいて組み立ててあります。以下で目標の草案全体に目を通してください。

ここでいう「目標」とは、当財団が来年度に取り組む製品技術プロジェクトを形作る高次の方向性です。（objective）。当財団の戦略方向性を意図的に広範に示してあり、要点は、多くの注力分野を想定できる中で当財団の提案としてどのような課題分野を来年度は優先すべきか表しています。現状、これを皆さんと共有して、当該年の予算や測定可能な目標の確定前に、私たちの初期段階の考え方の形成にコミュニティの皆さんからご協力いただきたいと考えます。

フィードバック

特にフィードバックを期待する分野の1つは「ウィキ体験」と名付けた一連の作業です。（「Wiki Experiences」。）「ウィキ体験」とは人々が直接、ウィキを使うとき、それぞれの人が投稿者や消費者あるいは寄付者のどの立場であっても効率的な方法を提供し、改善し、革新する方法と関連します。これには中核の技術と機能を支える作業が含まれ、ボランティア編集者 — 特に拡張権限を預かる編集者 — の体験向上に繋がるように、もっと良い機能とツールを、翻訳サービスを、プラットフォームの更新を手がけていきます。

ここでは計画をめぐる直近の論議から一部をまとめ、また私たちの発想にどのように磨きをかけるべきか皆さん全員が考える助けになるよう、以下の質問を置いてみます。

ボランティアとしてウィキメディアのプロジェクトに参加するなら、やりがいを感じる体験であるべきです。さらにオンラインの協働作業という経験は、ボランティアの皆さんが何度でも戻ってくる主な理由であるべきだと私たちは考えます。皆さんが無償の編集にやりがいを感じるため、お互いに協力して信頼できるコンテンツを構築するために、欠かせないものはいったい何でしょうか？
私たちのコンテンツの信頼性は、世界に贈るウィキメディア固有の貢献の一部を構成し、これがあるからこそ、人々は私たちのプラットフォームに何度もアクセスしコンテンツを利用し続けるのです。コミュニティはプロジェクトごとに品質のガードレールを設定しており、その範囲内に収まりつつ、信頼に足りるコンテンツをより迅速に伸ばすには、何を構築するとよいでしょうか？
関連性を保ちながら、ウィキメディアが大規模な他のオンライン・プラットフォームと競争するには、新世代の消費者にコンテンツと自身のつながりを感じてもらう必要があります。どうすれば、読者や寄付者にとってコンテンツが見つかりやすくなり、操作も楽になるでしょうか？
虐待がオンラインに蔓延する今の時代、コミュニティもプラットフォームも、そのためのシステムも、確実に保護する必要があります。それと並行して一方で私たちはコンプライアンス義務の進化に直面し、他方で世界の政策立案者は個人情報の保護、自己同一性やオンラインの情報共有を根付かせようとしています。これらの課題にきちんと対処するには、虐待と戦う能力をどのように改善すれば良いでしょうか？
メディアウィキ（MediaWiki）とはソフトウェアのプラットフォームでありインタフェースであり、ウィキペディアが機能するように働くため、公開で大規模な多言語コンテンツを作成し修正し保存と発見ができるようにするため、常にサポートが必要です。今年、何を決定しプラットフォームをどのように改善すると、このMediaWiki を持続可能にできるでしょうか？

議論

–– Selena Deckelmann

趣旨

現状では、計画の最高レベル - "目標" を公開しています。

次のレベル - 3月に最終的な目標ごとの"主要な成果"（以下KR）^※を、このページに公開しました。（"※"＝Key Results。）

それぞれの KR には下敷きとなる"仮説" は以下に示したとおりで、年間を通じて関連プロジェクト／チームのウィキページで更新していき、そのタイミングは時点を問わず、教訓が得られたときに更新する予定です。

ウィキの経験（WE）と目的
目的	目的範囲	目的	目的の内容	主催者
WE1 議論	投稿者の経験	投稿者は経験豊富であっても初学者であってもオンラインで連携して、もっと簡単に、ストレスを減らして信頼できる百科事典を構築します。	今後もウィキペディアが活気に満ちたものであり続けるには、ボランティア育成の対象を複数の世代に広げ、投稿が人々にとって魅力的になる取り組みをしなければなりません。必要な投資はボランティアの世代ごとに異なり -- 経験豊富な投稿者は強力なワークフローの合理化と修復を求めるとするなら、初学者は一人ひとりにとって意味のある編集方法を新しく手当てする必要があります。そして最も影響力のある作業をする上で肝心なのは、どの世代であっても、すべての貢献者が互いにつながり、協力できることです。この目的達成に向けて経験豊富な貢献者向けに重要なワークフローを改善し、初学者向けには建設的な貢献を阻害する壁を下げ、共通の事柄に関心を寄せるボランティア同士が相手を見つけたり互いに意思疎通できる方法に投資します。	Marshall Miller
WE2 議論	百科事典にふさわしい内容	知識の格差を効果的に縮めるには、アクセスしやすいツールやサポートシステムをコミュニティの皆さんに提供して、活用や改善のしやすさが百科事典に信頼性を確保したコンテンツを増やしていきます。	主にウィキペディアにある百科事典のコンテンツを増やしたり改善するには、取り組みの継続と革新を介しています。投稿者がニーズに合わせて使う（技術および技術以外の両面の）ツールとリソースは、もっと見つけやすく、信頼できるものにする余地があります。WMFはこれらのツールに対してもっと適切に対応し、機能改善を短いサイクルで達成するべきです。最近の傾向として AI 支援によるコンテンツ生成とユーザー行動の変化を考慮するなら、大幅な変化に適応する基礎づくりも探っていき（ウィキ関数など）、コンテンツ作成と再利用における大規模な成長を支援できるようにします。コンテンツ格差を特定するメカニズムは、もっと見つけやすく簡単に対策できる必要があります。百科事典の内容の伸展は、姉妹プロジェクトやウィキペディア図書館を含むプロジェクト類やキャンペーン関連の内容などを含めて、投稿ワークフローとの統合をもっと適切にできるはずです。これと同時に、手順の信頼性を引き続き確保するには、伸展に用いる手法は百科事典の掲載内容についてウィキメディアのプロジェクト群全体で認識される基本理念に忠実であることと、増大する脅威に対するガードレールを備える必要があります。観衆：編集者、翻訳者	Runa Bhattacharjee
WE3 議論	消費者の体験（閲読とメディア＝Reading & Media）	ウィキペディアにやってくる新世代の消費者にとって、百科事典のコンテンツを発見したり関与し、長く続くつながりを築きたくなる目的地となるようにします。	目標：既存と新世代の消費者と寄付者を保持。私たちのコンテンツの見つけやすさを高めて操作しやすくし、既存の消費者および新世代とのつながりを強化。私たちの経験と既存のコンテンツに適応するようにプラットフォーム間で連携させ、新世代の消費者や寄付者が行為者として、また、これらの人々を対象とした百科事典のコンテンツ探索やキュレーションができるようにします。	Olga Vasileva
WE4 議論	信頼安全	さまざまな種類の大規模かつ直接的な嫌がらせ行為に対抗するインフラとツール類や手順を改善して十分な設備を整え、コミュニティやプラットフォームおよびサービス提供システムを保護しつつ、進化する規制環境への説明責任（コンプライアンス）を保ちます。	嫌がらせ行為と戦う能力のいくつかの側面は向上させなければなりません。IP に基づいた不正行為の軽減は効果が薄れてきたことから、効率の改善が必要な管理ツールが複数あり、大規模な不正行為と戦う統一戦略を立てて、具体的にはさまざまな予兆や軽減の仕組み（キャプチャ、ブロックなど）を連動させて用いる必要があります。私たちは今年いっぱいをかけ、この分野最大の問題に取り組みを始めます。さらに嫌がらせ行為防止へのこの投資とバランスを取るには、コミュニティの健康状態を理解し改善するためにも投資が必要であり、それらの側面のいくつかはさまざまな規制要件に分散しています。	Suman Cherukuwada
WE5 議論	知識のプラットフォーム I（プラットフォームの進化）	メディアウィキのプラットフォームとそのインターフェイスを進化させ、ウィキペディアの中核となるニーズをより適切に満たします。	メディアウィキ（MediaWiki）を構築した目的は、オープンな多言語コンテンツを大規模に作成し管理し、保存や検出、利用ができるようにするためでした。知識プラットフォーム（Knowledge Platform）が2年目に入る今期は、システムの精査とプラットフォームの改善に取り組み、今後10年にわたってウィキメディアのプロジェクト群の中核となるニーズを効果的にサポートすることを目指し、まずはウィキペディアから始めます。これには、知識生成プラットフォームを定義する作業を続けること、プラットフォームの持続可能性を強化すること、拡張機能／フック類のシステムに注力して機能開発を明確にして合理化すること、人々がメディアウィキに貢献できるように知識の共有に投資を継続することが含まれます。	Birgit Müller
WE6 議論	知識のプラットフォーム II（開発者対象のサービス）	技術系の職員とボランティア開発者には、ウィキメディアのプロジェクト群を効率よくサポートする上で特定のツール類が必要です。	私たちが立ち上げた、ウィキメディアの製作における開発や試験、展開のワークフローを改善（および拡張）を目指す作業を継続し、ツール開発者向けのサービスを含めるように定義を拡張します。また開発者／エンジニアリングのワークフローや対象ユーザーの分野では、よくある質問に回答する能力を向上させ、関連データにアクセスできるようにして情報に基づいた意思決定を可能にすることも目指しています。この作業には、現行の慣行（またはその欠如）がエコシステムの課題となっているなら、それを検討することも含まれます。	Birgit Müller

信号およびデータサービス（SDS）と目的
目的	目的範囲	目的	目的の内容	主催者
SDS1 議論	洞察の共有	ウィキメディアの使命と運動をどのように支えるか、私たちは、高レベルの指標と洞察に基づいて決定します。	私たちが技術の構築を効率よく効果的にしたり、ボランティア対応、知識へのアクセスを保護し促進する政策を提唱するには、ウィキメディアのエコシステムを理解し、何が成功か調整する必要があります。ここで追跡する共通の指標のセットとは信頼できて理解しやすく、タイムリーに利用できるものを意味します。また同時に調査と洞察を浮上させて、それぞれの測定の背後にどんな理由と方法があるか理解するのに役立足せることも意味します。	Kate Zimmerman
SDS2 議論	実験用プラットフォーム	製品管理者は製品の機能に関して、迅速に簡便に製品の機能の影響を測定し結果に自信が持てます。	製品の機能開発に関して、データに基づいた意思決定を可能にし迅速化するために、製品管理者が実験プラットフォームを使えるようにすると、機能の定義やユーザーの比較対象者を選択し、影響を数値化して確認する場が得られます。立ち上げから分析までの時間短縮が重要であって、これは学びの日程短縮により実験を加速し、すると究極には発明の加速をもたらすからです。手作業による作業や測定ごとに特製の取り組みをすると、スピード化の壁となることがわかりました。理想的なシナリオは、製品管理者が自力で実験の開始から発見まで完了できることであり、その過程でエンジニアやアナリストが手動作業でほとんどまたはまったく介入しないことです。	Tajh Taylor

将来の観衆（FA）と目的
目的	目的範囲	目的	目的の内容	主催者
FA1 議論	仮説をテストする	オンラインで知識がどのように共有され消費されるか、実験に基づく洞察を得て実態の理解を深め、ウィキメディア財団が追求すべき戦略的な投資について勧告し – ゆくゆくは私たちの運動が変化を続けるインターネットで新しい視聴者にサービスを提供できるよう、補佐することになります。	読者や投稿者を引き付け維持しようとするウィキメディア運動ですが、技術もオンライン利用者の行動も変化し続けることから、課題に直面しています（例：情報はソーシャル・メディア系のアプリ経由で取得したい人の増加、短い教育的動画（エデュテインメント）の人気、生成AI の台頭）。こうした課題はまた、情報の作成と配信に新しい方法を使うと、新しい視聴者へのサービス提供という機会にもなります。それでも私たちという運動はさまざまな戦略の全体像をデータに基づいてそれらが何をもたらし何を奪うのか明確に把握していないため、課題の克服や新たな機会を掴もうとするとき、本来なら使えるかもしれない戦略を応用できていません。たとえば……。チャットボットやソーシャルビデオなど、規模の大きな新機能を私たちのプラットフォーム上に持ち込むように投資しますか？ウィキメディアにある知識と道のりを使って人気のあるサードパーティのプラットフォームに貢献してみませんか？他にもありますか？ウィキメディアが複数世代にわたるプロジェクトとなるよう目指し、私たちは – 将来もウィキメディア財団とウィキメディア運動に視聴者を引き付け、維持するため – 仮説の検証により、有望な戦略をよりよく理解し、推奨できるようにします。	Maryana Pinchuk

製品技術支援（PES）と目的
目的	目的範囲	目的	目的の内容	主催者
PES1 議論	業務の効率化	財団の業務をより迅速に、経費節約型に、波及効果を大きくすること。	財団業務をこなす職員は日常的に多くの業務を行って迅速に経費を抑えて処理し効果が出せるよう働いています。この目標が焦点を当てる特定の取り組みは、a）事務処理の迅速化と経費節減または効果をより発揮して大幅な利益をもたらす点と b）公式と非公式の財団慣行を調整し変更する点を両立させるものです。当財団の製品と技術関連の作業の運用効率に関して、この目標に含まれる KR を実施しようとすると、今年、基本的に最も困難かつ最善の改善となります。	Amanda Bittaker

主な成果の下書き

"主な成果"（KR＝Key Results）はそれぞれの決定した目標ごとに出揃いました。このページに既出の目的と対応しています。

各KRが根拠とする「仮説」は以下のとおり、このページで年間をつうじて更新し、教訓が得られるにつれて関連プロジェクトまたは担当チームのウィキページに載せます。

ウィキ体験の主な成果（WE＝Wiki Experiences） [ 趣旨 ]
主な成果の短縮名	主な成果の本文	主な成果の本文	主催者
WE1.1 議論	共通の関心をいだく貢献者同士が互いにつながり、一緒に貢献できるようにワークフローを1件、開発または改善します。	私たちは、コミュニティの空間とウィキ上の交流は、人々を幸せにするものであり、貢献者として生産性を高めると理解しています。コミュニティ空間はさらに、新規参加者対象の研修や指導、貢献の最善手法のモデル化、知識の格差解消に役立ちます。しかしながら、一方ではウィキ上でつながる人々をサポートする既存のリソースやツール、空間はまだ標準以下であり、今日の編集者の大多数がかかえる課題やニーズを満たしていません。他方、キャンペーン担当チームの取り組みから、多くの主催者が導入と実験に熱心でコミュニティ活動に役立つ新ツールには、ワークフローの構造化が求められると示しています。こうした理由から、私たちはウィキ上で寄稿者同士の帰属意識を奨励し促すことに重点を置きたいと考えます。	Ilana Fried
WE1.2 議論	建設的な活性化：介入の広範な展開により、モバイル機器のメイン名前空間で最低1件、建設的な編集を公開した新規参入者の割合を前年比で合計 #% 増やすと判明しました。注：この KR 測定はプラットフォーム単位で実施。	現在のページ全体の編集経験では、建設的に貢献しようとする初心者の皆さんの多くにとって求められる文脈も忍耐も、試行錯誤も、あまりにも多大です。新世代のボランティア支援のため、より小規模で構造化された、タスク固有を強めた編集ワークフローの件数と可用性を増やします。（編集チェックや構造化タスクなど。）注記：ベースライン類の確立は今年度第4四半期末まで待つことになり、KR目標指標の百聞率の確立も、その後の見込み。	Peter Pelberg
WE1.3 議論	モデレーション製品4件のユーザー満足度を X% 向上。	拡張権限を持つウィキメディアのプロジェクト群の編集者は、既存の機能や拡張機能、ツールやスクリプトを幅広く利用して、モデレートのタスクを実行します。この分野のプロジェクトでは今年、新機能の構築に取り組むのではなく、これらツール群の改善に重点を置きたいと考えます。年間を通して多くの製品に触れることを目指し、それぞれに効果的な改善を加えたいところです。そうすると、コンテンツ全体のモデレートの体験向上を実現したいと考えます。この作業の流れでは対象となる可能性のある複数の一般的なモデレーター用ツールのベースラインに、測定値X% を定義します。この KR の優先順位を決定する上で、コミュニティの要望リストが大きく貢献します。 We will define baselines for common moderator tools that we may target with this workstream to determine increase in satisfaction per tool. The Community Wishlist will be a substantial contributor to deciding on the priorities for this KR.	Sam Walton
WE2.1 議論	第2四半期末までに特定のツールや洞察、組織化の方法に関して主催者や寄稿者や団体をサポート、主要なトピック領域 [策定中] で質の高いコンテンツ占有率増加対象の記事数を実験的に X件分とすること。	この KR の目的は既存の知識の格差縮小のために主題の範囲改善とします。コミュニティがプロジェクトのコンテンツの品質向上を目的としたキャンペーンの恩恵を受けるコツは、効果的なツールの組み合わせにあると確立しました。今年は、既存のツール改善と、知識の格差に対処する主要な主題の領域に優先順位を付けるため、新しい方法の実験に重点を置きたいと考えています。カバレッジの増加目標 X% は、高品質なコンテンツ作成の既存のベースラインの確認によって決まります。またコミュニティや機関と連携して取り組む重点テーマ分野は、次の四半期までに決まる見込みです。 Our target 138 articles will be determined by looking at existing baselines of quality content creation.	Purity Waigi & Fiona Romeo
WE2.2 議論	第2四半期末までに、小規模な言語コミュニティの言語オンボーディングに対応する推奨事項2件（社会的と技術的）を展開してテスト、評価を採用してコミュニティのフィードバックを分析する。	現状でウィキペディアには約300の言語版があります。それでも、話者が何百万人もいる言語なのに、専用のウィキペディアも他のウィキも全くない言語がたくさんあるのです。インキュベータを2006年に開設したときは、前提条件として利用者ウィキ編集の事前知識を備えていることにしました（The Incubator）。これは、私たちが目指す理想、すべての人があらゆる知識の総和を無償で共有できるというものの実現を妨げます。ウィキメディアのインキュベータはウィキメディアのプロジェクトとして新しい言語版のウィキの可能性を整理し、作成してテストし、ウィキメディア財団がホストする価値があると証明できる場所です。この問題をさらに悪化させている事実とは、私たちの運動において参加した期間が最短で経験が最も浅い人々たちに、この過程を実行させるという想定です。あれ以来、ウィキメディアのウィキの編集は大幅に改善されたのですが、技術的な制限のせいで、インキュベーターにはこれらの更新が届いていません。現状で、特定のウィがインキュベータを卒業するまでの経過時間は数週間かかり、年ごとに作成される新規ウィキは12件程度しかないという、重大なボトルネックとなっています。既存の研究と資料から、新しい言語導入（オンボーディング）のあらゆる段階に技術的な課題が明らかになり、インキュベータに新しい言語を追加すること、コンテンツの開発と評価の複雑さ、特定の言語がインキュベータを卒業するときにウィキのサイト作成の過程が遅いことなどです。各段階は複雑で手作業で進めるため時間がかかり、改善が必要だと示しています。この問題に対処すると、特定のウィキに新しい言語版をもたらすとき、作成はより迅速かつ簡単になり、知識を共有できる人がより多くなります。さまざまな利害関係者や、既存の調査研究および情報源から、社会面でも技術面でも推奨事項のお勧めが提案され注目に値します。この主な成果では2つの推奨事項に着目、社会および技術の両面でテストし、コミュニティから寄せられるフィードバックの評価を提案します。	Satdeep Gill & Mary Munyoki
WE2.3 議論	第2四半期末までに新機能2件を導入、寄稿者はプロジェクトのガイドラインに準拠したソース素材を追加できるようになり、提携先3-5件から言語と地理の格差に対処する典拠資料の提供を受ける。	質の高い情報源素材へのアクセスを増やし、戦略上のコンテンツの格差を縮小しようと、以下を計画します。学習ネットワークとして、生物多様性ヘリテージ図書館、AfLIA、ウィキソースラブ・手稿と提携（Biodiversity Heritage Library; AfLIA; the Wikisource Loves Manuscripts。）もっとアクセスしやすい再利用指標を介し、コンテンツの提携先取得と保持を支援。寄稿者がコンテンツの信頼を高めるように、プロジェクトのガイドラインに適合する画像や典拠の追加に導き、例えば各自が画像のアップロード／追加の作業中に、潜在的な問題を指摘するなど対策します。	Fiona Romeo & Alexandra Ugolnikova
WE2.4 議論	第2四半期末までに小規模言語版のウィキペディア1件以上でウィキファンクションズ呼び出しを有効にしてスケーラブルな方法を提供し、新しいコンテンツのきっかけにする。（Wikifunctions）	知識の格差を効果的に削減するには、質の高いコンテンツの成長を支えるワークフローを改善、特にコミュニティが小さな言語地域では、計測可能にする必要があります（スケーラブル）。	Amy Tsay
WE3.1 議論	コミュニティ主導で厳選されアクセス可能な閲覧および学習体験2件を代表的なウィキに展開、非ログイン読者として経験を積んだ利用者の保持率は5%増を目指す。	このKRは、私たちのウェブサイトで新世代の読者の定着を高め、新世代の利用者がウィキペディアとのつながりを永続的に築けるように、興味を持つコンテンツをどうすれば読者がもっと簡単に発見したり学ぶ機会を得られるか、探求します。キュレーションを改め個人に引き寄せて、ブラウジングおよび学習体験をコミュニティ主導にするなどの探究と開発が含まれるはずです（例えば関連のあるコンテンツをフィードする、話題のコンテンツのお勧めや提案、コミュニティがキュレーションしたコンテンツを探索できる機会の創出など）。今年度は、はじめにブラウジング体験の一連の実験を開始する予定で、実稼働用にどれを拡張するか、またどのプラットフォームで拡張するか（ウェブかアプリまたはその両方か）を決定します。次に、これらの実験の拡張により運用環境で（読者の）保持率引き上げ効果のテストに焦点を当てます。年末までの目標として、実験を少なくとも2件、代表的なウィキで開始し、これら体験に関与した読者の保持率を正確に測定、5%増に達するかどうか確認。このKRの最適な達成に求められる条件として、ログアウトした利用者対象のA/B テストを実行できるか、読者の維持率を測定できる機器があるか。そのほか勧告事項その他をキュレーションする仕掛けの提示には、新しい API やサービスが必要な場合も見込まれます。	Olga Vasileva
WE3.2 議論	恒例のバナーや依頼メール以外のタッチポイント経由で、プラットフォームごとに寄付者の件数を50％増。	私たちの目標は、既存の寄付者に感謝しながら、収入源を多様にしようというものです。財団が過去に頼りにしてきた方法、特に毎年恒例のバナーによる募金のみに限らず、フィードバックとデータに基づいて寄付の数を増やすことに焦点を当てます。寄付者の経験をより統合し投資すると、バナーによる募金には応じない寄付者やその候補者に別の受け皿を提供するなら、私たち自身の仕事を続け、影響を拡大できると示したいと考えます。当初は指標を50%増しに設定、これはベクター2022の導入でウェブ上の寄付ボタンが見つけにくくなった点と、2023-2024年度のウィキペディア・アプリで実施した先行プロジェクトで寄付者の経験を強化したところ、寄付数が増えた点（寄付50.1%増）に基づきます。この指標の評価はプラットフォームごとに実施し、将来は異なる戦術を展開する必要があるかどうか理解するために役立てようとしており、プラットフォーム単位の傾向、それぞれの観衆の区分が行動の違いを表すかどうかに基づきます。	Jazmin Tanner
WE3.3 議論	By the end of Q2 2024-25, volunteers will start converting legacy graphs to the new graph extension on production Wikipedia articles.	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
WE4.1 議論	第3四半期末までに嫌がらせ行為や有害コンテンツに対する対策を3つ提案、データで裏打ちして、規制環境の進化に適合するものを提供します。	利用者の安全を確実にして幸福を保つことは、オンライン・プラットフォームの基本の責任です。多くの司法管轄国にはオンラインのプラットフォームに関する法律と規制があり、嫌がらせやサイバーいじめその他の有害なコンテンツに対策を講じるよう要求します。これらの問題に対処しない場合、プラットフォームは法的責任を追求され、規制や制裁にさらされると予見できます。現時点でこれらの問題がどれほど大きいか、あるいはその背後にある原因はよくわかっていません。私たちは事例証拠と手動のプロセスに大きく依存しているため、法的リスクばかりか、その他の広範な影響として、問題の過小評価、被害の拡大、風評被害、ユーザーの信頼の低下にもさらされています。嫌がらせと有害なコンテンツの発生率を測定するという強い文化を構築し、積極的に対策を実施する必要があります。	Madalina Ana
WE4.2 議論	第3四半期末までに、不正行為対策の手順用に信号を2件以上開発、悪意の利用者に関して行動の精度を向上させる。	ウィキ類は荒らしやスパム、悪用をブロックするメカニズムとして、IPアドレスのブロックに大きく依存しています。ところが個々の攻撃者を安定して識別する要素として、IP アドレスはますます役に立たなくなり、特定のIP アドレスをブロックしたばかりに、悪意のある攻撃者とたまたま同じ IP アドレスを共有した善意の利用者にまで、予期せぬ悪影響が生じる結果を招きかねません。IP アドレスの安定性の低下に IP ブロック依存度の高さが重なって、善意の利用者の巻き添え被害が高率になり、悪意のある攻撃者をターゲットにする精度と効果が低下しました。逆の状況を実現したいものです。つまり、巻き添え被害のレベルが低下し、攻撃者を対象とした緩和の精度も向上させたい。このKRで提言したいのは、役務者の不正行為対策をもっと支援したり、基本単位を提供するには、既存^※1や新しいツールで利用と再利用することで個人とそのアクションを確実に関連付け（ソックパペットの軽減）、悪意のある行為者をより正確に補足できるように既存の信号^※2を組み合わせることです。（※:12＝チェックユーザや特別:Blockほか。2＝IP アドレスやアカウント履歴や申請の属性。）	Kosta Harlan
WE4.3 議論	対策の適用とトラフィック量の維持にかかる時間をシミュレーションで測定し、大規模な分散攻撃の有効性を50%減。	インターネットの状況が進化して、大規模なボットネットの台頭、より頻繁な攻撃などにより、大規模な不正行為を制限する従来の方法は時代遅れになりました。左記の攻撃により、インフラにリクエストが殺到してサイトが利用できなくなったり、大規模な破壊行為に対抗するコミュニティの能力が圧倒されたりする可能性があります。すると高次の権限を持つ編集者や技術コミュニティにも本来はないはずの負担がかかります。このような攻撃に対して早急に改善する必要がある能力とは、それらを自動的に検出し耐え切り、軽減または停止するものです。改善は、実際に攻撃されたときの頻度や強度の計測だけに頼ることは不可能で、なぜなら、それでは外部の行動に依存することになり、私たちの進歩を明確に定量的に把握できなくなります。攻撃を受けていない状態で新しい対策のテストや、改善点の客観的な報告を実現するは、性質や複雑さや期間が異なる複数の攻撃を予測して、私たちのインフラに対して無害な状態で走らせ、それを四半期ごとに実施します。	Giuseppe Lavagetto
WE4.4 議論	一時的なアカウントは全てのウィキ・プロジェクトで使えるようにすること。	一時的なアカウントは IP の公開をめぐるさまざまな規制要件に準拠する解決策であり、私たちのプラットフォーム上のさまざまなサーフェスに適用されます。この作業には多くの製品やデータ・パイプライン、機能ツールおよびさまざまなボランティアのワークフローの更新が含まれ、追加のアカウント種別の存在に対処します。	Madalina Ana
WE5.1 議論	第3四半期末までに、プラットフォームの継続可能性を増加させる介入を5件以上完成させる。	メディアウィキのプラットフォームが持続可能かどうかは常に基本となる取り組みであり、開発者の満足度を向上させて広げるか低下を回避し、技術コミュニティを成長させる能力向上ための要点です。測定が難しく、技術および社会の要因に左右されがちです。それでも私たちには暗黙の知識があり、持続可能性を目指すなら特定の分野で戦略的な改善が必要だと気づいているはずです。そこで介入を計画すると、プラットフォームの持続可能性と保守性の向上、プラットフォームの劣化回避に役立つ可能性があります。私たちはこの取り組みの影響を第4四半期に評価し、持続可能性の今後の目標に何を推奨すべきか検討する予定であり、対象は例えば次の項目です。ウィキメディアの中核となる複雑なコードのドメインについて、その仕組みを知っている人がほんの一握りしかいないものを簡素化。コードベースの品質を知らせるためコード分析ツールの使用を増やすこと。パッケージ化やリリースなどのプロセスを合理化。	Mateus Santos
WE5.2 議論	1件以上の介入を第2四半期末までに識別を終え、第4四半期末までに完成を目指し、メディアウィキのエコシステムにおけるプログラミング用インターフェースを進化させ、より簡略で持続可能な独立した機能開発を強化します。	KR 5.2 の主な目標は、メディアウィキのコアなプラットフォームとその拡張機能や外装その他の部分で相互作用を改善し、明確にすることです。目的はメディアウィキのアーキテクチャの機能改善であり、実用的なモジュール性と保守性を可能にする理由は、拡張機能の開発が容易になることと、メディアウィキ製品のより広範な理想の要件を強化することにあります。この作業は、コア内や拡張機能またはそれらを結ぶインターフェイス内で、存在すべき（または存在すべきでない）ものは何かを知らせることも目指します。一年は次の2つのフェーズに分かれ、まず研究および実験段階に5ヵ月を使い、次にどんな特定の介入を実施するか、第2フェーズに引き継ぎます。	Jonathan Tweed
WE5.3 議論	第2四半期末までに、データ収集イニシアチブ1件とパフォーマンス改善実験1件を完了、メディアウィキの能力を活用し^※フォローアップ製品とプラットフォームの介入に受け渡す。（※＝ページは構造化された断片の構造であるとモデル化する。）	ここで言う主な目標とは、百科事典コンテンツの現在および将来のニーズに対応できるように、開発者と製品マネージャーにメディアウィキの新プラットフォームの機能活用を任せて、現状では実装が困難な新製品の提供と、プラットフォームのパフォーマンスと回復力を向上させることです。具体的にはその特定のプラットフォームのレベルで、メディアウィキの処理モデルにおいてページの扱い方を移し、モノリシック単位ではなく構造化されたコンテンツ単位の構成にしたいと考えています。これに向けた暗黙の動きとは、Parsoid ベースの読み取りビュー、ウィキデータとの統合、ウィキファンクション（Wikifunctions）のウィキへの統合のすべてです。この KR の一環として、より意図的に実験を行ってデータを収集し将来の介入に情報を提供したい、これらの新機能に基づいてインフラと製品への意図した影響を確実に達成したいと考えます。	Subramanya Sastry
WE5.4 議論	第2四半期末までに 1.43 LTS リリースを実施、これは PHP 更新と連動する新規の MW リリース・プロセスを経由します。	MediaWiki ソフトウェアのプラットフォームはその安全と持続可能性を保つため、次の PHP バージョンへの定期的な更新に依存しており、これこそインフラの最新化にとって重要で、私たちのプロセスにおける問題点です。私たちは同時に、MediaWiki ソフトウェアの新バージョンを定期的にリリースして、それには、たとえばソフトウェアのメッセージを翻訳する translatewiki.net などのプラットフォームが依存しており、ウィキメディアのプロジェクト群その他の多くのオープンソースのプロジェクト群で使用されています。このは、るプラットフォームです。 MediaWiki リリース・プロセスを改善する機会は次のリリースの前にあり（次回は長期サポート・バージョン＝ LTS となる予定）、例えば MediaWiki 製品戦略に沿って技術文書や PHP 更新の同期などを行います。この作業は MediaWiki プラットフォームの持続可能性に対する戦略的な投資の一環であり (見出しの 5.1 も参照)、その目標は開発者の体験とインフラ管理の改善にあります。	Mateus Santos
WE6.1 議論	質問5つを解決、効率性と情報に基づいた意思決定を可能にして、第4四半期末までに開発者とエンジニアリングのワークフローとサービスの関連データにアクセスできるようにする。	質問として「ウィキメディアの制作にどのリポジトリを展開するか」と問うなら、よくある答えは「複雑だ」です。この KRでは、エンジニアリングの生産性と経験の分野において「永遠の新人」の部分を探求します - 繰り返し問われ、簡単なように見えても回答は難しい質問、答えは出せるがデータにアクセスできない質問、対象の専門家しかカスタムのクエリができないなど、プロセスの格差その他の理由で答えがなかなか得られない質問。「解決」の意味をそれぞれの質問ごとに以下を含めて定義します。ある人にとっては、単に既存の正確なデータを入手できればよいだけのことかもしれません。他の質問では、研究と技術的な時間がないと、それらに答えられないかもしれません。この作業の全体的な目的はエンジニアリングと開発者のワークフローとサービスの改善を可能にすることで、開発者の経験の重要な側面に関して洞察するときに、時間と代替の解決法と注入する努力を削減します。	[TBD]
WE6.2 議論	第4四半期末までに既存の特定のプロジェクト強化と実験を2件以上実施し、維持可能な標的型環境の提供により、安全で半連続的な配信へ向かいます。	運用環境の利用者が影響を受ける以前にバグを検出しようと、開発者も利用者もウィキメディアのベータクラスタ（ベータ版）に頼っています。時間の経過とともにベータ版の使用が拡大し、競合が発生してしまいました—用途が多様すぎて、単一の環境に収まりきらない状態。私たちは既存の代替環境1件を強化して実験を実行するつもりで、目的は、テストが必要な優先度の高い単一のニーズについて現状ではベータ版で対処しているところを、保守可能な代替環境と置き換えて各ユースケースのニーズによりよく応えることにあります。	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 の使いやすさ向上、貢献をはばむ障壁を低くして、コミュニティの実践を改善し、確立された方針の順守を促進することです。このため技術および社会の側面に着目した持続可能性を評価する数値化システムを、第2四半期末までに Toolforge プラットフォームに導入の予定です。このシステムを目安に使い、重要な技術要素1件を 50% 向上させるよう目指します。	Slavina Stefanova

信号とデータサービス（SDS）の草案版主な成果（Signals & Data Services） [ 趣旨 ]
主な成果の短縮名	主な成果の本文	主な成果の本文	主催者
SDS1.1 議論	第3四半期末までに、プログラム2件もしくはKR主導の取り組みでは各チームの作業がコア指標1件以上に及ぼす直接の影響を評価し終えた。	財団の目標に向けた進捗状況を評価するには、私たちの中心的な組織指標がその主要なツールとして機能します。プログラムのリソース割り当て、主な成果（KR）指向のワークストリーム設定の際に、これら高次の指標は、年次計画に定義した財団の包括的な目標と、これら投資をどう結びつけるか、導く必要があります。主な成果をめぐるこの研究により、あらかじめ見込んだ介入すべての影響を高次または中核的な指標に定量的に結び付ける能力において、財団全体がまだまだ初歩段階にあると認められます。このKRの最終目標の追求では、目的は私たちの取り組みと高次の指標を論理および理論の両面でつなぎ共有するプロセス開発としています。実際の手順ではプロジェクトのレベルで得る取り組みの成果を、財団レベルのコア指標にどのようにリンクさせ、どんな波及効果がありそうか理解すること、財団各所の取り組み単位で主催者（オーナー）と提携することを意味します。現在、財団は目標の初期段階にあり、プログラムまたは製品主導の取り組みを実行し、それらの活動の影響をコア財団レベルの指標に帰するよう努力しています。この目標の追求には、この KR は次の項目の実現を目的とします。すなわち特定する候補プログラムまたは製品主導型イニシアチブは2件以上、コア指標への影響を評価する評価戦略を設計し、この評価戦略を実行することです。始める取り組みを2件と設定すると実際に分析をする際の評価の問題点を早く把握でき、すると自分たちのどの作業がコア指標にどのような影響を及ぼしたのか、目に見える形として理解できます。この KR からの学びが情報提供する戦略はより範囲が広く、財団がこの測定戦略を適用する取り組みの範囲を広げるよう、そして量的にも増やすように呼びかけます。	Omari Sefu
SDS1.2 議論	2026年度の年間計画に推奨事項や情報を提供したりするため、2024年12月までに2つの戦略的なオープンリサーチの質問に回答。	ウィキメディアのエコ・システムには研究上の未解決の質問がまだたくさんあり、WMF または提携団体にとってその質問のいくつかに答えを求めることは戦略となります。これらの質問に対する答えは、将来の製品や技術の開発に役立つ可能性があり、また政策分野の意思決定や権利擁護を支えることにも結びつきます。これらの質問の一部は、純粋に調査研究または研究工学の専門知識の活用で答えが出せますが、信頼できる洞察に達するウィキメディア・プロジェクトの社会技術的な性質を考慮すると、多くの場合、データ収集や文脈構築、利用者の相互作用、チーム間の協調による実験などの慎重な設計が必要になります。私たちはこの KR を通じてリソースの一部を優先して割り振り、それらの質問に少なくとも1つ答えようと目指しています。この KR の作業には、戦略に関する未解決の質問一覧に優先順位を付けること、実験作業の末、そのうちの X 個（現時点の目標値は2個）の回答探しが含まれます。ここで取り組む質問の理想としては、ここで見つけた回答が他の複数のチームやグループにとっても鍵になり、それぞれが抱える製品や技術または方針の作業を（情報を得て、よりよく？）行うという波及効果を期待できるものです。この KR の作業で、以下の KR を補完したいと意図しています。 PES1.3. 焦点は既存の製品に基づき、プラットフォーム上の製品もしくは機能の発想の実験。 FA1.1. 焦点は、将来の観衆に関して、人工知能／機械学習（AI/ML）を使っ実験すること。	Leila Zia
SDS1.3 議論	3つの中心的な主要指標に関して、データの利害関係者がデータの理解と追跡に要する平均所要時間を最低でも50%減らすこと	データ・ガバナンス標準の必須事項。データセットの出どころを遡って求めたり変換することは困難であり、異なるリポジトリやシステムの理解が欠かせません。私たちのシステムにおいて、データの流れをもっと理解しやすくすることが重要で、そうするとデータの利害関係者はもっと自立自助により作業ができるようになります。この作業が役立つ作業手順とは、データの変換と利用の目的が分析、機能、API、データ品質のジョブである場合です。指標の文書化については、フォローアップ用の KR を実施する予定。	Luke Bowmaker
SDS2.1 議論	第2四半期末までに支援対象とする製品チーム1ヵ所について、基本的なA/Bテストを用いた特定の機能もしくは製品の評価を行い、利用者相互作用のデータ所要時間は目標50%減。	共有ツールの採用は、製品チームがデータ基準の意思決定をしたり、効率性と生産性を高めて製品をめぐる戦略と革新をもたらすと考えます。ログイン利用者向けの UX および技術システムを確立すると、SDS 2.3 の実現に向けた長期目標に向かって前進することができ、つまりその作業と並行して、ログアウト利用者対象の A/B テストを支援できます。これを採用したチームごとに、利用者の相互作用のデータ取得時間をベースラインとして、50％短縮を目指します。あわせて製品部門全チームを見回し、より完全な文脈を想定して、これらの利点をどのように文脈化できるか検討します。採用したチームから集めるフィードバックならびにSDS 2.2.の成果に基づき、体験の改善と向上する能力の特定と優先順位の決定について学びがあると期待します。	Virginia Poundstone
SDS2.2 議論	第2四半期末には、実験分析（A/Bテスト）の基本的な指標3件が得られ、2024-25事業年度のKR類に関して、製品および／または機能の仮説実証に対応できるようにする。	プロダクト・マネージャー（PM）（またはデザイナー）が立てた仮説で、製品／機能がユーザーまたは組織の問題／ニーズに対処するとした場合、その仮説をテストすると指標に対するアイデアの潜在的な影響を実験により知ることができます。実験の結果を受け取ったPMは、それを次に取るべきアクションの決定に役に立てます（この考えを放棄して別の仮説を試す、開発ライフサイクルの早い段階で実行した実験なら開発を続行、あるいはまた製品／機能をより多くのユーザーにリリースする）。PMは立場上、自信を持ってそのような決定を下す必要があり、それは信頼し理解する証拠の裏付けを求められます。製品チームは現状、これに関して高いハードルを抱えており、プロジェクト固有のカスタム指標を用いて仮説を策定しているため、専任のアナリストに依頼して仮説の定義と測定、分析とレポートをしてもらう必要があります。テスト可能な製品／機能の仮説の声明を定式化するなら一連の必須指標に切り替えるわけで、次のようになります。その仮説の検証に用いるなら、より簡便かつ迅速に実験の設計や展開、分析ができる。実験から得た結果や学びを、意思決定者その他の対象者に容易に伝達できる（前者はPM、後者は上級リーダーその他、組織内の個人やコミュニティなど）。広く理解され一貫して使われる一連の指標 – かつ業界標準の指標から情報を得て影響を受けるもの – は重要であり、同時に組織のデータリテラシー向上、評価と実験学習の文化を促すと考えられる。（data literacy。）重要な指標として着目するのは2種類で、（1）製品／機能の成功と影響の最適な測定と評価に必要な2つの「Wiki Experiences KRs」 – 略号WE3.1 と略号WE1.2 – 、(2) 業界標準指標を反映または描き出しウェブ分析で採用するもの。	Mikhail Popov
SDS2.3 議論	私たちの CDN に対応する一意のエージェントを追求する仕組みを実装して、匿名の利用者を対象とした製品機能を A/B テストにかけられるようにします。	そのような追跡の仕組みがないままだと、匿名の読者を対象とした A/B テストの実施は不合理です。これは基本的に新しい技術的機能を作成するマイルストーンを基準とする成果であり、それを下地として他の人が測定可能なものを構築できるものです。主要な優先事例とは、匿名の読者を対象とした機能の A/B テストですが、他の重要な将来の機能もこの作業によって可能になり、すなわち後に WE4.x で（リクエストのリスク評価と大規模攻撃の緩和など）後続の仮説を作成するものであり、リソースと優先順位が許す限り、一意のデバイス数に関する指数／調査が成立します。	Brandon Black

将来の観衆の主な成果、草案版（FA＝Future Audiences） [ 趣旨 ]
主な成果の短縮名	主な成果の本文	主な成果の本文	主催者
FA1.1 議論	将来の観衆について実験的な洞察と推奨事項の成果は、第3四半期終了時に得るものとし、FA担当以外のチームが所有する目標または主な成果を翌年の年次計画の草案に1つ以上取り入れます。	2020年以降、財団は外部トレンドを追跡し、将来世代の知識消費者や知識貢献者に奉仕する私たちの能力、今後数世代にわたって無償の知識運動として繁栄を続けることに影響を与える可能性のある要素を見守ってきました。ここで言う「将来世代の観衆」とは小規模なR&Dチームを指し、担当は次のとおり【研究開発】。時間設定をした実験を迅速に実施（予算年次単位で実験は最低3件）、これらの傾向に対処する方法を探る WMFが追求する本格運用の新規投資 – すなわち新製品もしくは新規プログラムであり専用のチーム（複数可）を配置するべきもの – の提言は、恒例の年次計画の策定期間に実験から得た洞察に基づいて実施します。つまりチーム全体で取り組む必要がある新製品やプログラムについての推奨事項を作成します。この主な成果達成には、所有するチームがFA担当以外の目標または主な成果であり、FAの推奨事項に裏打ちされたものが少なくとも1件、次の会計年度の年次計画の草案に載っていることが条件となります。	Maryana Pinchuk

製品と技術支援の主な成果の草案（PES＝Product and Engineering Support） [ 趣旨 ]
主な成果の短縮名	主な成果の本文	主な成果の本文	主催者
PES1.1 議論	評価の文化：四半期ごとの調査でP+T職員の感情スコアを徐々に改善し、その範囲は配信、アライメント、方向性、チームの健全性とする。	評価の文化とは、製品開発の文化であり、より短いサイクルで実施する反復と学習、適応に基づきます。私たちの組織が年間目標を設定できると示してはいても、これらの目標達成に向けた私たちの行動は学習につれて変わっていき、年間を通じて適応するものです。評価の文化構築には要素が2つあり、それはプロセスと行動です。この KR は後者に焦点を当てます。行動の変化は評価の文化を成長させる要因であり、強化もできます。これは、より反復的な製品開発へと移行するため、個人の習慣や慣行（ルーチン）を変えることを含みます。この KR は、個人が自己申告する自分の行動の変化に基づき、その果てに職員の感情に変化があったなら、その変化を測定します。	Amy Tsay
PES1.2 議論	第2四半期末までに、新しい要望リストを運動のアイデアや要求を財団のP + T活動によりよく結びつけます（製品と技術）。要望リストのバックログ項目は2024-25年次の主な成果（KR）を介して対処、小さな要望10件を完了した財団は、ボランティアと連携して2025-26年度の機会の領域を3件以上、特定する。	コミュニティ要望一覧は、ウィキメディア運動のごく狭い部分を表しています（Community Wishlist）。参加者はおよそ1千名、そのほとんどが寄稿者または管理者です。 Phabricator 経由で機能のリクエストやバグ報告を書いて、要望一覧を回避することがしばしばありますが、財団やコミュニティが発するリクエストの識別は困難です。参加者にとって要望一覧とは、費用対効果を考えると時間の投資をしても見返りは最小限です。要望一覧とは、影響力のあるバグや機能改善への注意喚起、より広範で戦略的な機会の必要性を知らせる唯一の手段だと感じるため、参加者は今でも要望一覧に関与しつづけています。要望の書き方が問題提起ではなく解決策である場合が散見されます。机上では一見、懸命な対策に思える解決策ですが、必ずしも技術的には複雑かどうか、あるいはウィキメディア運動の戦略に及ぼす影響まで考慮してあるわけではありません。場合によっては、要望の範囲や広さがコミュニティ技術部門あるいは単一のチームの担当範囲や能力を超越してしまい、不満が長引いたり、コメント募集（RFC）、はたまた要望一覧そのものの廃止論にまで発展してしまいます。コミュニティ参加者側は、プロジェクトに関するアイデア出しに要望一覧を使いたがるものの、財団のチーム側では優先順位付けの時点で、要望一覧その他の受け入れ手順を比較検討したがる傾向があり、その背景には、要望の流れは年次計画の立案過程にとってタイミングが良くない点、ロードマップおよび／または OKR に組み込みにくい点があります。「将来の要望一覧」とはコミュニティと財団との架け橋になるものとして、コミュニティからは構造化した要望を差し出してもらい、私たちの側はそれに応じた行動を起こせるし、ボランティアの側にとって嬉しい事態となります（Future Wishlist）。ログインしたボランティアの皆さんを対象に、365日いつでも要望を受け取る新規プロセスを作成中です。要望とはバグの通報や詳細の提示、改善してほしいことの申し入れ、あるいはまた新機能に関するアイデア出しを呼び寄せるものです。要望には誰でもコメントを書けるし、ワークショップの主催者になったり、サポートを引き受けて優先順位付けに影響を与えたりできます。財団は要望を「大きすぎる」または「小さすぎる」などとは分類しません。さらに大きな問題領域にテーマ別にマッピングできる要望は、年次計画やチームのロードマップに影響を与え、戦略的な方向性と機会を提供すると考えられます。要望を運動に向けて見える化するには、プロジェクトや製品および／または問題領域、要望の種類ごとに分類したダッシュボードに表示します。当財団は要望にタイムリーに対応し、コミュニティと連携して要望の分類と優先順位付けにあたります。私たちはウィキメディアンと協力して、2025-26年度の財団年次計画に組み込むべき改善分野3件を特定し優先順位を付け、そこから影響力のある願望の採用率と実現率が向上すると見込まれます。私たちは、ボランティア開発者のコミュニティと財団チーム双方のため、広範囲にわたる要望にフラグを立て、チームと開発者の関与を深めたり、そこから満了する要望がますます増え、コミュニティの満足につながります。より多くの要望に応えると、投稿者の幸福度や役立っているという感覚、定着率が上がり、質が高めの編集やコンテンツを生み出し、読者がさらに増えるはずです。	Jack Wheeler
PES1.3 議論	第1四半期と第2四半期時点の消費者とボランティアの聴衆にとって知識の目的地となるには、ウィキペディアをどのように成長させればよいのか、既存の探索型の製品および／または機能からデータや洞察を提供する2つを選び、実験して完了します。ウィキ体験バケットでは第3四半期末までに、将来の OKR 作業に採用できるであろう学習と推奨事項をまとめあげ、共有します。	この取り組みは「将来の観衆」の目標に相当するものでありながら、重点は、もっと多くのプラットフォーム上の製品アイデアをより迅速にテストしたり、既存の視聴者（ウィキペディアの消費者と寄稿者）の関与を増やし深める機会を明白にすることに置いています。これらはエネルギーの供給と増殖させるものとして PES1 に組み込まれ、もっと有望な機能に焦点を当て - 主に対する従のプロジェクトの実験やハッキングに個人やチームが「すでに」費やした時間を活用する形になります。この KR は、これら副次のプロジェクトの停滞（限られたリソースを有効に活用していない）ではなく、これらアイデアの一部を実証済みの実験により規模がさらに大きな APP 設定に取り込めそうな道筋を提供します。これは翻って、職員が勤務時間をさらに効率的に使い、創造性と生産性、やる気の高揚が期待できます。こうした小規模で短期のプロジェクト群をより多く実施に導くと、ウィキペディアを変革する可能性のあるアイデアの学習や試行を現在の視聴者のニーズや期待の変化にもっと適合させる「賭け」も広がり多様化します。これは私たちの作業をもっと効果的かつ迅速に進めるため、財団にとっては、より短期に目標に向けて正しく調整できる一助になります。	Rita Ho
PES1.4 議論	手順を理解する：SLOの設定、監視、決定。SLO類のリリース時には、何か新しい点を選んで定義する。特定のSLOの定義は適切なチームと協力する（複数可、通常は製品、開発、SREのいずれかのチーム）。将来のリリースに関するガイドラインを作ってSLOを備えるものとその設定方法を書き、繰り返し見直す。	KRの将来：プロセスと初歩的なツールを設けて、新しいリリースの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

Hypotheses

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.

Q1

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.	phab:T347298 phab:T349641
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.
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.	[1]
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.	[2]
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 Meta Page
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 consultation 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.	mw: New Engagement Experiments#PES1.3.1_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.	mw: New Engagement Experiments#PES_1.3.2:_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.	mw: New Engagement Experiments#PES_1.3.3:_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.

Q2

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.
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.	https://meta.wikimedia.org/wiki/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.	mw:/wiki/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 Learn more.
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 consultation 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

それぞれのバケットの説明

ウィキにおける体験

Diversity (40786) – The Noun Project

このバケットの目的は無償の知識を世界中に配布するため、ウィキ体験の提供と改善、革新を効率化することです。このバケットは運動戦略の勧告事項その2（利用者体験の向上）ならびにその3（安全性と包括性の提供）に沿っています。私たちの観衆とは私たちのウェブサイト群に寄稿するすべての人々にとどまらず、閲覧者その他、無償の知識の消費者も含まれます。私たちがサポートするのは世界トップ10 のグローバルなウェブサイトであり、その他の無償だが重要な文化のリソースもその対象です。システムとしてこれらには、世界最大手のIT企業と同等にパフォーマンスと稼働時間に要件があります。具体的にはウィキ群の利用者インターフェイス、翻訳、開発者 API（そしてさらにあれこれ）、加えてそれらを支援するアプリケーションとインフラを提供しており、これらはいずれも世界規模の堅牢なプラットフォームを形成し、そこでボランティアの皆さんが協働して無償の知識を生み出しているのです。このバケットの目標が高めるものとはコア技術と機能であり、かつまたプロジェクト群に参加するボランティア編集者と調停者の皆さんの経験は継続して向上させ、ウィキ体験を改善または強化しようと取り組むすべての技術貢献者の体験をも高めると、やがて無償の知識を求める世界中の閲覧者と消費者に確実に素晴らしい経験をしてもらうことになります。これらを実現する私たちは、製品や技術の取り組み、さらには調査研究やマーケティングを切り口にしていきます。このバケットに入れる目標は最大で5つあると予想しています。

知識の構築を担うのは人！人であるからこそ、私たちの年次計画はコンテンツにとどまらず、コンテンツに貢献する人々やそれにアクセスして読む人々にも焦点を当てるものになります。

私たちが目指すものは、既存の戦略に基づいて運用計画を作成することであり、中心に投稿者、消費者およびコンテンツの「勢車」（はずみぐるま）に関する仮説を据えます（「flywheel」）。私が追求したい主な転換とは、このコンテンツの部分に重点を据えて、将来のコミュニティの健康指標を特定するという目的のもと、現在、仲裁者や関係者の皆さんが私たちに何を求めているのか探求することです。

信号およびデータサービス

Arrythmia noun 246518

運動戦略の勧告事項として意思決定の公平性（勧告事項の4）（※1）、利用者体験の向上（勧告事項の2）（※2）、評価し繰り返し適用する（勧告事項の10）（※3）がありますが、これらを達成しようとするウィキメディア運動全域の意思決定者には戦略的な意思決定をより適切に行う上でデータやモデル、洞察やツールが欠かせないし、それらには信頼できて関連性がありタイムリーにアクセスできるべきで、意思決定者自身やコミュニティの（実現したものと潜在的なものの両方の）作業の影響評価に役立つ必要があります。（※：1＝Ensuring Equity in Decision Making。2＝Improving User Experience。3＝Evaluating, Iterating and Adapting。）

信号とデータ・サービスのバケットでは主な対象者4区分を特定しました。すなわちウィキメディア財団の職員、ウィキメディア提携団体と利用者グループ、コンテンツを再利用する開発者、ウィキメディアの研究者であり、これら観衆のデータと洞察のニーズに優先順位を付けて対応します。私たちの仕事はさまざまな活動に及びます。格差の定義、指標の開発、指標の計算処理のパイプライン構築を手がけ、データと信号の探索体験と経路の開発などにより、意思決定者を補佐して当該のデータと洞察のやり取りをより効果よくかつ楽しくできるようにします。

将来の観衆とは

このバケットは無償の知識のエコシステムの不可欠なインフラとして世界中のすべての人に真の意味で響くこと、既存の消費者や投稿者という観衆を超えて拡大する戦略の模索を目指しています。このバケットは運動戦略の勧告事項その9（無料の知識の革新）と一致します。私たちは記事を載せたウェブサイトという従来のままのサービスを提供しているのに、人々の情報消費はそれとは異なる体験や形式で実施され – 音声アシスタントを用いたり、動画鑑賞に時間を費やしたり AI と連携させるなどなど、その傾向はますます強まっています。このバケットで仮説を立ててテストしたいのは、無料の知識のエコシステムが迎えるであろういくつかの長期の将来像と、さらにどの場合も私たちが不可欠なインフラであり続ける方法です。私たちはこれを製品や技術の取り組みにとどまらず、調査研究、パートナー関係、マーケティングの各方面でも実現していきます。有望な将来像を確実に描けたなら、このバケットで得た学びはバケット1と2に波及し複数年の年次計画に拡張され、当財団の製品と技術は、知識を求める将来の人々へのサービス提供を担当する存在としての立ち位置を示してもらえるはずです。無料の知識の未来像にきちんとピントを合わせようとする私たちだからこそ、このバケットでは実験と探索を促す目標を持たなければなりません。

子バケット

Noun project 3067

上記に加え、私たちには他に2つの「子バケット」があります。どちらも重要な機能の領域で構成され、これらは私たちの基本的な業務をサポートするゆえに財団に置く必要があり、そのいくつかはあらゆるソフトウェア組織とも共通しています。これら「子バケット」固有の上位の目標はないものの、他のグループがいだくそのような目標に意見を述べたり、それらに賛同して支えます。具体的には次の各項目です。

インフラの基盤整備。このバケットの対象は一般社会に向けたサイトとサービス類の運用関連のツールとプロセスについて、データセンターや電子計算機およびストレージ用のプラットフォーム、それらを運用するサービスを維持および進化させるチームです。（Infrastructure Foundations。）
製品と技術面のサポート。このバケットでは「大規模な」運用を行い、他のチームにサービスを提供し先方の生産性と運用を向上させるチームが対象です。含まれます。（Product and Engineering Support。）

ウィキメディア財団 年次計画/2024-2025/製品&技術OKR類

趣旨