|
* '''目標'''：由於志願者獲得了引人注目的機會並了解其作出的影響，因此貢獻增加。 {{Blue button|link=Talk:Wikimedia Foundation Annual Plan/2025-2026#Contributor Experiences (WE1)|text=討論}}
** '''背景'''：這一目標將成為實現新貢獻者策略的基礎，該策略有三大支柱：1）為志願者提供一種集中的方式來組織他們的維基活動，2）提供更小和更獨立的任務以創造更大的清晰度並幫助志願者發揮他們的潛力，3）使貢獻更有意義。在財政年度2025/2026 ，我們計劃提供基本的基礎設施，幫助志願者以集中的方式組織他們的維基活動，首先是專門針對經驗豐富的編輯和管理者的干預措施。在接下來的幾年裡，我們將增加對所有貢獻者角色的干預措施並涵蓋更多的問題空間。此外，我們將繼續投資於編輯檢查和結構化任務，為如何以可擴展的方式使用人工智慧奠定基礎，既作為編輯過程中的指導，同時作為向志願者指出引人注目的機會的一種方式。最後，我們將投入資金讓志願者的影響力更加明顯，為他們創造更有意義的體驗。
*** [[File:Font Awesome 5 solid magic.svg|14px|link=|class=skin-invert|alt=願望清單項目]] <span class="mw-translate-fuzzy">'''關鍵結果——維基體驗1.1：根據第二季末的實驗測量，對於累積編輯次數少於 100 次的編輯者，建設性編輯 [i] 增加 X%。'''</span>
***:* <span class="mw-translate-fuzzy">''i.「建設性編輯」= 發佈後 48 小時內未撤銷的編輯''</span>''
**** ''ii. [[phab:T389403#10960480|T389403#10960480]]''
**** 新的志願者努力開始成功編輯——特別是使用行動裝置的使用者，螢幕空間有限，注意力經常分散。
**** 有些人厭倦了建設性貢獻所需的背景、耐心和反覆試驗。其他人尚未遇到令人信服的嘗試機會。
**** 維基體驗1.1 將透過以下方式解決這些問題：
****#* 顯示編輯建議
****#* 提供可操作的編輯指導
****#* 建立更多針對特定任務的編輯工作流程
****<span class="mw-translate-fuzzy">這些工作的核心是需要可擴展的方法來檢測正在進行的編輯和現有內容如何改進。為了增強這種能力，我們將繼續嘗試機器學習，以了解人工智慧如何幫助我們識別維基百科政策問題。</span>
****<span lang="en" dir="ltr" class="mw-content-ltr">Proposed KR scoring methodology: On a per platform basis, we will calculate the proportion of interventions we deployed and evaluated through controlled experiments that met and/or exceeded the constructive edit target we set at the outset of this year. See [[phab:T379285#10782051]] for thinking.</span>
*** [[File:Font Awesome 5 solid magic.svg|14px|link=|class=skin-invert|alt=wishlist item]] '''關鍵結果——維基體驗1.2：到第四季末，維基媒體專案上的協作數量比去年同期成長X%。'''
*****<span lang="en" dir="ltr" class="mw-content-ltr">''Note: as June 30, 2025, WE 1.1 has two controlled experiments planned.''</span>
**** 貢獻者經常努力尋找彼此合作的機會，尤其是圍繞著他們關心的主題和任務。這可能會導致新成員在維基媒體專案上感到孤獨，同時可能會導致經驗豐富的編輯者感到倦怠。此外，協作活動的影響通常不明確，這可能導致較少的人願意加入、組織或支持維基上的協作。
**** 我們希望透過以下方式使協作的價值更加明確：
* [[File:Font Awesome 5 solid magic.svg|14px|link=|class=skin-invert|alt={{Tunit|79|wishlist item}}]] <span class="mw-translate-fuzzy">'''關鍵結果——維基體驗1.2：到第四季末，維基媒體專案上的協作數量比去年同期成長X%。'''</span>
****# 創造新的方式來分享維基媒體專案上協作活動的影響
** 貢獻者經常努力尋找彼此合作的機會，尤其是圍繞著他們關心的主題和任務。這可能會導致新成員在維基媒體專案上感到孤獨，同時可能會導致經驗豐富的編輯者感到倦怠。此外，協作活動的影響通常不明確，這可能導致較少的人願意加入、組織或支持維基上的協作。
****# 開始收集協作活動為整個維基媒體運動帶來影響的資料
** 我們希望透過以下方式使協作的價值更加明確：
****# 建立基本的基礎設施來追蹤協作貢獻，以便我們將來能夠提供創新的新方法來認可和獎勵貢獻
**# 創造新的方式來分享維基媒體專案上協作活動的影響
**** 協作將透過 CampaignEvents 擴充工具中的「活動註冊」功能所建立的新活動來衡量。我們的目標是，到關鍵結果結束時，我們將擁有更多擴充工具的使用者，以及顯示合作影響力的新方案。這將使我們能夠很好地將我們現有的基礎架構與其他表彰和獎勵維基上工作的方式（例如影響模組、感謝等等）連結起來。
**# 開始收集協作活動為整個維基媒體運動帶來影響的資料
**** 願望清單重點領域：[[Special:MyLanguage/Community Wishlist/Focus areas/Connecting Contributors|社群願望清單/重點領域/連結貢獻者]]
**# 建立基本的基礎設施來追蹤協作貢獻，以便我們將來能夠提供創新的新方法來認可和獎勵貢獻
*** [[File:Font Awesome 5 solid magic.svg|14px|link=|class=skin-invert|alt=願望清單項目]] '''關鍵結果——維基體驗1.3：截至第四季度末，新接觸此類管理的人員所採取的管理行動增加了 X%。'''
** 協作將透過 CampaignEvents 擴充工具中的「活動註冊」功能所建立的新活動來衡量。我們的目標是，到關鍵結果結束時，我們將擁有更多擴充工具的使用者，以及顯示合作影響力的新方案。這將使我們能夠很好地將我們現有的基礎架構與其他表彰和獎勵維基上工作的方式（例如影響模組、感謝等等）連結起來。
**** 作為我們為貢獻者創造更大清晰度的工作一部分，我們相信我們可以做得更好，讓志願者看到貢獻的機會。我們將測試這個理論，將特定的版面管理活動 (細節待定) 展現給第一次參與該類型版面管理活動的貢獻者，目標是讓更多貢獻者參與版面管理任務。我們的構想是將此活動放在志願者活動的中心位置，而此關鍵結果將成為我們探索此概念並決定此類介入適當位置的方法。
** 願望清單重點領域：[[Special:MyLanguage/Community Wishlist/Focus areas/Connecting Contributors|社群願望清單/重點領域/連結貢獻者]]
**** 正如關鍵結果中所述，我們的總體目標不僅僅是擴大管理工具的範圍，而是專注於為當前活躍的編輯提供他們可能不熟悉的機會。X％ 是一個佔位符值，用於測量活躍編輯者參與新管理工作流程的頻率基準。
* [[File:Font Awesome 5 solid magic.svg|14px|link=|class=skin-invert|alt={{Tunit|79|wishlist item}}]] <span lang="en" dir="ltr" class="mw-content-ltr">'''Key result WE1.3: By the end of Q3, 10% of contributors who were presented with a homepage aimed towards new moderators visited it two weeks in a row.'''</span>
**** 「管理工具」將遵循[[Research:Develop a working definition for moderation activity and moderators]]中開始的定義，但需要後續工作來縮小定量定義。
** <span lang="en" dir="ltr" class="mw-content-ltr">We believe that we can do a better job of surfacing contribution opportunities to volunteers. Long-term we believe a homepage can be helpful for any editor to organize their work, find new opportunities, and understand their impact. Our goal in FY25/26 is to surface new opportunities to experienced editors to take on moderation tasks they otherwise wouldn't necessarily have been exposed to.</span>
**** 願望清單重點領域：[[Special:MyLanguage/Community Wishlist/Focus areas/Task prioritization|社群願望清單/重點領域/任務優先順序]]
*** <span lang="en" dir="ltr" class="mw-content-ltr">We will test this theory first by understanding how much experienced editors would engage with a homepage, similar to what newcomers have access to.</span>
*** <span lang="en" dir="ltr" class="mw-content-ltr">We will then surface specific moderation activities (details to be determined) to contributors who are new to that type of moderation action, with the goal to help reduce the burden on experienced editors through reduced backlogs (under a new KR).</span>
*** <span lang="en" dir="ltr" class="mw-content-ltr">If successful with the homepage concept, we plan to make this page modular to cater to the needs of communities. These modules could include things such as making it easier for editors to understand their impact.</span>
**<span lang="en" dir="ltr" class="mw-content-ltr">Notes about the methodology:</span>
*** <span lang="en" dir="ltr" class="mw-content-ltr">We will have a hypothesis to define our audience, which will be part of WE1.3.1.</span>
*** <span lang="en" dir="ltr" class="mw-content-ltr">"Moderators" will follow the definition started in [[Research:Develop a working definition for moderation activity and moderators]], though followup work would be needed to narrow down the quantitative definition.</span>
*** <span lang="en" dir="ltr" class="mw-content-ltr">Second week will be defined relative to the timing of each user's first visit. In this case, we'd review all new moderators who visited the homepage during a specified timeframe and then made at least one more repeat visit (7 to 14 days) later.</span>
** 願望清單重點領域：[[Special:MyLanguage/Community Wishlist/Focus areas/Task prioritization|社群願望清單/重點領域/任務優先順序]]
----
*** '''關鍵結果——維基體驗 2.1：到第二季末，試驗並評估 3 項措施，幫助貢獻者改善其維基百科上重要內容的狀態。'''
**** 本關鍵結果將重點放在編輯機制中的內容差距，例如在維基百科上發現圖像、內容翻譯和指導新文章的創建。我們同時將實施和測試社會技術介入措施，以支援小語言社群的內容創作活動。我們將根據每個假設來衡量成功。
*** <span lang="en" dir="ltr" class="mw-content-ltr">'''Key result WE2.2: By end of Q4, build the platform capabilities needed to validate that we can support the Abstract Wikipedia vision at scale. We’ll know we’re successful if we show the system outputs rich, multi-lingual encyclopedic content using Wikidata and natural language generation, is controlled by the Wikimedia community, and remains performant in broad rollouts.'''</span>
*** '''關鍵結果——維基體驗 2.2：在第四季末，建構「維基函數」 (Wikifunctions) 所需的平台功能，以驗證抽象維基百科能夠大規模運作。如果我們能夠證明 「維基函數」 (Wikifunctions) 能夠大量生成自然語言函數、輸出豐富的內容，並在大規模部署中保持高效能，我們就成功了。'''
**** <span lang="en" dir="ltr" class="mw-content-ltr">Now that we can use Wikidata to output basic, plain text content on Wikipedias, the next step is to continue building platform capabilities that can support Abstract Wikipedia at scale. The platform will need to support rich, multilingual content that can be controlled by the community and stay performant at scale. This is a milestone KR as we are going from 0-1.</span>
**** 目前，並非所有維基百科均可以使用可擴充創建內容的工具。這包括已在較大的維基百科上用於創建和維護內容的模板和模組。「維基函數」 (Wikifunctions) 可以讓這些工具可供更多專案使用，而當地社群不必自行創建或維護這些工具。
**** Wikifunctions 的初始功能包括：
***** 轉換功能（在純維基文字中）可提供更全面的內容——否則這些內容會因為所費精力而不存在
***** 一些文章的開頭句子和段落 (純維基文本)，可確保不同維基間的一致性和正確性。這方面的例子包括許多維基站點中關於年份的文章，或意大利文維基百科上的傳記。
***** 我們可以使用維基數據並在資料更新時自動維護內容，例如與城市人口或人的年齡相關資訊。
----
*** '''關鍵結果——維基體驗3.5：在第四季末以前改善捐贈者辨認措施，確保所有登入讀者經同意可藉由捐贈者地位辨別，以提升個人體驗。'''
**** 我們將執行捐贈者辨識策略，確保所有登入讀者經同意可藉由捐贈者地位辨別，以量身打造深入的個人體驗。我們在第四季間將優先從事捐贈者識別工作，以加強支援未來個人化及活化措施。
*** '''關鍵結果——維基體驗3.6：在第四季末之前完成、發佈和傳達維基百科讀者和消費者跨平台體驗策略，並與利害關係人和社群合作制定明確的目標和基準指標，以指導我們到 2030 年的工作。 '''
**** 消費者策略工作將繼續進行，重點是內部和社群建構和溝通該策略，並定義和建立消費者的核心指標及其各自的基線。
----
{{Anchor|WE4}}
<span id="Safety_and_Security_(WE4)"></span>
==== 信任與安全 （維基體驗 4） ====
*** 識別機器學習機會以減輕具有擴展權限的使用者的負擔。
*** 進行實驗來了解我們應該關注的主題，以便產生最大的影響。
* '''關鍵成果——維基體驗4.6：在技術上強制規定，在第四季結束前，只有啟用雙重因素驗證的帳號才能執行 100% 的權限，讓使用者能夠進行安全或隱私敏感的權限操作。'''
** 我們需要加強維基媒體專案用戶帳戶的安全性，尤其是擁有敏感權限的用戶。其中一項重點是要求任何敏感操作只能由啟用雙重認證（2FA）的使用者執行。我們將建構一個更具擴充性的權限執行系統，以繞過審核和手動執行雙重認證的需要，並擴展平台上需要啟用雙重認證的權限範圍。
** 作為其中的一部分，我們將改進我們的驗證和恢復系統，以便我們維基媒體基金會和我們的用戶可以更輕鬆地支持對雙重認證採取更嚴格的態度。我們將在整個平台上擴大雙重認證的普遍可用性，以便每位使用者均能按需要啟用，並確保在授予敏感權限之前啟用。我們同時將專注於降低帳戶復原和支援系統的作業負荷，協助簡化帳戶登入的重設和復原程序。我們進一步打算改善雙重認證實作的可用性，提供使用者更多的選項來保護他們的帳戶，避免意外鎖定。
{{Blue button|link=Talk:Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs##Contributor Experiences (WE1)|text={{MediaWiki:talk/{{PAGELANGUAGE}}}}}}
|-
! 假設簡稱 !! 第一季文字內容 !! 細節與討論
|-
|WE1.1.1
|-
|WE2.2.1
| 如果我們遵循 Parsoid 的推出並將「維基函數」 (Wikifunctions) 整合到大多數維基詞典和一些低流量維基百科中，我們將獲得所需的測試，以便自信地將其推廣到更大的維基媒體專案。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we follow Parsoid’s rollout and integrate Wikifunctions on most Wiktionaries and some low-traffic Wikipedias, we will get the testing we need to confidently roll out to larger wikis.</span>
|
|-
|WE2.2.2
| 如果我們啟用「維基函數」 (Wikifunctions) 來輸出 HTML 表格、樣式和連結，我們將透過顯示動詞變位表的函數來證明其除了簡單轉換之外在維基詞典上生成淨新知識的能力。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we enable Wikifunctions to output HTML tables, styling, and links, we will demonstrate through a Function that displays a conjugation table its capability for generating net new knowledge on Wiktionaries beyond simple conversions.</span>
|
|-
|WE2.2.3
| 如果我們在嵌入式函數呼叫中新增對維基數據實體的支持，我們將啟用 200 多個新函數，這些函數可以使用維基數據實體產生全面的句子，使函數更容易在維基媒體專案中使用。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we add support for Wikidata entities in embedded function calls, we will enable over 200 new functions that can generate comprehensive sentences using Wikidata entities, making functions more easily used on Wikimedia projects.</span>
|
|-
|WE2.2.4
|如果我們制定「抽象維基媒體專案」內容的存放位置及其與維基百科互動的架構計劃，我們將更準備好實施「抽象維基百科」平台，以增加高品質百科全書內容的提供。
|<span lang="en" dir="ltr" class="mw-content-ltr">If we build out an architecture plan for where Abstract Content will reside and how it will interact with Wikipedia, we will be more ready to implement the Abstract Wikipedia platform to increase provision of high-quality encyclopedic content.</span>
|
|-
|WE2.2.5
|如果我們在產品和技術團隊之間定義和交流「抽象維基百科」內容所需引用的產品需求，我們將能夠推動跨維基媒體的工作，提供附加在「抽象維基百科」內容上的出處信息，這對於在維基上成功應用至關重要。
|<span lang="en" dir="ltr" class="mw-content-ltr">If we define and socialize across Product & Technology teams on the product needs for citations that are required for Abstract Content, we will be able to drive cross-Wikimedia work to deliver provenance information attached to Abstract Content, which is crucial for successful take-up across wikis.</span>
|
|-
|WE2.2.6
| 如果我們使後端內部請求格式更具表現力和簡潔性，我們可以提高系統的穩定性，從而支援更廣泛的推廣。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we make our backend-internal request format more expressive and concise, we can increase the system's stability, thereby supporting a broader rollout.</span>
|
|-
|WE2.2.7
| 如果我們使用維基數據和「維基函數」 (Wikifunctions) 呼叫來產生自然語言片段，提供原型片段，我們將表明該專案已準備就緒，並準備好用這來訓練人工智慧，這樣人類就不必過多考慮功能。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we provide prototype fragments using Wikidata and Wikifunctions calls to generate natural language snippets, we will show readiness for the project, and will be ready for it to be used to train AI so humans don't have to think too much about functions.</span>
|
|-
|WE2.2.8
| 如果我們提供帶有限定字符的維基數據語句的導入，就有可能產生多層面的事實（不僅需要主題/詞彙/值來表達的事實），這包括維基數據中估計 50% 的百科全書內容。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we provide import of Wikidata statements with qualifiers, it will be possible to generate multifaceted facts (facts requiring more than just subject/predicate/value to express), which includes an estimated 50% of encyclopedic content in Wikidata.</span>
|
|-
|WE2.2.9
| 如果我們提供檢索到的維基數據實體的緩存，我們將使基於維基數據內容的功能的平均運行時間減少至少 50%，從而減少逾時和使用者的挫折感。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we provide caching of retrieved Wikidata entities, we will reduce by at least 50% the average runtime of Wikidata content-based functions, reducing timeouts and user frustration.</span>
|
|-
|WE2.2.10
| 如果我們在「維基函數」 (Wikifunctions) 使用者介面中提供維基數據詞素感知元件，那麼貢獻者將能夠識別和選擇相關的詞素，而無需離開平台/「維基函數」 (Wikifunctions) ，從而減少上下文切換並能夠更快並更成功地創建與語言相關的功能。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we provide a Wikidata lexeme sense component into the Wikifunctions UI, then contributors will be able to identify and select relevant lexemes without leaving the platform/Wikifunctions—reducing context switching and enabling faster and more successful creation of language-related functions.</span>
|
|-
|WE2.2.11
| 如果我們解決達巴尼語社群關於維基百科上的「維基函數」 (Wikifunctions) 整合的可用性問題，我們會發現編輯者在測試期間將功能插入文章時遇到的關鍵可用性問題較少或為零。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we address usability findings from the Dagbani community on Wikifunctions integration on Wikipedia, we will observe that editors encounter fewer or zero critical usability issues when inserting a function into an article during testing.</span>
|
|-
|WE3.1.1
| 如果我們在 IOS 應用程式上對標籤式瀏覽功能的改進版本進行 A/B 測試，我們會看到標籤式瀏覽功能的多日使用率增加 5%。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we A/B test an improved version of the Tabbed browsing feature, on the IOS App, we’ll see a 5% increase in multi-day usage among Tabs users.</span>
|
|-
|WE3.1.3
| 如果我們為用戶提供一種新的方式，讓他們可以瀏覽文章頁面內的相關圖片或影片內容，我們將看到使用此功能的用戶的點擊率至少達到 3%。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we provide a new way for users to browse through relevant image or video content within article pages, we will see at least an 3% click-through rate among users who are presented with this feature.</span>
|
|-
|WE3.1.4
| 如果我們向讀者展示幾個用於遍歷維基上的知識網絡的概念，我們將得出一個優先概念列表，以供進一步開發。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we show readers several concepts for traversing the knowledge network on the wikis, we will come away with a prioritized list of concepts for further development.</span>
|
|-
|WE3.1.5
| 如果我們提供網路讀者一個選項，讓他們可以檢視其語言版本無法使用的維基百科內容的機器翻譯版本，我們就可以了解閱讀活動是否增加，以頁面互動增加 3% 來衡量，將讀者吸引到當地語言的維基百科，並可能增加當地的編輯活動。這將以控制 A/B 測試的方式進行，測試時間不超過 6 個月，並在事先取得同意的情況下，在 13 個維基百科中使用維基百科編輯人員已可使用的開放式機器翻譯服務。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we provide web readers the option to view a machine translated version of Wikipedia content unavailable in their language, we'll learn if reading activity is increased, measured as a 3% increase in page interactions, drawing readers to the local language wiki with a potential increase in local editing activity. This will be provided as a controlled A/B testing setting for no longer than 6 months, and in 13 Wikipedias with prior consent, using open machine translation services already available to Wikipedia editors.</span>
|
|-
|WE3.2.1
| 如果我們與籌款部門合作，我們將根據用戶測試結果，在 iOS 版本年度回顧中開發更具吸引力、更整合、更個性化的捐贈者幻燈片。我們將在第二季進行一項假設，評估改進後的年度回顧的捐款金額是否比 2024 年的年度回顧高出 5%。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we collaborate with fundraising we will develop more engaging, integrated, and personalized donor slides in the iOS Year in Review as measured through user testing. This will be followed up with a hypothesis in Q2 to assess if the improved Year-in-Review saw 5% more donations than 2024’s Year in Review.</span>
|
|-
|WE3.2.2
| 如果我們提示非活動市場的 Android 應用程式讀者，根據他們對維基百科的使用情況，設定可選、可自訂 (金額與頻率) 的捐款提醒，我們就會看到這些市場的 App 選單捐款增加 5%。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we prompt Android App readers in non-campaign markets to set up an optional, customizable (amount and frequency) reminder for donations based on their usage of Wikipedia, we’ll see a 5% increase in app menu donations in those markets.</span>
|
|-
|WE3.2.3
| 如果我們對未有登入的使用者進行 A/B 測試實驗，以顯示行動端和桌面端捐贈入口點的微妙變體，我們會觀察到透過處理路徑進行捐款的人數比對照高出 2%。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we run an A/B test experiment on logged out users to display subtle variants of the donation entry point for both mobile and desktop, we will observe a 2% higher number of donations via the treatment paths, as compared to control.</span>
|
|-
|WE3.3.1
| 如果我們將 2024 年 iOS 應用程式用戶要求的中低難度個人化元素加入到 2025 年的年度回顧中，透過可用性測試或測試版本，我們會發現滿意度比去年增加了 3%。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we add low to medium effort personalized elements requested by iOS users in 2024 to 2025’s Year-in-Review, we will see a 3% increase in satisfaction compared to last year, as measured through usability testing or beta testing.</span>
|
|-
|WE3.3.2
| 如果我們將 Android 應用程式上現有的「編輯」標籤擴展為個人化的活動中心，其中包括閱讀和非編輯參與的洞察，我們會發現與原始版本相比，該標籤的多日參與度增加了 5%。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we expand the existing Edit tab on Android into a personalized activity hub that includes insights into reading and non-editing participation, we’ll see a 5% increase in multi-day engagement with the tab compared to the original version.</span>
|
|-
|WE3.3.3
| 如果我們在 Android 應用程式中為帳號持有人推出至少一個可解鎖的頭像 (透過有意義的讀者動作賺取，如儲存一定數量的文章)，我們將可在多天內將登入使用者重複參與相關動作的比例提高 10%。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we introduce at least one unlockable avatar in the Android app for account holders—earned through meaningful reader actions like saving a certain number of articles — we’ll increase repeated engagement with associated action by logged-in users by 10% over multiple days.</span>
|
|-
|WE3.3.4
| 如果我們允許已登入的讀者將文章保存到私人閱讀列表，我們預計網站的參與度將會增加，以使用該功能的讀者的內部推薦流量增加 5% 來衡量，並且所有用戶的參與度都會有顯著的增加。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we give logged-in readers the ability to save articles to a private reading list, we expect engagement on the site to increase, as measured by a 5% increase in internal referral traffic for readers who use the feature, and a statistically significant increase for all users.</span>
|
|-
|WE3.3.5
| 如果我們進行一項使用者研究，允許網路讀者從維基百科收集/整理內容，那麼至少 10% 的參與者會將兩種或更多不同類型的內容（例如文章、摘錄、媒體）保存到一個集合中。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we conduct a user study that allows web readers to collect/curate content from Wikipedia, then at least 10% of participants will save two or more distinct types of content (e.g. articles, excerpts, media) to a collection.</span>
|
|-
|WE3.4.1
| 如果我們致力於混合存取點/內容傳遞網路部署，這將允許我們根據需要啟動完整的存取點和迷你存取點（實體和雲端），為未來的原型迷你存取點部署奠定基礎。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we work towards a hybrid PoP/CDN deployment, it will allow us to bring up both full PoPs and mini PoPs (physical and cloud) as required, laying the foundation for a prototype mini PoP deployment in the future.</span>
|
|-
|WE3.6.1
| 如果我們對未有登入的用戶保留率進行 A/A 測試，我們將為未來幾季使用的保留率建立基準。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we run an A/A test on retention rate for logged-out users, we will establish a baseline for retention rate we can use for future quarters.</span>
|
|-
|WE3.6.2
| 如果我們建立並發佈已登入讀者的定義，我們將能夠在與維基體驗 3.3 關鍵目標相關的所有團隊和假設中使用此定義。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we create and publish a definition of logged-in reader, we will be able to use this definition across all teams and hypotheses related to the WE 3.3 KR.</span>
|
|-
|WE3.6.3
| 如果我們讓社群參與討論讀者不斷變化的需求以及互聯網上知識的變化性質，我們就可以共同關注如何為讀者服務，並共同研究是否以及如何測試我們的各種想法（包括那些圍繞多媒體、搜尋與發現，以及機器學習的想法）。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we engage communities in conversations about the evolving needs of readers, and about the changing nature of knowledge on the internet, we can build a shared focus on how to serve readers and work together on whether and how to test our various ideas (including those around multimedia, search and discovery, and machine learning).</span>
|
|-
|{{anchor|WE4hypotheses}}WE3.6.4
| 如果我們研究讀者何時、為何以及如何使用維基百科和其他知識平台背後的不同動機、行為和需求，我們將獲得可用於指導和發展我們的消費者策略的發現。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we research the distinct motivations, behaviors, and needs behind when, why and how readers use Wikipedia and other knowledge platforms, we will have findings we can use to inform and evolve our consumer strategy.</span>
|
|-
|WE4.1.1
| 如果我們製作一個最小可行的非緊急流程的原型，並在與具有擴展權限的使用者一起開發這個原型時保持開放的迭代反饋循環，那麼這些群組將能支援該流程的擴展部署。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we prototype a minimally viable non-emergency flow, and keep open an iterative feedback loop as we develop it with users with extended rights, then these groups will support expanded deployment of this flow.</span>
| [[Special:MyLanguage/Incident Reporting System|Project page]]
|
|-
|WE4.2.1
|如果我們將與建立帳號相關的 hCaptcha 風險等級顯示給可信賴的功能人員，就能減少識別不良行為者所需的時間，並增加偵測到平台上建立的不良行為者帳號的次數。我們可以透過檢視應用於帳號的封鎖率、hCaptcha 風險等級與封鎖帳號的一致性，以及功能人員的定性回饋，來衡量這項假設是否成功。
|<span lang="en" dir="ltr" class="mw-content-ltr">If we surface the hCaptcha risk level associated with account creation to trusted functionaries, we will decrease the time needed to identify bad actors, and increase the number of detections of bad actor accounts created on the platform. We can measure the success of the hypothesis by looking at the rate of blocks applied to accounts, the alignment of hCaptcha risk levels and blocks of accounts generally, and qualitative feedback from functionaries.</span>
|
|-
|WE4.2.2
| 如果我們產生建議調查供 CheckUsers 跟進，我們就會看到識別不良帳戶所需的時間減少，而識別出的不良帳戶數量增加。當我們看到「建議調查」功能的定期使用率、透過建議調查所識別帳戶的減緩措施增加，以及定性調查回饋，我們就知道我們成功了。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we generate suggested investigations for CheckUsers to follow up on, we will see a decrease in the time needed to identify bad actor accounts and an increase in the number of bad actor accounts identified. We will know we’re successful when we see regular usages of the “Suggested investigations” feature, an increase in mitigations applied to accounts identified via suggested investigations, and via qualitative survey feedback.</span>
|
|-
|WE4.2.3
| 如果我們分析來自 hCaptcha 帳戶創建試驗的數據，我們將了解帳戶創建管道、hCaptcha 謎題和分數的有效性，並獲得必要的數據來進一步推出 hCaptcha 帳戶創建功能。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we analyze data from the hCaptcha account creation trial, we will understand the account creation funnel, the effectiveness of hCaptcha’s puzzle and scores, and have the data necessary to inform further rollout of hCaptcha on account creations.</span>
|
|-
|WE4.2.4
| 如果我們在所有維基媒體專案上部署用戶資訊卡，我們將使管理員能夠更有效地識別和緩解不良行為者帳戶。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we deploy the UserInfoCard across all wikis, we will empower functionaries and moderators to more efficiently identify and mitigate bad actor accounts.</span>
|[[mw:Special:MyLanguage/Trust and Safety Product/Anti-abuse signals/User Info|Project page]]
|
|-
|WE4.2.5
| 如果我們進行研究、諮詢社群並調查技術解決方案，我們將能夠定義一組可在所有維基媒體基金會維基媒體專案中使用的結構化封鎖原因。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we conduct research, consult with communities, and investigate technical solutions, we will be able to define a set of structured block reasons that can be used across all WMF wikis.</span>
|
|-
|WE4.2.6
| 如果我們開發出在資料平台上部署以開放搜尋為基礎的叢集能力，那麼產品功能工程團隊將獲授權開發整合此能力的系統，並擁有極大的自主性、彈性以及與其他以搜尋為基礎的系統的隔離。此系統的第一個主要租戶將是 IPoid 服務。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we develop the capability for deploying OpenSearch based clusters on the Data Platform, then product feature engineering teams will be empowered to develop systems that integrate this capability, with a great deal of autonomy, resilience, and isolation from other search-based systems. The first and principal tenant for this system will be the IPoid service.</span>
|
|-
|WE4.2.7
| 如果我們在幾個維基百科上部署 hCaptcha 企業版整合作為試驗，我們將能夠收集 hCaptcha 企業版在反濫用、機器人偵測、可用性和可及性方面的功效和價值的數據。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we deploy hCaptcha Enterprise integration on several production Wikipedias as a pilot trial, we will be able to collect data on the efficacy and value of hCaptcha Enterprise on anti-abuse, bot detection, usability and accessibility.</span>
|
|-
|WE4.3.1
| <span lang="en" dir="ltr" class="mw-content-ltr">If we integrate support for the new如果我們將對新的 Edge Uniques cookie into的支援整合到 requestctl, our edge rules engine forrequestctl（我們用於 [[:en:Special:MyLanguage/Site reliability engineering#Definition|SREs站點可靠性工程]] fighting abuse, we will better be able to defend from DDoS and content reuse.</span>對抗濫用的邊緣規則引擎）中，我們將能夠更好地防禦分散式阻斷服務攻擊和內容重複使用。
|
|-
|WE4.4.1
| 如果我們能夠根據試點的回饋做出改進，並將臨時帳戶部署到所有專案，我們將能夠保護所有專案中未有註冊用戶的個人識別資訊（IP 位址），使其僅向不到 0.1％ 的所有（已註冊）用戶開放。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we can make improvements based on pilots feedback and deploy Temporary Accounts to all projects we will be able to protect the exposure of personally identifiable information (IP addresses) of unregistered users on all our projects to be available to less than 0.1% of all (registered) users.</span>
|rowspan=4|[[mw:Special:MyLanguage/Trust and Safety Product/Temporary Accounts|Project page]]
|
|-
|WE4.4.2
| 如果我們及時、清楚地與相關維基媒體運動利害關係者（包括維基社群和全球管理員）進行溝通，我們將能夠在所有剩餘的維基媒體專案上進行部署，減少最後一刻發現的工作量，並避免回滾部署。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we communicate with the relevant movement stakeholders (incl. wiki communities and global functionaries) clearly and on time, we will be able to deploy on all remaining wikis, reduce workload discovered last-minute, and avoid rolling back deployment.</span>
|
|-
|WE4.4.3
| 如果我們讓巡邏員更輕鬆地根據臨時帳戶的 IP 位址過濾操作並查看臨時帳戶的活動，那麼我們將能夠成功地將臨時帳戶功能推廣到所有維基媒體專案。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we make it easier for patrollers to filter actions by and view the activity of temporary accounts, based on their IP addresses, then we will enable temporary accounts to be successfully rolled out to all wikis.</span>
|
|-
|WE4.4.4
| 如果我們允許根據 IP 顯示存取政策撤銷臨時帳戶 IP 顯示存取權限，並在更多地方展示該功能，那麼我們將能夠成功將臨時帳戶功能推廣到所有維基媒體專案。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we allow temporary account IP reveal access to be revoked in line with the IP reveal access policy, and surface the feature in more places, then we will enable temporary accounts to be successfully rolled out to all wikis.</span>
|
|-
|WE4.5.1
| 如果我們進行定性研究來確定產生人工智慧輔助的不良行為者的濫用範例（例如垃圾郵件、騷擾、長期濫用者、未公開的付費編輯或虛假宣傳活動），我們將能夠評估我們的社群模式的風險並產生減輕不同類型的產生人工智慧輔助濫用的想法。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we run qualitative research to identify examples of abuse from bad actors assisted by generative AI (such as spam, harassment, long term abusers, undisclosed paid editing, or disinformation campaigns), we will be able to assess the risk to our community models and generate ideas to mitigate different types of generative AI assisted abuse.</span>
|
|-
|-
|WE4.6.2
| 如果我們支持並鼓勵用戶註冊多個身份驗證因素，啟用雙重認證的用戶就不太可能將自己鎖定在帳戶之外。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we support and encourage users to register multiple authentication factors, users with 2FA enabled will be less likely to lock themselves out of their account.</span>
|
|-
|WE4.6.3
| 如果我們允許所有擁有已確認電子郵件地址的使用者為其帳戶啟用雙重認證，但不主動向使用者宣傳此更改，我們的復原支援服務台負載量將維持在可持續的水平。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we allow all users with a confirmed email address to be able to turn on 2FA for their accounts, but do not proactively advertise this change to users, our recovery support desk load will remain at a sustainable level.</span>
|
|-
|WE5.1.1
| 如果我們對經過驗證的會話和匿名會話使用不同的儲存後端，我們將能夠保護 Sessionstore 免受分散式阻斷服務攻擊和高容量抓取工具的侵害，因為不會因為在身份驗證頁面上建立匿名會話以提供跨站請求偽造預防而使其過載。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we use different storage backends for authenticated and anonymous sessions, we will be able to protect Sessionstore from DDoS attacks and high-volume scrapers, by not overloading it with the anonymous sessions that are created to provide CSRF prevention on authentication pages.</span>
| [[:phab:T398814|T398814]]
|-
|WE5.1.2
| 如果我們將 MediaWiki 會話 cookie 變更為具有加密簽章的結構化格式，我們將能夠使用會話的存在作為防禦抓取工具的因素，透過以高效能和高度可擴展的方式在邊緣啟用會話的可信任驗證。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we change MediaWiki session cookies to a structured format with a cryptographic signature, we will be able to use the presence of a session as a factor in protection against scrapers, by enabling trusted verification of sessions at the edge in a performant and highly scalable manner.</span>
| [[:phab:T398815|T398815]]
|-
|WE5.1.3
| 如果我們使用基於 Kubernetes 的本機開發環境為應用程式介面閘道建立速率限制解決方案，我們將能夠透過比較至少三種不同速率限制服務的效能和功能來確定使用生產流量進行測試的最佳選項。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we create a rate limiting solution for the API gateway using a local development environment based on Kubernetes, we will be able to determine the best option to test with production traffic, by comparing the performance and functionality of at least three different rate limiting services.</span>
| [[:phab:T398913|T398913]]
|-
|WE5.2.1
| 如果我們重新設計 REST 應用程式沙盒使用者介面以更好地滿足開發人員的資訊需求，我們將提高文件的清晰度，這已透過可用性測試得到驗證。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we redesign the REST API Sandbox UI to better meet developers’ informational needs, we will improve documentation clarity, as validated through usability testing.</span>
|
|-
|WE5.2.2
| 如果我們透過中央網關路由所有低於rest.php的應用程式介面，我們將解鎖集中式應用程式介面管理的手段，並可以開始持續測量 REST 應用程式介面流量和使用模式，以獲得可為未來決策和行動提供參考的見解。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we route all APIs under rest.php through a central gateway, we will unlock the means of centralized API management and can begin consistently measuring REST API traffic and usage patterns to gain insights that will inform future decisions and actions.</span>
|
|-
|WE5.2.3
| 如果我們為 MediaWiki REST 應用程式介面實作監控儀表板和警報，那麼我們可能會展示一種可持續、有用且可複製的方法來提高我們系統行為的可見性並更快地發現問題，特別是在關鍵修改期間。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we implement monitoring dashboards and alarms for the MediaWiki REST API, then we may demonstrate a sustainable, useful, and replicable way to improve visibility into our systems’ behavior and surface issues sooner, especially during critical modifications.</span>
|
|-
|WE5.3.1
| 如果我們在更新任何現有指導方針的同時，擴大並簡化使用者體驗歸因指導方針，我們將可建立一套經改良的核心指導方針，隨時準備進行內部測試與迭代改進，以準備供更廣泛的大眾使用。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we expand and streamline UX attribution guidelines while updating any existing guidelines, we will establish a core set of improved guidelines ready to be internally tested and iteratively refined to be prepared for broader public use.</span>
|
|-
|WE5.3.2
| 如果我們創建一個宣傳，展示將維基百科歸因於第三方內容重用者及其最終用戶的好處，我們可以透過讓至少一個額外的重用合作夥伴同意在第一季末出現在歸因案例研究或演示中來支持 WME4.1 和 WME4.2。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we create a pitch that demonstrates the benefits of attributing Wikipedia to 3rd party content reusers and their end-users, we can support WME4.1 & WME4.2 by enabling at least one additional reuse partner to agree to appear in an attribution case study or demo by the end of Q1.</span>
|
|-
|WE5.4.1
| 如果我們確保大多數網路請求都獲得邊緣唯一 cookie，那麼識別機器人和偽造請求將變得更加容易。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we ensure a majority of web requests get an edge uniques cookie, it will be easier to identify bots and forged requests.</span>
|
|-
|WE5.4.2
| 如果我們建立了可擴充的方式來識別已知用戶端，我們就可以允許經過驗證的機器人在一般速率限制上有例外，並且邁向有系統地執行我們的規則。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we build a scalable way to identify known clients, we can allow exceptions to general rate-limits for bots of verified origin, and move towards systematic enforcement of our rules.</span>
|
|-
|WE5.4.3
| 如果我們圍繞允許清單/拒絕清單方法重新組織內容傳遞網路上的文字請求過濾，我們可以對機器人實施更嚴格的一般速率限制並簡化流量過濾。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we reorganize filtering of text requests at the CDN around an allowlist/denylist approach, we can enforce stricter general rate-limiting for bots and streamline traffic filtering.</span>
|
|-
|WE5.4.4
| 如果我們制定統一的測量策略，我們將能夠評估「負責任地使用基礎設施」的多年期策略，並定義指導指標開發和報告能力的路線圖。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we develop a unified measurement strategy, we will enable evaluation of the multi-year strategy for 'responsible use of infrastructure,' and define a roadmap to guide metric development and reporting capabilities.</span>
|
|-
|WE6.1.1
| 如果我們將每日映像建置重新安置到部署伺服器並新增由選擇部署作業觸發的映像更新，我們將發現限制並為執行更連續部署所需的時間建立基準。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we rehome daily image builds to the deployment server and add image updates triggered by select deployment actions we will uncover constraints and establish a baseline for time needed to perform more continuous deployments.</span>
|
|-
|WE6.1.3
| 如果我們將 wikifarms 添加到合併前測試環境中，這將使開發團隊能夠針對生產進行構建，他們需要多個維基媒體專案來單獨測試他們的補丁，從而為他們提供更大的預生產信心，並減少缺陷逃逸。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we add wikifarms to a pre-merge testing environment this will enable development teams building against production who require multiple wikis to test their patches in isolation giving them greater pre-production confidence and result in fewer defect escapes.</span>
|
|-
|WE6.2.1
| 如果我們審查並發佈生產就緒清單，明確定義服務被視為生產就緒的先決條件以及可自助服務的任務，我們將協調[[:en:Special:MyLanguage/Site reliability engineering#Definition|站點可靠性工程]]和開發團隊之間的期望，從而提高我們的整體營運效率和可擴展性。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we review and publish our Production Readiness Checklist that clearly defines the prerequisites for a service to be considered production-ready, along with self-serviceable tasks, we will align expectations between [[:en:Special:MyLanguage/Site reliability engineering#Definition|SREs]] and development teams, improving our overall operational efficiency and scalability.</span>
|
|-
|WE6.2.2
| 如果我們宣布創建一個 Golang 和 nodejs 函式庫，為開發人員抽像出許多繁重的任務，他們將會提供回饋和興趣。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we announce creating a Golang and nodejs library abstracting a lot of toilous tasks for developers, they will respond offering feedback and interest.</span>
|
|-
|WE6.2.3
| 如果我們建立清單/工作表，開發人員可以提前充分準備資料持久性設計審查。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we create a checklist/worksheet, developers can fully prepare in advance for the Data Persistence design review.</span>
|
|-
|WE6.3.1
| 如果我們在第一季推出至少 70 個低流量維基百科（不包括支援語言變體的維基媒體專案），我們將對最終推出前 10 個維基媒體專案充滿信心，這將對透過 Parsoid 提供的頁面瀏覽量產生更大的影響。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we roll-out at least 70 low-traffic Wikipedias in Q1, excluding wikis with Language variant support, we will increase our confidence for the eventual roll-out to the top 10 wikis which will have a bigger impact in page views served through Parsoid.</span>
|
|-
|WE6.4.1
| 如果我們在自己的叢集中部署維基共享資源的分割連結表，我們將增加維基共享資源的資料庫成長維持永續性的機會。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we deploy splitting links table of Commons in its own cluster, we will increase the chances that database growth for Commons remains sustainable.</span>
| [[phab:T398709]]
|-
|WE6.4.2
| <span lang="en" dir="ltr" class="mw-content-ltr">If we (如果我們（[[:en:Special:MyLanguage/Site reliability engineering#Definition|SRE站點可靠性工程]]) provide assistance to the）為 MediaWiki engineering teams - by creating documentation, preparing necessary infrastructure (e.g.,工程團隊提供協助——透過創建文件、準備必要的基礎設施（例如 PHP packages, container images), and offering guidance and review - they will be able to confidently initiate the production、容器鏡像）以及提供指導和審查——他們將能夠在第二季度初自信地啟動生產 PHP 8.3 upgrade by the start of Q2.</span>升級。
|
|-
|WE6.4.3
| 如果我們要求具有提升的系統權限的使用者使用實體第二因素（硬體安全金鑰）進行安全殼層協定登錄，我們將降低受感染筆記型電腦造成嚴重安全漏洞的風險。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we require a physical second factor (hardware security key) for SSH logins by users with elevated system privileges, we will reduce the risk that a compromised laptop will cause a severe security breach.</span>
|- id="we644"
|-
|WE6.4.4
| 如果我們透過統一域名，將所有 MediaWiki 網站上的頁面訪問量統一到一個規範域名，那麼我們將能夠消除行動子域名重定向，從而降低平台複雜性和[[:en:Search engine optimization|搜尋引擎最佳化]]風險。完成度衡量標準是將規範網域名稱上的行動頁面訪問量從 0% 提升到 100%。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we unify our domains by serving all page views on MediaWiki sites through a canonical ___domain, then we will reduce platform complexity and [[:en:Search engine optimization|Search Engine Optimization]] (SEO) risks by eliminating the mobile-subdomain redirect. Completion is measured by increasing mobile page views on canonical domains from 0% to 100%.</span>
| [[phab:T214998|T214998]]
|
|}
{| class="wikitable"
! colspan="3" | 信號和數據服務（英文簡稱為：SDS）假設
! colspan="3" | <span lang="en" dir="ltr" class="mw-content-ltr">Signals & Data Services (SDS) Hypotheses</span>
[ [[Special:MyLanguage/Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs#Signals and Data Services (SDS)|<span lang="en" dir="ltr" class="mw-content-ltr">SDS Key Results</span>信號和數據服務關鍵結果]] ]
{{Blue button|link=Talk:Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs#Metrics (SDS1)|text={{MediaWiki:talk/{{PAGELANGUAGE}}}}}}
|-
! 假設簡稱 !! 第一季文字內容 !! 細節與討論
! <span lang="en" dir="ltr" class="mw-content-ltr">Hypothesis shortname</span> !! <span lang="en" dir="ltr" class="mw-content-ltr">Q1 text</span> !! <span lang="en" dir="ltr" class="mw-content-ltr">Details & Discussion</span>
|-
|SDS 1.1.1
| 如果我們分析自動流量偵測啟發式技術在我們的頁面瀏覽量資料集中的功效，我們將能夠發展資料品質指標來描述其效能，並決定是否需要進一步投資在這些啟發式技術上。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we analyze the efficacy of the automated traffic detection heuristics in our pageviews datasets, we will be able to develop data quality metrics to describe their performance and determine the need for further investment in these heuristics.</span>
|
|-
|SDS 1.2.2
| 如果我們將 XML Dumps 流程從目前的「Dumps 1」基礎架構遷移到利用 MediaWiki 內容管道的資料管道，我們將能夠保證服務等級目標並關閉基於「Dumps 1」的 XML 匯出。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we migrate the XML Dumps process from the current 'Dumps 1' infrastructure to a data pipeline that leverages the MediaWiki Content Pipelines we will be able to guarantee SLOs and turn off the 'Dumps 1'-based XML export.</span>
|
|-
|SDS1.2.3
| 如果我們對 MediaWiki 內容歷史和活動平台的服務等級目標進行一次演練和檢閱，我們就可以驗證消費者、度量指標和依賴的利害關係人，並找出服務等級目標可能需要的改進，這將有助於我們釐清每周交付保證中的任何缺口。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we do a walkthrough and review the SLOs for MediaWiki Content History and Event Platform / Event Gate, we can validate the customers, metrics, and dependent stakeholders, and identify improvements that might be needed for the SLOs, which will help us clarify any gaps in our weekly delivery guarantees.</span>
|
|-
|SDS2.1.1
| 如果我們與執行實驗的團隊密切配合，就能瞭解未來如何讓系統更自助，以及他們可能會遇到概念或技術上的挑戰。
| <span lang="en" dir="ltr" class="mw-content-ltr">if we pair closely with teams running experiments, we will learn how to make the system more self-service in the future and what conceptual or technical challenges they may run into.</span>
|
|-
|SDS2.1.2
| 如果我們能夠為事件日誌實現更好的調試，那麼產品團隊就會知道他們的實驗正在按預期收集事件數據，從而增加實驗所有者的信心。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we can implement better debugging for eventlogging, then product teams will know that their experiment is collecting event data as expected, increasing experiment owners’ confidence.</span>
|
|-
|SDS2.1.3
| 如果我們改進實驗平台的 A/B 測試系統 (xLab) 元件及其相關 MediaWiki 部分的日誌記錄和可觀察性，我們將能夠為系統效能建立基準並對與實驗相關的故障做出反應。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we improve logging and observability for the A/B testing system (xLab) component of the experimentation platform, and for its related MediaWiki parts, we’ll be able to establish baselines for the system's performance and respond to experiment-related failures.</span>
|
|-
|SDS2.1.4
| 如果我們每月一次在整個組織內分享實驗故事和結果（透過產品營運會議、設計團隊會議和跨團隊演示），那麼我們將創造實驗平台的有機採用。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we share experiment stories and results across the organization once a month (through Product Ops meetings, Design team meetings, and cross-team presentations), then we will create organic adoption of the experimentation platform.</span>
|
|-
|SDS2.1.5
| 如果我們告訴使用者，他們的儀器 (如果是在 xLab 中建立的) 包含一組會改變風險類別的屬性，我們就能阻止儀器使用者過度收集資料，並提高屬性組合需要隱私權審查的清晰度。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we tell users that their instrument, if created in xLab, contains a set of attributes that changes the risk category, we will deter instrumentation users from over-collecting data and increase clarity around what combination of attributes require privacy review.</span>
|
|-
|}
{| class="wikitable"
! colspan="3" |未來讀者（英文簡稱為：FA）假設
! colspan="3" |<span lang="en" dir="ltr" class="mw-content-ltr">Future Audience (FA) Hypotheses</span>
[ [[Special:MyLanguage/Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs#Future Audiences (FA)| <span lang="en" dir="ltr" class="mw-content-ltr">FA Key Results</span>未來讀者關鍵結果]] ]
{{Blue button|link=Talk:Wikimedia Foundation Annual Plan/2025-2026#Future Audiences (FA1)|text={{MediaWiki:talk/{{PAGELANGUAGE}}}}}}
|-
! 假設簡稱 !! 第一季文字內容 !! 細節與討論
! <span lang="en" dir="ltr" class="mw-content-ltr">Hypothesis shortname</span> !! <span lang="en" dir="ltr" class="mw-content-ltr">Q1 text</span> !! <span lang="en" dir="ltr" class="mw-content-ltr">Details & Discussion</span>
|-
|FA1.1.1
|如果我們 1）為其他平台（如 Letterboxd、Goodreads 和 RateMyMusic）上的媒體收藏者提供方法，利用維基百科獨有的知識來增強他們的收藏，或 2）為這些媒體收藏者提供有趣的社交媒體共享內容，那麼我們將能夠增加維基百科在平台外的影響力。
|<span lang="en" dir="ltr" class="mw-content-ltr">If we 1) offer ways for media collectors on other platforms (such as Letterboxd, Goodreads, and RateMyMusic) to enhance their collections with Wikipedia-exclusive knowledge, or 2) offer these media collectors interesting social media shareables, then we will be able to increase Wikipedia's reach off-platform.</span>
|
|-
|FA2.1.1
| 果我們在第一季建立內部創建短片內容的能力（透過擴大團隊規模以及審核和識別提高當前生產流程效率的機會），我們將能夠根據財政年度 2024-2025 創建的內容的經驗採取行動，並實現財政年度 2025-2026 第二季度所製作內容的同比覆蓋率更高。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we build up our internal capacity to create short video content (by increasing our team size and auditing and identifying opportunities to increase efficiency in our current production process) in Q1, we will be able to act on learnings from content created in FY2024-5 and achieve higher YoY reach of content produced in Q2 FY2025-6.</span>
|
|}
{| class="wikitable"
! colspan="3" |產品和工程支援（英文簡稱為：PES）假設
! colspan="3" |<span lang="en" dir="ltr" class="mw-content-ltr">Product and Engineering Support (PES) Hypotheses</span>
[ [[Special:MyLanguage/Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs#Product & Engineering Support (PES)| <span lang="en" dir="ltr" class="mw-content-ltr">PES Key Results</span>產品和工程支援關鍵結果]] ]
{{Blue button|link=Talk:Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs#Product & Engineering Support (PES1)|text={{MediaWiki:talk/{{PAGELANGUAGE}}}}}}
|-
! 假設簡稱 !! 第一季文字內容 !! 細節與討論
! <span lang="en" dir="ltr" class="mw-content-ltr">Hypothesis shortname</span> !! <span lang="en" dir="ltr" class="mw-content-ltr">Q1 text</span> !! <span lang="en" dir="ltr" class="mw-content-ltr">Details & Discussion</span>
|-
|PES1.1.1
| <span lang="en" dir="ltr" class="mw-content-ltr">If we support如果我們支援 xLab, 、Charts, and和 ToneCheck in為 defining metrics for SLIsPrometheus (中的[[:en:Special:MyLanguage/Service level indicators|Service Level Indicators服務等級指標]])定義指標，並在 in Prometheus, and onboard thePyrra those上加入這些 [[:en:Special:MyLanguage/Service-level objective|Service Level Objectives服務等級目標]] (SLOs) on Pyrra, we'll learn the limits and corner cases of our tooling in multiple complex scenarios, as well as clarify what iterations are needed for the SLO template, which will help us to better support the，我們將了解我們的工具在多個複雜場景中的限制和極端情況，並明確指出服務等級目標模板需要哪些迭代，這將幫助我們的 6 planned SLOs for the KR.</span>個迭代模型。
|
|-
|PES1.1.2
| 如果我們試用兩套服務等級目標警報儀表板，就能了解實施合適的工具，讓服務所有者清楚了解他們的承諾有多難，以及是否需要遷移到其他僅提供特定服務等級目標單一視圖的工具。一套儀表板將用於季度報告（其中設定了錯誤預算的實際[[:en:Special:MyLanguage/Service-level agreement|服務等級協定]]），另一套規模較小的動態儀表板（稱為「滾動」）用於日常營運和警告。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we pilot two sets of SLO alert dashboards, we'll learn how difficult it would be to implement suitable tooling such that service owners clearly understand their commitments, and also whether we need to migrate to a different tool that offers only a single view of a specific SLO. One dashboard will be for quarterly reports (where the actual [[:en:Special:MyLanguage/Service-level agreement|Service Level Agreement]] for the error budget is set) and a smaller dynamic one (called "rolling") will be for day-to-day operations and alerting.</span>
|
|-
|PES1.1.3
| 如果我們繼續支援抽象維基百科 (Abstract Wikipedia) 小組為維基函數(Wikifunctions) 專案起草[[:en:Special:MyLanguage/Service-level objective|服務等級目標]]，我們將學習如何為目前正在新增至關鍵使用者工作流程的複雜功能——即算繪維基文章——定義一系列服務等級目標（以及其的服務等級指標）。我們同時將學習如何使用[[:en:Special:MyLanguage/Site reliability engineering#Definition|站點可靠性工程]]提供的儀表板和監視器，正確地視覺化相關的錯誤預算並發出警報。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we keep supporting the Abstract Wikipedia group in drafting an SLO ([[:en:Special:MyLanguage/Service-level objective|Service Level Objectives]]) for the Wikifunctions project, we'll learn how to define a list of SLO targets (alongside with their Service Level Indicator metrics) for a complex feature currently being added to a critical user workflow: rendering Wiki articles. We'll also learn how to properly visualize the related error budgets and alert on them using dashboards and monitors provided by [[:en:Special:MyLanguage/Site reliability engineering#Definition|SRE]].</span>
|
|-
|PES1.1.4
| 如果我們支援資料平台群組對 MediaWiki 內容歷史專案的[[:en:Special:MyLanguage/Service-level objective|服務等級目標]]進行審查和迭代，我們將學習如何在批次和串流處理服務組合在一起更新資料集時利用服務等級目標來支援服務所有權，使其保持一致並可供下游使用者使用。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we support the Data Platform group with review and iteration of the [[:en:Special:MyLanguage/Service-level objective|Service Level Objectives]] (SLO) for the MediaWiki Content History project, we'll learn how to leverage SLOs to support service ownership when a combination of batch and stream processing services are orchestrated together to update dataset, keeping it consistent and available to downstream users.</span>
|
|-
|PES1.2.1
| 如果我們對願望清單進行 3 項有針對性的改進，那麼我們將鼓勵願望清單中的獨立參與者增加 30%。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we create 3 targeted improvements to the Wishlist, then we will encourage 30% more unique participants in the Wishlist</span>
|
|-
|PES1.2.2
| 如果我們對收到的願望進行分類並在 72 小時內指派一名維護者（例如產品經理）（包括拒絕、澄清、標記未維護的服務等），透過將新願望與維護者表進行交叉引用，並將「維護者類別」分配給最相關的產品團隊或個人參與者，維護者（例如產品經理）將能夠在 10 天或更短的時間內評估並回應願望。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we triage incoming wishes and assign a Maintainer (e.g. Product Managers) within 72 hours (including declining, clarifying, flagging unmaintained services, etc.), by cross-referencing new wishes against the Maintainers table and assigning a “Maintainer category” to the most relevant product team or individual, Maintainers (e.g. Product Managers) will be able to assess and respond to wishes in 10 days or less.</span>
|
|-
|PES1.2.3
| 如果我們試行辨識整個社群訊號的工作，我們將在社群知情的優先排序工作中納入更多志願者的聲音。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we pilot work to identify community signals at large, we will incorporate more voice of volunteer in our community-informed prioritization efforts</span>
|
|-
|PES1.2.4
| 如果我們在第一季與 3 個團隊試行季度願望和社群訊號審查流程，我們將讓產品經理將社群訊號整合到他們的季度和年度計劃流程中。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we pilot a quarterly wish and community signal review process with 3 teams in Q1, we will engage Product Managers to integrate community signals into their quarterly and annual planning processes.</span>
|
|-
|PES1.3.1
| 如果到第一季末，我們能夠與傳播部門和產品團隊協調 3 次功能規劃會議，以協調維基百科二十五週年慶祝計劃的資訊傳遞、創意需求和活動時間表，那麼我們將最終確定所有 3 個活動實驗（25YiR、復活節彩蛋、WikiRun）的創意簡報。
| <span lang="en" dir="ltr" class="mw-content-ltr">If, by the end of Q1, we coordinate 3 functional planning sessions with the Communications department and product teams to align on messaging, creative needs, and campaign timelines for WP25 initiatives, then we will finalize creative briefs for all 3 campaign experiments (25YiR, Easter Eggs, WikiRun).</span>
|
|-
|PES1.3.2
| 如果我們建立一個由設計和功能工程代表組成的指導委員會，我們將能夠定義關於 Codex 貢獻的基準指標：知名度、使用情況、貢獻品質和數量。透過評估這些基準指標，我們將能夠制定路線圖，以促進 Codex 貢獻者群體的共同成長和多元化。
| <span lang="en" dir="ltr" class="mw-content-ltr">If we establish a steering committee with representatives from Design and feature engineering, we will be able to define baseline metrics about contributions to Codex: awareness, usage, quality of contribution, and quantity. Insights from assessing against these baseline metrics will help us determine a roadmap for federating growth and diversification of the Codex contributor base.</span>
|
|-
| 