維基媒體基金會年度計劃/2025-2026/產品與技術目標與關鍵結果
未來的一年
即使我們的世界正在發生變化，維基媒體基金會仍然堅信我們的使命——使維基媒體專案中的有用信息在互聯網上自由提供並保持可用——這是一項跨世代的事業：我們希望自由知識能夠繼續為我們的下一代所用。
網路變化迅速。新世代透過社群影片與人工智能體驗獲取資訊，相較於以前的世代，較少人知道維基百科。我們發現造訪我們網站的人數和編輯維基百科的人數都在下降。同時，網路上的各個平台都依賴維基媒體內容來支援其人工智慧和搜尋服務。這些動態是重大挑戰，但這清楚地表明了為什麼我們共同創造的可靠的自由知識如此重要。世界比以往任何時候都更需要值得信賴並經過人工審核的知識來源，而維基媒體專案正在繼續證明我們可以提供這樣的知識來源。
為了在未來一年應對這些挑戰，我們將建立可持續利用維基媒體內容的途徑，並將維基媒體內容帶到新一代聚集的線上社交空間。我們將改進我們自己的網站，以便讀者願意回來，深入參與，並以對他們有意義的方式做出貢獻。我們將投資於快速試驗新技術的能力，以便我們的發展速度能夠跟上世界變化的速度。
至於基礎設施方面，我們的目標實為平臺本身及使用者體驗如何支援應對前述挑戰，並顧及維基媒體運動大多數參與者。這並非一系列專案，而是一套指導方針，旨在促進志願者的成長，使志願者能夠創建值得信賴的百科全書內容，為我們的使命提供資金，並改進我們的服務以塑造不斷變化的網路。您可以在此閱讀有關這四大策略支柱的更多資訊。
推動志願者的成長
志願者社群是維基媒體專案得以成功的獨特引擎，我們需要社群健康和成長——但在過去的一年裡，我們看到專案的新編輯和回歸編輯的數量持續下降。為深入理解並有效回應志願者現行需求，基金會將社群願望清單從一年一次的調查改組為一個全年開放的流程，使用者需求和專案想法可以回饋到維基媒體基金會多個團隊的工作中。為了實現這一目標，我們將這些願望分為幾個「重點領域」，並將其中三個重點領域納入年度計劃的關鍵成果之下。我們且新設「產品及技術諮詢委員會」此一組織，以彙整基金會團隊全年與社群成員在站內外的諸多討論意見。與此同時，我們更看到了融入新一代的機會：青年人正熱切參與其他線上社交空間，以便利使用、適合行動裝置的管道就共同感興趣的主題進行交流。
在未來的一年裡，我們將透過擴展移動優先、新的編輯方式（「結構化任務」），以及添加智能工作流程，讓新貢獻者可以輕鬆地進行建設性的移動編輯（「編輯檢查」），讓貢獻對新一代具有吸引力。為維持既有志願者並加深他們的參與，我們將建議各種操作及任務，並統一在特定中央樞紐顯示，以便於管理站內活動。在這些功能中，我們將精心使用人工智慧來加強志願者的工作，始終讓人類參與其中並優先考慮透明度。對於新志願者和有經驗的志願者，我們將在我們的網站上建立聯繫和協作的途徑——受到成功的活動和維基媒體專案的啟發——讓他們找到志同道合的編輯者並改進與他們的興趣相關的內容（與這個願望清單重點領域一致）。
提供值得信賴的百科全書內容
隨著網路上人工智慧生成的素材不斷增加，世界比以往任何時候都更需要值得信賴的百科全書內容。我們希望提高志願者產生新內容的能力，確保現有內容的可信度，並將這些內容向擁有新需求及喜好的次世代讀者傳遞。
為了幫助志願者產生新內容，我們將改進內容創建功能（例如內容翻譯工具），以便較小的社群可以涵蓋重要內容。同時，為了保證內容的可信度，我們將通過擴展他們用來查找需要他們關注任務的工具來幫助經驗豐富的志願者更好地管理他們日益增加的工作量——使他們更容易更新文章和撤銷無用的編輯（與這個願望清單重點領域一致）。
我們同時將以既有IP位址以外可識別不良行為者的新特徵，幫助管理人員保護我們的內容，從而以最大限度減少對善意編輯者的錯誤屏蔽。
為了將百科全書內容傳遞給新一代，我們將建立一些功能以幫助新一代讀者輕鬆理解文章，幫助他們找到感興趣的訊息，並允許他們在閱讀時積極參與。這些變化旨在鼓勵新的維基百科讀者成為忠實的維基百科讀者，並鼓勵其中一些讀者成為捐贈者（與此願望清單重點領域一致）。
提供可信賴的內容同時意味著支持「知識即服務」模式，即整個互聯網均利用維基媒體的內容。在這個模式中，我們的基礎建設不僅是人類進入我們網站的寶貴資源，同時是搜尋與人工智能公司的寶貴資源，這些公司會自動存取我們的內容，作為其產品的基本輸入與輸出。這類公司只是眾多用途中的一種，他們給我們的基礎設施帶來了日益難以承受的負擔。在過去的一年裡，來自抓取工具和機器人的請求量大幅增加，這使得我們更迫切地需要糾正這一趨勢。我們需要為開發人員和重用者建立存取知識內容的可持續途徑，以便人類優先於機器人。
為「自由」的未來提供資金
產品和技術部門在確保我們維基媒體運動永續性方面發揮著重要作用。在未來的一年裡，我們將與籌款團隊密切合作，以便我們的捐贈者獲得越來越清晰和有益的體驗。在我們的網站和行動應用程式上，我們將為讀者創造透過捐贈表達對維基百科感激之情的機會，並且我們將建立讓捐贈者感受到認可的新方式，以便他們年復一年地繼續捐贈。
塑造不斷變化的網路
為了向世界上的每個人提供自由的知識，我們需要滿足他們的需求，提供有助於他們學習的經驗。18至24歲的人們，對維基百科的認知和使用率都比上一代人低。他們主要從短視訊平台、可信賴的線上人物、社交遊戲體驗，以及越來越多的人工智能應用程式中學習與互動。今年，我們將在這些受眾的上網場所向他們提供維基百科，以便他們將維基百科視為由人類創造並值得信賴的知識來源。我們將擴大在熱門影片平台上的影響，傳播維基百科內容並在這些空間中建立社群。我們同時將探索將維基百科知識引入遊戲和社交平台的想法。
至於基礎設施，我們將之分為三個有關組合面向：「維基體驗」（Wiki Experiences）、「信號和數據服務」（Signals and Data Services）及「未來觀眾」（Future Audiences），均與過去兩年的目標相同。
總的來說，我們相信這個計劃正值網路歷史上的關鍵時刻，使我們能夠確保自由知識內容繼續為各個年齡層的人們所獲取和塑造。我們的目標和關鍵成果更詳細地展示了這個計劃的結構和內容，我們期待聽到更廣泛社群的問題和想法。
以深耕價值為維基媒體計畫站點及志願者建設、改善及維護基礎設施
「基金會將永遠免費提供旗下站點所產生及保存的有用資訊。」
產品及技術團隊常年致力於優先改善及維護維基媒體計畫站點營運所需的基礎設施。我們投資伺服器，開發開源軟體及設計系統，並維護、改善資料產品及人工智慧模型基礎設施。
我們的部分關鍵工作著重於開發及主持大型熱門網站所需基礎。我們將維基媒體計畫站點內容放置於資料中心、伺服器及其他自有硬體，予以安裝、維護，並經由高速網路架構互相連結。我們監控並適時擴充網站量能，同時汰換老舊設備。例如今年，我們即預計為美國維吉尼亞州阿士伯恩（Ashburn）及德克薩斯州喀拉爾頓（Carrollton）兩個資料中心更新硬體、擴充量能。
我們設計並開發MediaWiki等開源軟體，且應用許多既有第三方開源應用程式、資源庫及框架。維護開源軟體需要熟悉開源軟體研發、站點可靠度工程（site reliability engineering，SRE）、產品管理、專案管理、設計等領域專業的特殊人才。為應對環境變遷，我們的職員致力確保軟體及系統正常更新，這即包括適當更新程式碼，以符合安全修補要求，並與第三方軟體配合良好。例如，MediaWiki以PHP程式語言寫成，而近一年來，我們將其PHP版本由第7.4版升級至第8.1版；這同時需要變更代碼與站點及服務主機所在的基礎設施。今年，我們將利用此前習得經驗及升級第8.1版期間所研發的工具，進一步將之升級至第8.3版。此類更新可以加速讀者讀取、方便職員及志願者使用系統，並全面加強安全保障；與此同時，使用提升安全程度、性能及額外支援的最新程式語言，更有利於節省未來開發時間。
為確保各站點內容得以永遠在線上提供，我們的團隊竭盡全力，維持站點及服務正常可用，其中即包含遭逢巨大災難或惡意事件之後的復原工作：我們一向備份重要資料，以用於還原；另外，每年還會測試自動切換資料中心兩次，並解決此間所發現的問題。與此同時，我們亦注重追蹤並因應收穫流量類型及規模的變遷趨勢；例如，值此自動爬蟲遽增之際，我們正優先確保人類得以持續存取各站點及服務，並以系統方法樹立基礎設施正常使用規範。
無論如何，並非所有工作均能提前規劃。我們亦需要應對網站斷線、安全報告與事故、大規模破壞等預料之外的狀況。我們會監控妨礙讀者正常存取的問題（如網路連線、審查封鎖等），並調查任何異常事件。部分意外或重複出現的問題，將由職員臨時處理，之後再提出完整解決方案，以避免額外負面影響。我們利用最佳化效能、重新設計瓶頸區域架構、增加整體量能等手段，使維基媒體站點得以承受因重大新聞事件（如知名人物逝世等）遽增的全球流量，而不至於崩潰。與此同時，我們近來針對流量管理工具及系統所從事的改善措施，亦足以更加迅速而有效地因應情況變遷。此類調適工作，正是我們面對新興事件之際確保各站點內容存取無礙的關鍵。
產品與技術目標
此處提出的目標尚處於草案形式，歡迎大家提出評論和討論。
- 目標代表高階方向。
- 「關鍵結果」（英文簡稱為：KRs）代表一種可衡量的方式來追蹤其目標的成功程度。
- 每個關鍵結果的基本「假設」代表了我們為達成相關關鍵結果所做的實際工作。這些假設將會在本文件以及相關專案或團隊的維基媒體頁面上，隨著全年的深入了解而更新。
-
代表維基媒體基金會在社群願望清單下優先考慮的工作。
維基體驗 （英文簡稱為：WE）
貢獻者體驗 （維基體驗 1）
- 目標：由於志願者獲得了引人注目的機會並了解其作出的影響，因此貢獻增加。
- 背景：這一目標將成為實現新貢獻者策略的基礎，該策略有三大支柱：1）為志願者提供一種集中的方式來組織他們的維基活動，2）提供更小和更獨立的任務以創造更大的清晰度並幫助志願者發揮他們的潛力，3）使貢獻更有意義。在財政年度2025/2026 ，我們計劃提供基本的基礎設施，幫助志願者以集中的方式組織他們的維基活動，首先是專門針對經驗豐富的編輯和管理者的干預措施。在接下來的幾年裡，我們將增加對所有貢獻者角色的干預措施並涵蓋更多的問題空間。此外，我們將繼續投資於編輯檢查和結構化任務，為如何以可擴展的方式使用人工智慧奠定基礎，既作為編輯過程中的指導，同時作為向志願者指出引人注目的機會的一種方式。最後，我們將投入資金讓志願者的影響力更加明顯，為他們創造更有意義的體驗。
- 關鍵結果——維基體驗1.1：根據第二季末的實驗測量，對於累積編輯次數少於或等于 100 次的編輯者，建設性編輯 [i] 增加 4%。[ii]
- i.「建設性編輯」= 發佈在任何維基百科主命名空間後 48 小時內未撤銷的編輯
- ii. T389403#10960480
- 新的志願者努力開始成功編輯——特別是使用行動裝置的使用者，螢幕空間有限，注意力經常分散。
- 有些人厭倦了建設性貢獻所需的背景、耐心和反覆試驗。其他人尚未遇到令人信服的嘗試機會。
- 維基體驗1.1 將透過以下方式解決這些問題：
- 顯示編輯建議
- 提供可操作的編輯指導
- 建立更多針對特定任務的編輯工作流程
- 這些工作的核心是需要可擴展的方法來檢測正在進行的編輯和現有內容如何改進。為了提升這種能力，我們將繼續嘗試機器學習，以了解如何才能更好地服務不同角色和經驗水平的編輯者。
- 建議的關鍵結果評分方法：我們將以每個平台為單位，計算我們部署並透過對照實驗評估的干預措施中，達到和/或超過我們年初設定的建設性編輯目標的比例。請參見 phab:T379285#10782051 以查看我們的想法。
- 注：截至2025年6月30日， WE 1.1已經計劃進行兩組對照試驗。
- 背景：這一目標將成為實現新貢獻者策略的基礎，該策略有三大支柱：1）為志願者提供一種集中的方式來組織他們的維基活動，2）提供更小和更獨立的任務以創造更大的清晰度並幫助志願者發揮他們的潛力，3）使貢獻更有意義。在財政年度2025/2026 ，我們計劃提供基本的基礎設施，幫助志願者以集中的方式組織他們的維基活動，首先是專門針對經驗豐富的編輯和管理者的干預措施。在接下來的幾年裡，我們將增加對所有貢獻者角色的干預措施並涵蓋更多的問題空間。此外，我們將繼續投資於編輯檢查和結構化任務，為如何以可擴展的方式使用人工智慧奠定基礎，既作為編輯過程中的指導，同時作為向志願者指出引人注目的機會的一種方式。最後，我們將投入資金讓志願者的影響力更加明顯，為他們創造更有意義的體驗。
- 關鍵結果——維基體驗1.2：到第四季末，維基媒體專案上的協作數量比去年同期成長55%。
- 貢獻者經常努力尋找彼此合作的機會，尤其是圍繞著他們關心的主題和任務。這可能會導致新成員在維基媒體專案上感到孤獨，同時可能會導致經驗豐富的編輯者感到倦怠。此外，協作活動的影響通常不明確，這可能導致較少的人願意加入、組織或支持維基上的協作。
- 我們希望透過以下方式使協作的價值更加明確：
- 創造新的方式來分享維基媒體專案上協作活動的影響
- 開始收集協作活動為整個維基媒體運動帶來影響的資料
- 建立基本的基礎設施來追蹤協作貢獻，以便我們將來能夠提供創新的新方法來認可和獎勵貢獻
- 協作將透過 CampaignEvents 擴充工具中的「活動註冊」功能所建立的新活動來衡量。我們的目標是，到關鍵結果結束時，我們將擁有更多擴充工具的使用者，以及顯示合作影響力的新方案。這將使我們能夠很好地將我們現有的基礎架構與其他表彰和獎勵維基上工作的方式（例如影響模組、感謝等等）連結起來。
- 願望清單重點領域：社群願望清單/重點領域/連結貢獻者
- 關鍵結果——維基體驗1.3：到第三季末，在向新任管理員展示的專屬首頁中，有10%的貢獻者連續兩週造訪該頁面。
- 我們相信能更有效地為志願者提供貢獻機會。長遠而言，我們認為主頁可以幫助所有編輯組織工作、尋找新的機會並了解自身的影響。在2025/26財政年度，我們的目標是為資深編輯提供新的機會，讓他們承擔一些他們原本可能不會接觸到的審核任務。
- 我們將首先透過了解經驗豐富的編輯會如何與類似於新手所能訪問的主頁互動來檢驗這個理論。
- 然後，我們將向不熟悉此類審核操作的貢獻者介紹具體的審核活動（細節待定），旨在透過減少積壓案件（在新的關鍵成果框架下）來減輕資深編輯的負擔。
- 如果首頁設計方案成功，我們計劃將其模組化，以滿足不同社群的需求。這些模組可能包括幫助編輯更輕鬆地了解其內容影響等功能。
- 有關此方法論的備註：
- 我們將提出一個假設來定義我們的受眾，這將是維基體驗 1.3.1 的一部分。
- 「管理工具」將遵循Research:Develop a working definition for moderation activity and moderators中開始的定義，但需要後續工作來縮小定量定義。
- 第二週將根據每位用戶首次造訪的時間點來界定。在此情況下，我們將審查所有在指定時間段內造訪首頁的新任管理員，且其後至少再進行一次重複造訪（間隔7至14天）。
- 願望清單重點領域：社群願望清單/重點領域/任務優先順序
- 我們相信能更有效地為志願者提供貢獻機會。長遠而言，我們認為主頁可以幫助所有編輯組織工作、尋找新的機會並了解自身的影響。在2025/26財政年度，我們的目標是為資深編輯提供新的機會，讓他們承擔一些他們原本可能不會接觸到的審核任務。
- 關鍵結果——維基體驗1.4：提高點擊查看「編輯」按鈕的獨立訪客對關注列表和/或最近更改的訪問比例。
- 我們的目標是協助擁有100次以上編輯經驗的編輯，更有效率地找到並開啟符合其興趣的編輯任務。我們將深入探索任務優先級聚焦領域，實現該領域的願望清單，並徵求志願者對如何改善這些介面的額外反饋。我們可透過提升各頁面"尋找工作"的效能來衡量成效，此效能將以點擊率指標作為衡量標準。
- 關鍵結果——維基體驗1.5：定義並實施七項高優先級指標 [1]，以便在第四季度末追蹤實現貢獻者策略中各目標的達成進度，具體措施包括建立儀表板，並將每月活躍管理員指標納入常態運作機制。
[1]指標包含：留存編輯、建設性活躍度、建設性編輯次數、新進用戶帳戶註冊留存率、按資歷劃分的活躍編輯者、按經驗等級劃分的活躍編輯者。- 貢獻者體驗策略規劃了一項為期三至五年的行動計劃，旨在透過三大核心活動領域「推動志願者增長」並「提升新舊貢獻者的留存率與活躍度」：
- 簡化志願者接收推薦、管理任務與興趣、掌握維基媒體專案的動態，以及理解自身影響力的流程
- 我們提供結構合理的任務，以提高清晰度，並透過優化分配給志願者的工作流程，幫助他們充分發揮潛力。包括持續投入資源提供系統化指導與自動化重複性任務，特別著重於行動網頁體驗的改善。
- 透過向志願者展示他們的貢獻所帶來的影響，並投資於人際溝通管道和基於正面回饋的環境，使貢獻更有意義。
- 隨後，一項衡量策略專案勾勒出龐大的指標網絡，用以追蹤此變革理論。該專案結論指出，成功的主要衡量標準（「核心指標」）應為留存編輯者的數量，輔以更精準的指標（如建設性活躍度與貢獻者回歸意願）及更廣泛的「下游」指標（如活躍編輯者數量與優質內容產出）。我們必須確保這些指標能實際運作並顯示於儀表板中，以便追蹤策略執行進度。
重要知識（維基體驗2）
- 目標：提供更多不同語言和主題的重要知識，並加以說明。
- 目標背景：此目標將推動內容成長，以回應貢獻者對特定主題和語言的興趣，以及讀者對圖文並茂的重要知識的需求。重要知識是提供可用維基百科語言專案所需主題廣度與深度的文章集合。這是由社群所定義，並參考可記性、相關性、預測讀者人數以及文章之間的連結。
- 我們將採取社會技術性的方案，改善功能、工具和社會流程的效能。我們將在建議任務、媒體搜尋和內容翻譯等高影響力的產品功能的基礎上，促進較小語言維基百科的加入和發展。我們將支援維基媒體的組織者，他們招募、訓練並支援貢獻者，讓他們透過維基媒體專案和活動等協作設定，達成共同的內容目標。（我們估計每季至少有 300 位活躍組織者。）我們同時會與最相關的出版商建立關係，以消除取得原始資料的障礙。（我們目前與 100 多家全球頂尖的訂閱型資料庫建立了合作關係。）
- 為了確保我們的措舉對重要知識有正面的影響，我們將同時測量社群優先內容的增加量以及該內容的品質，並檢視還原率、引用和圖片數量等因素。
- 關鍵結果——維基體驗2.1：到第二季末，試驗並評估 3 項措施，幫助貢獻者改善其維基百科上重要內容的狀態。
- 本關鍵結果將重點放在編輯機制中的內容差距，例如在維基百科上發現圖像、內容翻譯和指導新文章的創建。我們同時將實施和測試社會技術介入措施，以支援小語言社群的內容創作活動。我們將根據每個假設來衡量成功。
- 關鍵結果——維基體驗2.2：在第四季度末之前，建立必要的平台功能，以驗證我們能否大規模支持抽象维基百科(Abstract Wikipedia)的願景。如果我們能夠證明該系統利用維基數據和自然語言生成技術輸出豐富的多語言百科全書內容，由維基媒體社群控制，並且在廣泛部署中保持性能，那麼我們就成功了。
- 既然我們已經能夠使用維基數據在不同的維基百科上輸出基本的純文字內容，下一步就是繼續建立平台功能，以大規模支援抽象維基百科(Abstract Wikipedia)。該平台需要支援豐富的多語言內容，這些內容可以由社群控制，並且能夠在大規模部署時保持高效能。這是一個里程碑式的關鍵成果，標誌著我們從 0 邁向 1。
- 關鍵結果——維基體驗2.3：到第四季末，部署新版維基的初始版本，以便社群儘早建立抽象維基百科(Abstract Wikipedia)的項目。
- 這項關鍵成果為我們明年測試抽象維基百科(Abstract Wikipedia)的平台功能奠定了基礎。這個全新的獨立維基媒體專案將託管基於維基函數構建的摘要文章庫，並提供必要的平台功能，以便將來將摘要文章整合到維基百科中。
- 關鍵結果——維基體驗2.4：就維基數據關鍵應用場景所需技術基礎設施的改進成果，協調維基媒體基金會與維基媒體德國分會對成功標準的定義，包括涵蓋2025-2026財政年度的指標與目標。
- 維基媒體基金會維基數據平台（WDP）團隊於2025年8月成立並配備了一名產品負責人和一名技術負責人。作為維基媒體基金會與維基媒體德國分會中技術及產品負責人歷經多年開發的計畫新成員，此目標體現我們透過使用案例、依賴關係及關鍵成功標準的協作，逐步完成責任移交的意圖。本關鍵成果將奠定對問題領域的共同認知基礎，我們將在後續財政年度（至2026年5月）持續深化此基礎。
- 關鍵結果——維基體驗2.1：到第二季末，試驗並評估 3 項措施，幫助貢獻者改善其維基百科上重要內容的狀態。
消費者體驗 （維基體驗 3）
- 目標： 來自不同世代的讀者參與並保持與維基百科的互動，進而大幅增加維基百科的留存率與捐贈活動。
- 目標背景：該目標將重點透過創新的內容形式留住新讀者，透過加強熟悉的閱讀體驗留住核心讀者，並透過深化讀者聯繫和多樣化捐贈來確保長期的可持續性。這將包括我們繼續進行的工作，透過新的和更具實驗性的功能（例如人工智慧摘要或個人化的兔子洞）使內容更容易發現。這同時將包括在閱讀管道中更深入地保留和提高閱讀體驗品質的工作，以及透過閱讀清單和其他非編輯參與探索閱讀策劃。對於捐贈者來說，這項工作將繼續致力於從平台內部實現收入來源多樣化。
- 關鍵成果——維基體驗 3.1：到第二季末，透過對每個平台的一個功能進行A/B 測試衡量，可以顯著提高未有登入的讀者的保留率。
- 此關鍵成果將專注於繼續投資於改善瀏覽和學習內容新方式的體驗，通常透過使用新技術和格式——以新穎且引人入勝的方式呈現現有內容。在這個財政年度，我們希望繼續嘗試新功能，同時致力於在維基和平台上擴展成功的實驗。 關鍵成果的工作將涵蓋行動和桌面網站以及 iOS 和 Android 應用程序，並專注於內容發現（瀏覽入口點和推薦）和適應性學習格式（機器輔助摘要、內容混合）。
- 願望清單重點領域：新的消費者體驗
- 關鍵成果——維基體驗3.2：透過產品介入措施促進更深的聯繫並減少捐贈者的摩擦，到第二季末，透過非橫幅或電子郵件方式捐贈的數量同比增長5%
- 透過此關鍵成果，我們將繼續探索捐贈的新切入點和其他機會，將讀者轉化為捐贈者，並透過加深他們與維基的聯繫來留住他們，包括提供更多個人化內容。此關鍵成果將與籌款團隊合作，專注於引入新的切入點，並迭代應用程式和網路上現有的切入點。
- 關鍵成果——維基體驗 3.3：到第二季末，透過對每個平台的一個功能進行A/B 測試衡量，可以顯著提高未有登入的讀者的保留率。
- 此關鍵成果將專注於改善現有和有經驗的讀者閱讀和學習體驗，目標是留住我們現有的讀者並加深他們與網站的聯繫，以便他們可以了解更多信息，並準備好並願意走上捐贈和編輯的道路。這裡的工作將專注於改善網路和應用程式上的閱讀體驗（可讀性改進、更好的導航和發現），以及建立和迭代我們的策展和個人化產品（閱讀清單、個人化建議、用戶和文章歷史記錄等）。
- 關鍵結果——維基體驗 3.4：到第四季末，消除所有已確定的阻礙小規模快取站點部署（PoP）的因素，使其符合我們目前的快取站點部署的服務品質和安全標準。
- 此關鍵成果將重點證明這樣一個概念：我們可以透過簡化快取基礎設施和改進快取站點部署流程來提高網站效能並減少讀者的延遲，將基線部署時間從平均約一年縮短至最多四分之一。這裡的重點是完成簡化、部署系統一致性點、進行安全審查並完成是否繼續在公有雲端中部署我們的邊緣快取的決策簡要。降低延遲可以顯著增加頁面瀏覽量並擴大讀者群的地理分佈。
- 關鍵結果——維基體驗3.5：在第四季末以前改善捐贈者辨認措施，確保所有登入讀者經同意可藉由捐贈者地位辨別，以提升個人體驗。
- 我們將執行捐贈者辨識策略，確保所有登入讀者經同意可藉由捐贈者地位辨別，以量身打造深入的個人體驗。我們在第四季間將優先從事捐贈者識別工作，以加強支援未來個人化及活化措施。
- 關鍵結果——維基體驗3.6：在第四季末之前完成、發佈和傳達維基百科讀者和消費者跨平台體驗策略，並與利害關係人和社群合作制定明確的目標和基準指標，以指導我們到 2030 年的工作。
- 消費者策略工作將繼續進行，重點是內部和社群建構和溝通該策略，並定義和建立消費者的核心指標及其各自的基線。
- 目標背景：該目標將重點透過創新的內容形式留住新讀者，透過加強熟悉的閱讀體驗留住核心讀者，並透過深化讀者聯繫和多樣化捐贈來確保長期的可持續性。這將包括我們繼續進行的工作，透過新的和更具實驗性的功能（例如人工智慧摘要或個人化的兔子洞）使內容更容易發現。這同時將包括在閱讀管道中更深入地保留和提高閱讀體驗品質的工作，以及透過閱讀清單和其他非編輯參與探索閱讀策劃。對於捐贈者來說，這項工作將繼續致力於從平台內部實現收入來源多樣化。
信任與安全 （維基體驗 4）
- 目標：我們的系統預設更好地保護編輯者的帳戶和私人信息，同時為編輯者和具有擴展權限的用戶提供更多途徑來防止和應對濫用行為。
- 關鍵成果——維基體驗 4.1：在第二季末之前，在我們所有的維基媒體專案上部署一個可行且有效的事件報告系統，該系統將被其社群使用和接受。
- 確保使用者的安全和福祉是我們平台的基本責任。許多司法管轄區均有法律法規要求像我們這樣的線上平台監控並採取行動，打擊其平台上的騷擾、網路霸凌和其他有害內容。如果不能解決這些問題，平台可能會面臨法律責任和監管制裁。
- 我們希望賦予使用者權力，讓他們能夠透過容易發現且直覺式的回報機制，回報即時的傷害威脅，以確保我們能夠瞭解此類事件，並在必要時立即採取行動。這是讓我們的使用者在平台上貢獻時感到安全的一步。我們正在維基上實施事件回報系統。
- 關鍵結果——維基體驗4.2：透過在第二季末之前部署兩項改進措施，加強反濫用工具的精確度和有效性。
- 我們和我們的社群需要更好地偵測和預防維基媒體專案上的虛假和惡意活動。我們將透過增加平台可用訊號的數量和品質來實現這一目標，將這些訊號整合到我們為擁有擴展權限的使用者提供的工具中，並確定哪些地方可以安全地對可疑活動進行自動限制。
- 我們看到了同時改善維基百科和我們其他專案的可讀性的機會。舉例來說，其中一個專案是要用風險評分服務取代維基百科非常傳統的自我管理式 CAPTCHA (用戶在解開謎題之前無法登入)——該驗證碼會阻止用戶登錄，直到他們解答謎題。取而代之的是，這會默默地標記一個可疑程度的帳號，以便我們禁用相關功能，並將此狀態提供給高權限的管理員，以協助他們開展工作。
- 一般而言，維基媒體專案嚴重依賴 IP 位址封鎖來減少惡意使用者的濫用。這在阻止濫用方面越來越無效，並對受到 IP 和 IP 範圍封鎖影響的善意使用者造成負面影響。在本關鍵結果中，我們的目標是改善現有的功能，並提供新的工具，以更精確和更有效地封鎖惡意使用者，並減少 IP 和 IP 範圍封鎖所造成的附帶傷害。
- 為了衡量我們的成效，我們將檢視從事反濫用工作的志願者所提供的定性回饋，以及定量指標，例如 IP 封鎖的部署率、IP 聲譽和瀏覽器信號減緩措施的採用率、使用者被封鎖時可能與人類互動的比率，以及反濫用工具中新信號的採用率。
- 本關鍵結果的工作包括改進傀儡和禁令規避的偵測與減緩、顯示有關潛在附帶損害的資訊、加強機器人偵測、向反濫用志願者顯示訊號、改善反濫用工具介面的效率、改善與濫用相關的指標，並向 CheckUsers 提供可疑帳戶活動建議以供調查。
- 關鍵成果——維基體驗 4.3：到第四季末，將需要站點可靠性工程人工干預的大規模攻擊數量減少 50%（與上一財政年度同期相比）。
- 網路格局的演變，包括大規模殭屍網路的興起和更頻繁的攻擊，使得我們限制大規模濫用的傳統方法已經過時。此類攻擊會使我們的基礎設施被大量請求淹沒，從而導致我們的網站無法使用，或削弱我們社群應對大規模破壞行為的能力。這同時給我們的高權限編輯和技術社群帶來了不合理的壓力。
- 我們迫切需要提高自動偵測、抵禦、減輕或阻止此類攻擊的能力。
- 今年我們將主要致力於自動偵測經常對我們發動攻擊的 IP 位址和網絡，並減少那些持續有害實體對我們的系統造成的負載。
- 關鍵成果——維基成果 4.4：在我們所有的專案中部署臨時帳戶功能，這樣到第二季末，未有註冊編輯者的個人識別資訊將只有不到 0.1% 的註冊用戶可以看到。
- 臨時帳戶旨在保護未有註冊的編輯人員的隱私，從而提高他們的安全性——方法是將他們的個人識別資訊（IP 位址）隱藏起來，不讓公眾查看，並限制只有那些出於巡邏目的需要的管理人員才能存取。該專案除了對用戶安全有重大改進之外，對於遵守各種監管要求同時至關重要。
- 關鍵成果——維基體驗4.5：在第三季末之前，評估生成式人工智慧對信任和安全的影響，並確定產品介入措施，以利用機會並防止維基媒體專案面臨的威脅。
- 人工智慧（尤其是生成式人工智慧）在網路上的應用正在迅速成長。隨著人工智慧的普及，信任和安全方面既有機遇，也有威脅。例如，內容生成更容易和更便宜，但審核卻更費力。同樣，研究可以更輕鬆地進行，但人工智慧的幻像更難辨識。
- 該專案旨在透過評估人工智慧對維基媒體生態系統信任和安全的影響，在機器學習/人工智慧人權影響評估的基礎上進一步發展。具體內容包括：
- 與具有擴展權限的使用者進行協商。
- 識別生成性人工智慧輔助濫用的例子和潛在的緩解措施。
- 識別機器學習機會以減輕具有擴展權限的使用者的負擔。
- 進行實驗來了解我們應該關注的主題，以便產生最大的影響。
- 關鍵成果——維基體驗4.6：在技術上強制規定，在第四季結束前，只有啟用雙重因素驗證的帳號才能執行 100% 的權限，讓使用者能夠進行安全或隱私敏感的操作。
- 我們需要加強維基媒體專案用戶帳戶的安全性，尤其是擁有敏感權限的用戶。其中一項重點是要求任何敏感操作只能由啟用雙重認證（2FA）的使用者執行。我們將建構一個更具擴充性的權限執行系統，以繞過審核和手動執行雙重認證的需要，並擴展平台上需要啟用雙重認證的權限範圍。
- 作為其中的一部分，我們將改進我們的驗證和恢復系統，以便我們維基媒體基金會和我們的用戶可以更輕鬆地支持對雙重認證採取更嚴格的態度。我們將在整個平台上擴大雙重認證的普遍可用性，以便每位使用者均能按需要啟用，並確保在授予敏感權限之前啟用。我們同時將專注於降低帳戶復原和支援系統的作業負荷，協助簡化帳戶登入的重設和復原程序。我們進一步打算改善雙重認證實作的可用性，提供使用者更多的選項來保護他們的帳戶，避免意外鎖定。
負責任地使用基礎設施 （維基體驗 5）
- 目標：開發人員和重用者透過精選的途徑存取知識內容，確保我們基礎設施的可持續性和負責任的內容重用。
- 目標背景：此目標將重點放在建立負責任的內容重用途徑。
- 維基媒體擁有網路上最大的人工知識集合。這使得我們的知識基礎設施不僅對人類來說是一個無價的目的地，而且對自動數據消費者同時如此。我們的內容輸入到搜尋引擎、社群媒體平台、電子商務——並且自從人工智慧興起以來，就被用於訓練大型機器學習模式。消費者透過抓取頁面、使用應用程式介面和下載內容來取得資料——這通常未有註明來源。在未經身份驗證的流量世界中，我們無法可靠地區分一個用戶與另一個用戶，這極大地限制了我們實現和強制負責任地使用我們的基礎設施的能力：我們如何才能繼續支持我們的社群，同時為自動內容消費設定界限？我們如何將使用者引導至我們喜歡的並受支援的管道？我們需要什麼指導來鼓勵負責任的內容重複使用？我們如何推動實現有凝聚力的開發人員體驗，並建立滿足志願開發人員、員工和重複使用者需求的產品？雖然這些問題並不全是新問題，但解決這些問題的迫切性卻呈指數級增長：自 2024 年以來，我們觀察到請求量急劇增加，其中大部分增長來自於抓取機器人為人工智慧工作流程和產品收集訓練資料。我們的基礎設施負載是不可持續的，並使人類獲取知識面臨風險：我們現在需要採取行動，重新建立健康的平衡，這樣我們才能有效地支持維基媒體專案，並確保我們的使命持續成功。
- 關鍵成果——維基體驗 5.1：到第四季末，50% 的程式化存取管道請求可以歸因於已知的開發人員或應用程式。
- 目前，我們在識別誰對自動流量負責方面的方法有限，而且與維基不同，我們在聯絡使用者或規範其存取方面的方法同時有限。我們看到外部自動化流量顯著增加，這對我們來說是不可持續的，並且使人類獲取知識面臨風險。我們的目標是透過要求基於分層存取等級的身份驗證和授權來提高歸因於已知帳戶的自動流量的百分比，以實現對大量抓取和應用程式介面使用的控制。這將幫助我們識別誰在大規模重複使用內容，使我們能夠保護我們的基礎設施並改善公平使用治理，同時更有效地滿足他們的需求。我們同時將探索如何透過更具凝聚力的開發人員體驗來更好地支援技術社群，以保護社群成員的優先存取權並為開發人員提供新功能。
- 關鍵成果——維基體驗 5.2：到第四季末，70% 的維基媒體網絡應用程式介面端點將由通用基礎架構支援。
- 我們的目標是為所有維基媒體開發人員提供更一致、穩定和可發現的網絡應用程式介面，從而改善開發人員途徑的體驗和永續性。我們將透過為核心應用程式介面功能引入更集中的基礎設施來簡化我們的應用程式介面產品，讓我們在以下方面擁有一致的途徑和治理：開放應用程式介面規範和文件、開發人員識別和存取控制、應用程式介面策略實作、路由、版本控制和錯誤處理。透過簡化我們的應用程式介面產品，我們將更快、更輕鬆、更愉快地建立服務於維基媒體使命的工具、機器人、研究專案和功能。這種方法透過降低應用程式介面基礎設施維護成本、提高打擊不良行為者的可見性和存取控制以及培育更強大的開發者社群，以支援任務的多代未來。
- 關鍵成果——維基體驗5.3：到第四季度末，新的網頁、應用程式、語音助理和大型語言模型歸因框架將發佈並在維基媒體網站上分享連結，同時部署兩個可推動可衡量參與度的重用演示，並有一個外部重用合作夥伴採用最佳實踐歸因。
- 為了提高維基媒體內容的署名正確性，我們將提供清晰的最佳實踐指南，以促進負責任的再利用。這包括為關鍵平台（網頁、應用程式、語音、多媒體）建立署名框架，並展示至少兩個維基媒體內容的典型應用實例。例如，鼓勵媒體機構註明維基共享資源圖片的出處，促使搜尋引擎更有效地呈現相關的維基媒體數據，或讓人工智慧助理以透明且負責任的方式整合維基百科知識，從而提升其可靠性。加強署名實踐不僅可以提高公眾意識，引導用戶參與維基媒體專案，同時有助於建立負責任且創新的知識整合方式，並有效防止濫用。
- 關鍵成果——維基體驗 5.4：以請求率衡量，將抓取工具產生的流量減少 20%，以頻寬衡量，將抓取工具產生的流量減少 30%
- 抓取資訊一直存在：幾十年來，搜尋引擎一直依賴維基百科向用戶提供資訊；然而最近我們有了另一個巨大的動機來抓取我們的數據：這是您可以在互聯網上找到的最大的、經過精心策劃的多語言知識內容集，同時是訓練大型語言模型的基本工具——對於我們的百科全書內容和多媒體儲存庫維基共享資源來說，情況都是如此，這對於生成圖像的機器學習模型來說是無價的。
- 因此，在過去的一年裡，我們發現抓取工具的流量顯著增加，相關的站點穩定性事件同時顯著增加：站點可靠性工程師不得不逐案強制限制網路爬蟲的速率或反覆禁止網路爬蟲，以保護我們的基礎設施。抓取已變得如此突出，以至於我們的外寄頻寬在 2024 年增加了 50%。更重要的是，最近的一項分析顯示，我們最昂貴的請求（我們無法從快取伺服器提供服務，只能從主要資料庫提供服務的請求）中，至少有 65% 是由機器人執行的。
- 與我們產生的流量相比，我們的運算資源極為有限，因此我們必須優先考慮用這些資源為誰服務，我們希望有利於人類消費，並優先用我們稀缺的資源支持維基媒體計劃和貢獻者。
- 關鍵成果——維基體驗 5.1：到第四季末，50% 的程式化存取管道請求可以歸因於已知的開發人員或應用程式。
加速產品成果的實現 （維基體驗 6）
- 目標：維基媒體開發人員快速且自信地將他們的產品推向終端用戶。
- 目標背景：為了有效實現四大策略支柱，維基媒體開發人員需要將時間和精力花在高槓桿活動上，以便儘早交付高品質的產品。過於複雜的工作流程、缺乏標準工具以及不可持續的系統組件阻礙了這些結果。
- 這項工作建立在我們過去兩年的年度計劃勢頭之上，該計畫將 MediaWiki 發展為一個平台，並支援其開發和部署的軟體。今年的工作將重點放在提供更可靠的開發環境、簡化預生產工作流程以及降低平台和基礎設施風險。
- 關鍵成果——維基體驗 6.1：到第四季末，測試維基以外的連鎖阻礙漏洞數量減少10%。
- 2024年，有144次開發人員因為有緊急情況導致無法部署MediaWiki而不得不重新檢視工作。在其中的許多案例中，這些缺陷是在部署到 testwikis 之後才被發現的，這意味著問題可能會影響到數以億計的用戶。我們無法控制 缺陷存在的事實，但及早發現缺陷將意味著需要較少的善後工作。這同時會讓開發人員建立信心，相信當某些東西真正投入生產時不會發生意外。
- 我們將透過提供開發人員所需的環境來更早發現這些錯誤，以便開發人員在整個開發和部署生命週期中自信地交付和測試他們的程式碼。我們同時需要確保這些改進不會以犧牲開發人員的速度為代價。
- 關鍵成果——維基體驗 6.2：到第四季度末，無需站點可靠性工程干預即可執行生產準備審查清單中的 4 個步驟。
- 目前，在生產中部署新服務或功能取決於 24 個步驟，每個步驟通常均需要站點可靠性工程的支援。我們建立了站點可靠性工程大使計劃，以便在開發週期的早期進行干預並增強開發團隊本身的能力，但許多任務應該完全可以自助完成。目前，這相當於手動、重複、可自動化的工作，並且隨著開發團隊的數量線性擴展。從長遠來看，這對站點可靠性工程團隊來說是不可持續的。
- 過去，我們透過維護一套共用的共用函式庫和最佳實務，來與我們的平台互動，從開發團隊抽象出大部分的工作。當我們轉移到新的 Kubernetes 基礎架構時，這些東西就被放棄了，沒有直接的替代品。透過提供適用於今日建置與部署方式的類似程式庫、文件與訓練，我們相信可以減少站點可靠性工程在部署新服務或功能到生產之前所需的參與程度。
- 關鍵成果——維基體驗 6.3：到第四季末，100% 的維基百科頁面瀏覽量均透過 Parsoid 提供
- Parsoid 為維基文案的演進和平台的未來發展提供了增強的功能。從長遠來看，同時維護兩個解析器是不可持續的，因為這會增加技術債務和複雜性。此外，一些新專案（例如 「維基函數」 (Wikifunctions) ）的成功依賴於 Parsoid 的廣泛應用。
- 我們一直在擴大規模，向更小的專案推出此功能，今年我們將為維基百科做好準備。透過 Parsoid 提供所有維基百科頁面瀏覽量是下一個最重要的里程碑。除了推出此功能本身之外，這項工作同時包括解決效能問題並有效地向讀者和編輯傳達其影響。
- 關鍵成果——維基體驗 6.4：截至第二季末，至少兩個威脅我們繼續部署或擴展維基能力的已知風險已被緩解或降低到可接受的水平。
- 透過一些有針對性的舉措，我們將減少或減輕我們認為可能對我們的平台和公共專案的成長和永續性構成潛在威脅的幾個可擴展性、可靠性或安全性風險。
- 舉個例子，我們將重構維基共享資源核心資料庫的結構，以確保其成長在未來幾年內不會受到可用伺服器硬體容量的限制。我們同時將把支援 MediaWiki 和相關服務的程式語言 PHP 升級到更現代的版本。已發現的其他風險可能需要實施額外的安全措施來保護和加強我們的基礎設施。
- 關鍵成果——維基體驗 6.1：到第四季末，測試維基以外的連鎖阻礙漏洞數量減少10%。
信號和數據服務 （英文簡稱為：SDS）
指標 （信號和數據服務 1）
- 目標：決策者使用更多可信任和及時的指標來指導產品和策略決策。
- 目標背景：我們使用計量指標評估基金會應於何處集中精力，以為維基媒體運動提供最大幫助。不過，目前部分資料管道容易中斷，導致結果傳遞減緩，而我們識別並解決資料問題的時間則過長。此外，許多資料集不易用於分析趨勢，且缺乏用以解釋資料的重要特徵。前述問題使我們評估指標的能力及速度有所受限。
- 在2025至2026財政年度間，我們將重點關注流量指標，並作為案例研究，以解決我們當前管道中的數據品質差距，設置用於監控和解決數據品質問題的基礎設施和流程，並提供使決策者能夠了解人工和自動流量趨勢的工具。
- 其中一類用例，為辨別人類及機器人流量。近幾年來，自動流量與日俱增，頗干擾我們正常分析一般人如何貢獻維基媒體計畫站點並與之互動。我們希望能夠提升評估不同種類流量特徵的能力，以為關鍵計劃及產品決策所參考。
- 關鍵成果——信號和數據服務 1.1：到第一季末，使用頁面瀏覽量指標的分析師可以獲得資料品質的基準指標和自動流量偵測啟發式演算法的效能指標。
- 透過本關鍵成果中探討的假設，們的目標是找出目前自動流量偵測啟發式方法的不足之處，並瞭解這些方法在哪些地方無法正確分類頁面瀏覽流量。這些洞察力將有助於改善產生和分類頁面瀏覽量指標的管道。此外，我們將定義資料品質指標，以監控和衡量資料準確性的改善。
- 本關鍵成果將為後續關鍵成果奠定基礎，後續關鍵成果2重點關注實施此處確定的必要管道改進。此階段所建立的數據品質指標將作為評估未來增強效果的基準。
- 關鍵結果——信號和數據服務1.2：到第一季末，MediaWiki 內容歷史數據集的內容將透過檔案匯出方式提供，並保證每週交付一次（服務等級目標）。匯出的文件資料將與舊版 XML Dumps 1 匯出流程的資料完全一致。
- 上一財政年度計畫的關鍵結果1.4，旨在使最關鍵的3個下游管道不再仰賴每月更新的「mediawiki_wikitext_history」及「mediawiki_wikitext_history_current」資料集，並提供符合每週更新服務級別目標水準的替代資料集。
- 前述關鍵結果，雖緩解了若干最關鍵管道的有關問題，但其餘管道仍有仰賴不甚可靠的舊式輸入來源者。這些管道及過往Wikitext歷史資料集的檔案輸入來源亦應予以更新。
- 關鍵結果——信號和數據服務1.3：到第二季末，機器人偵測將新增一個訊號，並針對異常情況產生自動警報。
- 維基媒體基金會各團隊正依據能否區分人類讀者與自動化流量，來制定產品決策與資金分配方針。數據平台作為機器人偵測訊號與批次分析的核心儲存庫，我們計劃透過第一至第二季規劃的假設驗證，逐步導入新型機器人偵測訊號以精進自動化流量分析能力，並建立高效且可重複的新訊號導入流程。
- 關鍵結果——信號和數據服務1.4：到第二季末，決策者應該對我們組織指標所提供的洞察現狀有清晰的了解。如果我們能夠提供一份可用於維基媒體基金會理事會會議的演示文稿，將指標分析置於維基媒體生態系統以及更廣泛的互聯網市場趨勢和挑戰的背景下進行闡述，那麼我們就知道我們成功了。
- 我們從組織指標中獲得的洞察，被運用於維基媒體基金會各層面的決策，包括產品開發策略、基礎設施資源分配，以及募款方案的制定。與此同時，網路環境持續演變，自動化流量尤其影響著我們的指標數據。維基媒體基金會領導層的目標，是在十二月維基媒體基金會理事會會議前，透過對內部指標與外部趨勢的精準分析，提出關於維基媒體生態系統所面臨威脅與潛在機遇的清晰敘事。我們可透過彙整洞察、指標與數據點，確切闡述以下面向：
- 我們內部讀者數量（頁面瀏覽量）指標的趨勢
- 我們貢獻者生態系統的發展趨勢
- 來自外部數據和競爭對手基準的趨勢
- 來自內部和外部研究以及可靠研究的見解
- 我們從組織指標中獲得的洞察，被運用於維基媒體基金會各層面的決策，包括產品開發策略、基礎設施資源分配，以及募款方案的制定。與此同時，網路環境持續演變，自動化流量尤其影響著我們的指標數據。維基媒體基金會領導層的目標，是在十二月維基媒體基金會理事會會議前，透過對內部指標與外部趨勢的精準分析，提出關於維基媒體生態系統所面臨威脅與潛在機遇的清晰敘事。我們可透過彙整洞察、指標與數據點，確切闡述以下面向：
- 關鍵成果——信號和數據服務 1.1：到第一季末，使用頁面瀏覽量指標的分析師可以獲得資料品質的基準指標和自動流量偵測啟發式演算法的效能指標。
實驗平台（信號和數據服務 2）
- 目標：產品經理可以快速、輕鬆、自信地評估維基百科中產品功能變化的影響。
- 目標背景：為了實現並加速有關產品功能開發的數據知情決策，產品經理需要一個實驗平台，他們可以在其中定義功能、選擇用戶的處理受眾並查看影響測量。加快從發佈到分析的時間至關重要，因為縮短學習時間將加速實驗，並最終加速創新。手動任務和定制的測量方法被認為是速度的障礙。理想的情況是，產品經理從實驗啟動到發現，幾乎不需要或根本不需要工程師和分析師的人工干預。
- 下一財政年度我們將重點放在維基百科，因為這是核心體驗感興趣的實驗領域（組織策略讓我們加倍關注維基百科），而且這使我們能夠更清楚地關注和表明我們正在與哪些團隊和專案合作。其他團隊已經使用了實驗平台組件，並且可能繼續此工作，但這種使用並不是本目標的重點。
- 關鍵結果——信號和數據服務2.1：在第二季末以前，應用實驗平臺完成至少2次完整實驗循環。
- 在此一組織日漸重視以資料指導產品決策之際，我們應對所有產品團隊開放實驗，而非限定於特定技能範疇。產品團隊需要共享標準、工具及基礎設施，藉以：
- 以全域使用者為基礎迅速測試想法
- 以標準化指標測量產品變更影響
- 與運動利益相關者公開透明分享成果
- 為什麼我們將焦點由「賦能團隊數量」轉向「實驗完成數量」：
- 戰略協調：評估平臺是否成功的主要指標
- 以資料決策：我們的（現行）使用者研究指出，組織各團隊面對變化局勢應有所準備。此外，我們知悉網路團隊已有意參與兩類特定實驗。
- 最佳化資源：我們推出最簡可行產品平臺之際，相關方面上手需要充分接觸，以利於有效專注實驗機會，而非在多個團隊之間「撒網捕魚」。畢竟，我們目前計劃推進釋出正式版本，並不希望為重新訓練團隊而無謂投資。
- 聚焦未來：前述完整實驗循環的回饋結果，相較於此前部分或不完整的採用經驗，將更加有效幫助我們改善平臺。在釋出正式版本以前加緊完成實驗，可迴避投資於屆時需要額外重新開發的臨時手段。
- 我們正從事使用者研究，彙整各團隊需求；我們將於2025年5月下半舉行調查及訪談，以確定產品團隊具體需求。研究結束後，我們將製作實驗行事曆，用於設定關鍵結果目標及其優先順序。
- 在此一組織日漸重視以資料指導產品決策之際，我們應對所有產品團隊開放實驗，而非限定於特定技能範疇。產品團隊需要共享標準、工具及基礎設施，藉以：
- 關鍵結果——信號和數據服務2.1：在第二季末以前，應用實驗平臺完成至少2次完整實驗循環。
未來觀眾 （英文簡稱為：FA）
未來觀眾 (FA1)
- 目標：維基媒體基金會提出了有關策略投資的建議，以幫助我們維基媒體運動在不斷變化的互聯網中服務於新的受眾。
- 目標背景：由於技術和線上用戶行為的不斷變化（例如，用戶越來越傾向於透過社交應用程式獲取資訊、短影片教育娛樂的流行、生成式人工智慧的興起），維基媒體運動在吸引和留住讀者和貢獻者方面面臨挑戰。這些變化同時帶來了透過以新的方式創建和傳遞訊息來服務新受眾的機會。然而，作為一個運動，我們沒有一個基於數據的清晰圖像來了解我們可以採取的不同潛在策略的利益和權衡，以克服挑戰或抓住新機會。例如，我們應該...
- 投資聊天機器人等大型新功能嗎？
- 將維基媒體的知識和途徑為流行的第三方平台做出貢獻嗎？
- 其他主意？
- 為了確保維基媒體成為一個多世代的專案，我們將測試不同的假設，以更好地理解和推薦有前途的策略——對於維基媒體基金會和維基媒體運動——追求吸引和留住未來的讀者。
- 關鍵成果——未來觀眾 1.1： 作為未來聽眾實驗性洞察和建議的結果，在第三季度結束前，至少有一個由非未來聽眾團隊擁有的目標或關鍵結果出現在下一年度的年度計劃草案中。
- 自 2020 年起，維基媒體基金會一直在追蹤可能影響我們服務未來世代知識消費者與知識貢獻者的能力，並在未來世代維持蓬勃發展的自由知識運動的外部趨勢。未來聽眾（Future Audiences）是一個小型的研發團隊，將：
- 進行快速、有時限的實驗（目標是每個財政年度至少 3 次實驗），以探索應對這些趨勢的方法
- 根據從實驗中獲得的洞察力，對維基媒體聚會應該進行的新的非實驗性投資提出建議——即需要由一個或多個完整團隊負責的新產品或計劃——在我們的定期年度規劃期間進行。
- 如果下一個財政年度的年度計劃草案中至少出現一項由未來觀眾以外的團隊所擁有、並由未來觀眾建議所推動的目標或關鍵結果，則該關鍵結果將達成。
- 自 2020 年起，維基媒體基金會一直在追蹤可能影響我們服務未來世代知識消費者與知識貢獻者的能力，並在未來世代維持蓬勃發展的自由知識運動的外部趨勢。未來聽眾（Future Audiences）是一個小型的研發團隊，將：
- 關鍵成果——未來觀眾 1.1： 作為未來聽眾實驗性洞察和建議的結果，在第三季度結束前，至少有一個由非未來聽眾團隊擁有的目標或關鍵結果出現在下一年度的年度計劃草案中。
- 目標背景：由於技術和線上用戶行為的不斷變化（例如，用戶越來越傾向於透過社交應用程式獲取資訊、短影片教育娛樂的流行、生成式人工智慧的興起），維基媒體運動在吸引和留住讀者和貢獻者方面面臨挑戰。這些變化同時帶來了透過以新的方式創建和傳遞訊息來服務新受眾的機會。然而，作為一個運動，我們沒有一個基於數據的清晰圖像來了解我們可以採取的不同潛在策略的利益和權衡，以克服挑戰或抓住新機會。例如，我們應該...
社交影片 （未來觀眾2）
- 目標：年輕人（<25 歲）喜歡在他們喜歡上網的平台上學習、參與和分享維基百科內容。
- 目標背景：未來觀眾團隊在本財政年度進行的短片實驗顯示，我們可以在這些平台上大規模接觸較年輕的受眾，但我們的品牌健康數據顯示，我們目前的投資並不足以對抗 Z 世代受眾對維基百科認知與親和力的下降。
- 為了確保我們能有效接觸並吸引這一代觀眾，我們相信我們需要採取各種策略，並大幅提高我們在付費和影響力行銷、創意活動等領域的參與度，對趨勢做出反應，並提高我們在這些管道上的實驗水準。
- 我們預期我們面臨的挑戰將需要更大量的投資來協助我們克服，特別是在傳播與行銷方面，以創造參與度，以及跨部門合作創造新產品與體驗，以增加維基百科的品牌與內容在這些平台上的存在。
- 關鍵成果——未來觀眾 2.1：到上半年末，在所有自有頻道中透過短影片內容產生 9,500,000 次觀看次數。
- 今年，我們在 TikTok、Instagram 和 YouTube 上的 @Wikipedia 頻道推出短片後的 3 個月內，達到約 100 萬人次的瀏覽量。到下個財政年度開始時，我們預期自有頻道上會有更多的追隨者，同時會對有效/吸引人的內容有更多的了解，我們可以將這些內容付諸實行，以達到更多的觀眾。
- 透過在上半年設定一個雄心勃勃的目標，我們希望推動更大的影響，允許創建新的策略/流程來促進工作，並能夠倡導額外的資源來實現這一目標。
- 關鍵成果——未來觀眾 2.2：到2025/26財政年度結束（2026年6月），將我們在TikTok上的非平台追蹤者數從中等規模（10萬-25萬追蹤者）提升至宏觀規模（25萬-100萬追蹤者）。
- 我們目前處於TikTok中階追蹤者層級（10萬至25萬追蹤者），目標是在2025/26財政年度結束前（2026年6月）晉升至宏觀層級（25萬至100萬追蹤者）。這三個層級——微型、中型與宏觀——是業界衡量受眾規模與觸及率的標準指標。為達成此目標，我們將改善內容策略以更有效吸引Z世代追蹤者，並透過社群管理提升整體能見度。上半年表現將作為下半年策略調整的依據，以加速成長並達成此里程碑。
- 關鍵成果——未來觀眾 2.3： 針對未來受眾的新學習/媒體消費方式，推出平台外產品，並透過合作的產品品牌與行銷活動將其推向市場。
- 未來觀眾團隊通常進行小規模實驗，並進行最少/有機的營銷。今年，我們希望預留一些時間，針對平台外更年輕的受眾，推出更大規模的新產品和行銷活動。
- 關鍵成果——未來觀眾 2.1：到上半年末，在所有自有頻道中透過短影片內容產生 9,500,000 次觀看次數。
產品和工程支援 （英文簡稱為：PES）
產品和工程支援 (PES1)
- 目標：由於流程的改進，維基媒體基金會產品和工程團隊的效率更高，從而促進了我們文化的積極轉變。
- 目標背景：此目標是讓維基媒體基金會的工作方式更快速、更聰明、更好。這一切都與我們的運作方式有關。這意味著流程中的摩擦和障礙（低效率和錯誤）更少，並且更快地產生影響。此目標同時涉及學習可在整個部門和組織中採用的工作方式。
- 關鍵成果——產品和工程支援 1.1：到第二季度末，根據優先級排序標準為 6 項生產服務定義服務級別目標，旨在最大限度地學習如何定義和使用服務級別目標，以便利益相關者團隊就可靠性相關工作的優先級做出明智的決策。
- 服務級別目標 (SLO) 是利害關係人團隊之間就服務目標水準（可靠性/效能）達成的協議，團隊透過合作來達到該目標（但不能大幅超出該目標）。例如，這有助於確定開發團隊何時應優先考慮或降低可靠性或效能工作的優先級，或什麼會造成問題。團隊需要關心識別哪些是緊急事件（警報/事件回應/關鍵錯誤）以及哪些不是。目標是透過協商目標和告知共享且明確的優先順序來減少跨職能部門的摩擦。
- 關鍵成果——產品和工程支援 1.2：到第二季末，社群訊號（包括願望清單）已經影響維基媒體基金會為第三季至第四季確定至少 5 個產品工作流程的優先順序。
- 我們的目標是識別和慶祝團隊根據以實證為基礎的社群要求來排定工作優先順序的情況。
- 本計劃中的兩個假設專門針對願望清單。這旨在增強信任、簡化流程並提高員工和志志願者的參與度。另一個假設是進行一項實驗，旨在檢驗互助客棧等設施是否收集到足夠多的有價值訊號，以及人工智慧能否支援我們訊號收集的能力。
- 關鍵成果——產品和工程支援 1.3：維基媒體基金會將兩個早期跨部門實驗納入年度計劃，這些實驗由我們的外部消費者、捐贈者和貢獻者受眾驗證。
- 這項工作是為了創建實驗和實驗流程，以供我們整個組織採用。
- 維基媒體基金會將兩個經過驗證的早期實驗納入其年度計劃，加強了跨部門實驗的文化。該計劃促進了產品和技術部門功能團隊以外的合作，鼓勵與組織內其他部門（如通訊和發展部門）進行更多創新。透過植入未經測試的新想法並簡化實驗流程，團隊可以提高生產力並擴大影響力。成功的衡量標準是每年完成兩次跨部門實驗，將其整合到未來的目標與關鍵結果工作中，並增加實驗實踐的採用。產出的例子包括用於提高新編輯者成長和生產力的新原型，以及用於加深讀者和捐贈者與維基百科聯繫的實驗性功能。確定的一個具體機會是連接小功能探索以慶祝維基百科成立 25 週年。
- 關鍵成果——產品和工程支援 1.1：到第二季度末，根據優先級排序標準為 6 項生產服務定義服務級別目標，旨在最大限度地學習如何定義和使用服務級別目標，以便利益相關者團隊就可靠性相關工作的優先級做出明智的決策。
- 目標背景：此目標是讓維基媒體基金會的工作方式更快速、更聰明、更好。這一切都與我們的運作方式有關。這意味著流程中的摩擦和障礙（低效率和錯誤）更少，並且更快地產生影響。此目標同時涉及學習可在整個部門和組織中採用的工作方式。
假設
第一季
維基媒體基金會年度計劃的第一季(Q1)涵蓋七月至九月。
| 維基體驗（英文簡稱為：WE）假設
[ 維基體驗關鍵結果 ] | ||
|---|---|---|
| 假設簡稱 | 第一季文字內容 | 細節與討論 |
| WE1.1.1 | 如果我們提示新加入的志願者從外部網站貼上文字以確認他們是否編寫了他們試圖添加的內容，那麼我們將看到新加入的志願者發佈的新內容編輯的百分比下降≥10％，這些編輯因 WP:COPYVIO（和相關政策）而被撤銷。 | |
| WE1.1.2 | 如果我們提供「改進語氣」建議編輯的初始測試版本，那麼我們就可以了解這種新格式的建議編輯是否是一種有意義的方案，可以增加新貢獻者的建設性編輯，而不會增加巡邏者/審查者的審核負擔。 | |
| WE1.1.3 | 如果我們在視覺化編輯器（行動 + 桌面）中部署一個針對高級貢獻者的新建議模式作為測試版本功能，其中包含 ≥ 3 個新的編輯建議，我們將發現在透過受控實驗評估新志願者的體驗之前需要進行哪些調整（如果有的話）。 | |
| WE1.1.4 | 如果我們透過受控實驗在英語維基媒體專案上部署參考檢查，我們將看到新志願者發佈的建設性編輯增加≥10%，並了解巡邏員和管理員是否有足夠的支持以更廣泛地啟用該功能。 | |
| WE1.1.5 | 如果我們透過新成員的設計原型測試進度系統，那麼我們就可以確定哪些類型的里程碑、指導和認可被認為最能激勵人心，並利用這些見解來完成未來試驗維基實驗的設計。 | |
| WE1.1.6 | 如果我們透過使用者研究和數據分析來調查行動網路編輯的最大技術、社會和行為障礙和推動因素，我們將產生至少三個可行的見解，以彌補關鍵的知識差距並增強我們自信地優先考慮財政年度 25/26 下半年及以後的產品投資能力。 | |
| WE1.2.1 | 如果我們建立一個在維基媒體專案上顯示協作貢獻資料的概念證明，我們可以收集至少 30 位貢獻者的回饋，其中 70% 的受訪者表示該功能很有用，並且有助於推動協作成長。 | |
| WE1.3.1 | 如果我們利用先前的研究和設計中確定的需求，並分享最具影響力的 X 個管理模組的早期模型，我們就可以與他們一起修改審核操作的主頁。 | |
| WE1.3.2 | 如果我們修改新成員首頁來有條件地呈現管理模組，那麼我們就可以證明管理員使用該頁面的可行性。 | |
| WE1.4.1 | 如果我們實施T396489中提到的一系列改進，大型維基媒體專案上緩慢的最近更改查詢將減少 X%。這樣，管理員工具就能在這些維基媒體專案上部署主頁模組，而無需擔心資料庫效能問題。 | T400696 |
| WE2.1.1 | 如果我們透過其所在地區高流量維基百科上的中央公告橫幅邀請小型維基的母語人士為建議編輯和其他成長功能做出貢獻，我們可以評估這種方法是否吸引了新的母語人士，以及他們是否使用這些編輯工具來改進重要內容。 | |
| WE2.1.2 | 如果我們開發並發佈針對新編輯的翻譯建議，那麼我們就能測試這種方法是否比我們目前的方法產生更好的翻譯結果。
這解決了新編輯面臨的已知挑戰，他們更有可能被刪除文章。透過引導他們翻譯更易於管理的內容，我們的目標是提供一個更簡潔、更易於理解的翻譯流程介紹。優秀的候選文章和章節在格式和整體長度方面可能看起來不太複雜。 |
|
| WE2.1.3 | 如果我們了解編輯者在創建新文章和新章節時的體驗（包括動機、痛點以及他們對如何更好地支持他們的新想法的反應），那麼我們將發現用戶的需求和行為，從而提供可行的見解和策略，為產品、設計和工程提供信息，以改善文章創作的體驗。 | |
| WE2.1.4 | 如果我們透過參與式研討會或訪談來探索三個中型維基百科如何處理知識差距和重要性，我們將發現與每個社區相關的「重要知識」的工作定義或框架概念。 | |
| WE2.2.1 | 如果我們遵循 Parsoid 的推出並將「維基函數」 (Wikifunctions) 整合到大多數維基詞典和一些低流量維基百科中，我們將獲得所需的測試，以便自信地將其推廣到更大的維基媒體專案。 | |
| WE2.2.2 | 如果我們啟用「維基函數」 (Wikifunctions) 來輸出 HTML 表格、樣式和連結，我們將透過顯示動詞變位表的函數來證明其除了簡單轉換之外在維基詞典上生成淨新知識的能力。 | |
| WE2.2.3 | 如果我們在嵌入式函數呼叫中新增對維基數據實體的支持，我們將啟用 200 多個新函數，這些函數可以使用維基數據實體產生全面的句子，使函數更容易在維基媒體專案中使用。 | |
| WE2.2.4 | 如果我們制定「抽象維基媒體專案」內容的存放位置及其與維基百科互動的架構計劃，我們將更準備好實施「抽象維基百科」平台，以增加高品質百科全書內容的提供。 | |
| WE2.2.5 | 如果我們在產品和技術團隊之間定義和交流「抽象維基百科」內容所需引用的產品需求，我們將能夠推動跨維基媒體的工作，提供附加在「抽象維基百科」內容上的出處信息，這對於在維基上成功應用至關重要。 | |
| WE2.2.6 | 如果我們使後端內部請求格式更具表現力和簡潔性，我們可以提高系統的穩定性，從而支援更廣泛的推廣。 | |
| WE2.2.7 | 如果我們使用維基數據和「維基函數」 (Wikifunctions) 呼叫來產生自然語言片段，提供原型片段，我們將表明該專案已準備就緒，並準備好用這來訓練人工智慧，這樣人類就不必過多考慮功能。 | |
| WE2.2.8 | 如果我們提供帶有限定字符的維基數據語句的導入，就有可能產生多層面的事實（不僅需要主題/詞彙/值來表達的事實），這包括維基數據中估計 50% 的百科全書內容。 | |
| WE2.2.9 | 如果我們提供檢索到的維基數據實體的緩存，我們將使基於維基數據內容的功能的平均運行時間減少至少 50%，從而減少逾時和使用者的挫折感。 | |
| WE2.2.10 | 如果我們在「維基函數」 (Wikifunctions) 使用者介面中提供維基數據詞素感知元件，那麼貢獻者將能夠識別和選擇相關的詞素，而無需離開平台/「維基函數」 (Wikifunctions) ，從而減少上下文切換並能夠更快並更成功地創建與語言相關的功能。 | |
| WE2.2.11 | 如果我們解決達巴尼語社群關於維基百科上的「維基函數」 (Wikifunctions) 整合的可用性問題，我們會發現編輯者在測試期間將功能插入文章時遇到的關鍵可用性問題較少或為零。 | |
| WE3.1.1 | 如果我們在 IOS 應用程式上對標籤式瀏覽功能的改進版本進行 A/B 測試，我們會看到標籤式瀏覽功能的多日使用率增加 5%。 | |
| WE3.1.3 | 如果我們為用戶提供一種新的方式，讓他們可以瀏覽文章頁面內的相關圖片或影片內容，我們將看到使用此功能的用戶的點擊率至少達到 3%。 | |
| WE3.1.4 | 如果我們向讀者展示幾個用於遍歷維基上的知識網絡的概念，我們將得出一個優先概念列表，以供進一步開發。 | |
| WE3.1.5 | 如果我們提供網路讀者一個選項，讓他們可以檢視其語言版本無法使用的維基百科內容的機器翻譯版本，我們就可以了解閱讀活動是否增加，以頁面互動增加 3% 來衡量，將讀者吸引到當地語言的維基百科，並可能增加當地的編輯活動。這將以控制 A/B 測試的方式進行，測試時間不超過 6 個月，並在事先取得同意的情況下，在 13 個維基百科中使用維基百科編輯人員已可使用的開放式機器翻譯服務。 | |
| WE3.2.1 | 如果我們與籌款部門合作，我們將根據用戶測試結果，在 iOS 版本年度回顧中開發更具吸引力、更整合、更個性化的捐贈者幻燈片。我們將在第二季進行一項假設，評估改進後的年度回顧的捐款金額是否比 2024 年的年度回顧高出 5%。 | |
| WE3.2.2 | 如果我們提示非活動市場的 Android 應用程式讀者，根據他們對維基百科的使用情況，設定可選、可自訂 (金額與頻率) 的捐款提醒，我們就會看到這些市場的 App 選單捐款增加 5%。 | |
| WE3.2.3 | 如果我們對未有登入的使用者進行 A/B 測試實驗，以顯示行動端和桌面端捐贈入口點的微妙變體，我們會觀察到透過處理路徑進行捐款的人數比對照高出 2%。 | |
| WE3.3.1 | 如果我們將 2024 年 iOS 應用程式用戶要求的中低難度個人化元素加入到 2025 年的年度回顧中，透過可用性測試或測試版本，我們會發現滿意度比去年增加了 3%。 | |
| WE3.3.2 | 如果我們將 Android 應用程式上現有的「編輯」標籤擴展為個人化的活動中心，其中包括閱讀和非編輯參與的洞察，我們會發現與原始版本相比，該標籤的多日參與度增加了 5%。 | |
| WE3.3.3 | 如果我們在 Android 應用程式中為帳號持有人推出至少一個可解鎖的頭像 (透過有意義的讀者動作賺取，如儲存一定數量的文章)，我們將可在多天內將登入使用者重複參與相關動作的比例提高 10%。 | |
| WE3.3.4 | 如果我們允許已登入的讀者將文章保存到私人閱讀列表，我們預計網站的參與度將會增加，以使用該功能的讀者的內部推薦流量增加 5% 來衡量，並且所有用戶的參與度都會有顯著的增加。 | |
| WE3.3.5 | 如果我們進行一項使用者研究，允許網路讀者從維基百科收集/整理內容，那麼至少 10% 的參與者會將兩種或更多不同類型的內容（例如文章、摘錄、媒體）保存到一個集合中。 | |
| WE3.4.1 | 如果我們致力於混合存取點/內容傳遞網路部署，這將允許我們根據需要啟動完整的存取點和迷你存取點（實體和雲端），為未來的原型迷你存取點部署奠定基礎。 | |
| WE3.6.1 | 如果我們對未有登入的用戶保留率進行 A/A 測試，我們將為未來幾季使用的保留率建立基準。 | |
| WE3.6.2 | 如果我們建立並發佈已登入讀者的定義，我們將能夠在與維基體驗 3.3 關鍵目標相關的所有團隊和假設中使用此定義。 | |
| WE3.6.3 | 如果我們讓社群參與討論讀者不斷變化的需求以及互聯網上知識的變化性質，我們就可以共同關注如何為讀者服務，並共同研究是否以及如何測試我們的各種想法（包括那些圍繞多媒體、搜尋與發現，以及機器學習的想法）。 | |
| WE3.6.4 | 如果我們研究讀者何時、為何以及如何使用維基百科和其他知識平台背後的不同動機、行為和需求，我們將獲得可用於指導和發展我們的消費者策略的發現。 | |
| WE4.1.1 | 如果我們製作一個最小可行的非緊急流程的原型，並在與具有擴展權限的使用者一起開發這個原型時保持開放的迭代反饋循環，那麼這些群組將能支援該流程的擴展部署。 | Project page |
| WE4.2.1 | 如果我們將與建立帳號相關的 hCaptcha 風險等級顯示給可信賴的功能人員，就能減少識別不良行為者所需的時間，並增加偵測到平台上建立的不良行為者帳號的次數。我們可以透過檢視應用於帳號的封鎖率、hCaptcha 風險等級與封鎖帳號的一致性，以及功能人員的定性回饋，來衡量這項假設是否成功。 | |
| WE4.2.2 | 如果我們產生建議調查供 CheckUsers 跟進，我們就會看到識別不良帳戶所需的時間減少，而識別出的不良帳戶數量增加。當我們看到「建議調查」功能的定期使用率、透過建議調查所識別帳戶的減緩措施增加，以及定性調查回饋，我們就知道我們成功了。 | |
| WE4.2.3 | 如果我們分析來自 hCaptcha 帳戶創建試驗的數據，我們將了解帳戶創建管道、hCaptcha 謎題和分數的有效性，並獲得必要的數據來進一步推出 hCaptcha 帳戶創建功能。 | |
| WE4.2.4 | 如果我們在所有維基媒體專案上部署用戶資訊卡，我們將使管理員能夠更有效地識別和緩解不良行為者帳戶。 | Project page |
| WE4.2.5 | 如果我們進行研究、諮詢社群並調查技術解決方案，我們將能夠定義一組可在所有維基媒體基金會維基媒體專案中使用的結構化封鎖原因。 | |
| WE4.2.6 | 如果我們開發出在資料平台上部署以開放搜尋為基礎的叢集能力，那麼產品功能工程團隊將獲授權開發整合此能力的系統，並擁有極大的自主性、彈性以及與其他以搜尋為基礎的系統的隔離。此系統的第一個主要租戶將是 IPoid 服務。 | |
| WE4.2.7 | 如果我們在幾個維基百科上部署 hCaptcha 企業版整合作為試驗，我們將能夠收集 hCaptcha 企業版在反濫用、機器人偵測、可用性和可及性方面的功效和價值的數據。 | |
| WE4.3.1 | 如果我們將對新的 Edge Uniques cookie 的支援整合到 requestctl（我們用於 站點可靠性工程 對抗濫用的邊緣規則引擎）中，我們將能夠更好地防禦分散式阻斷服務攻擊和內容重複使用。 | |
| WE4.4.1 | 如果我們能夠根據試點的回饋做出改進，並將臨時帳戶部署到所有專案，我們將能夠保護所有專案中未有註冊用戶的個人識別資訊（IP 位址），使其僅向不到 0.1％ 的所有（已註冊）用戶開放。 | Project page |
| WE4.4.2 | 如果我們及時、清楚地與相關維基媒體運動利害關係者（包括維基社群和全球管理員）進行溝通，我們將能夠在所有剩餘的維基媒體專案上進行部署，減少最後一刻發現的工作量，並避免回滾部署。 | |
| WE4.4.3 | 如果我們讓巡邏員更輕鬆地根據臨時帳戶的 IP 位址過濾操作並查看臨時帳戶的活動，那麼我們將能夠成功地將臨時帳戶功能推廣到所有維基媒體專案。 | |
| WE4.4.4 | 如果我們允許根據 IP 顯示存取政策撤銷臨時帳戶 IP 顯示存取權限，並在更多地方展示該功能，那麼我們將能夠成功將臨時帳戶功能推廣到所有維基媒體專案。 | |
| WE4.5.1 | 如果我們進行定性研究來確定產生人工智慧輔助的不良行為者的濫用範例（例如垃圾郵件、騷擾、長期濫用者、未公開的付費編輯或虛假宣傳活動），我們將能夠評估我們的社群模式的風險並產生減輕不同類型的產生人工智慧輔助濫用的想法。 | |
| WE4.6.1 | 如果我們在 Zendesk 中實現密碼重設的同步帳戶流程自動化，這將減輕信任與安全團隊的負擔，並使他們能夠處理更多的多重要素驗證重設請求。 | |
| WE4.6.2 | 如果我們支持並鼓勵用戶註冊多個身份驗證因素，啟用雙重認證的用戶就不太可能將自己鎖定在帳戶之外。 | |
| WE4.6.3 | 如果我們允許所有擁有已確認電子郵件地址的使用者為其帳戶啟用雙重認證，但不主動向使用者宣傳此更改，我們的復原支援服務台負載量將維持在可持續的水平。 | |
| WE5.1.1 | 如果我們對經過驗證的會話和匿名會話使用不同的儲存後端，我們將能夠保護 Sessionstore 免受分散式阻斷服務攻擊和高容量抓取工具的侵害，因為不會因為在身份驗證頁面上建立匿名會話以提供跨站請求偽造預防而使其過載。 | T398814 |
| WE5.1.2 | 如果我們將 MediaWiki 會話 cookie 變更為具有加密簽章的結構化格式，我們將能夠使用會話的存在作為防禦抓取工具的因素，透過以高效能和高度可擴展的方式在邊緣啟用會話的可信任驗證。 | T398815 |
| WE5.1.3 | 如果我們使用基於 Kubernetes 的本機開發環境為應用程式介面閘道建立速率限制解決方案，我們將能夠透過比較至少三種不同速率限制服務的效能和功能來確定使用生產流量進行測試的最佳選項。 | T398913 |
| WE5.2.1 | 如果我們重新設計 REST 應用程式沙盒使用者介面以更好地滿足開發人員的資訊需求，我們將提高文件的清晰度，這已透過可用性測試得到驗證。 | |
| WE5.2.2 | 如果我們透過中央網關路由所有低於rest.php的應用程式介面，我們將解鎖集中式應用程式介面管理的手段，並可以開始持續測量 REST 應用程式介面流量和使用模式，以獲得可為未來決策和行動提供參考的見解。 | |
| WE5.2.3 | 如果我們為 MediaWiki REST 應用程式介面實作監控儀表板和警報，那麼我們可能會展示一種可持續、有用且可複製的方法來提高我們系統行為的可見性並更快地發現問題，特別是在關鍵修改期間。 | |
| WE5.3.1 | 如果我們在更新任何現有指導方針的同時，擴大並簡化使用者體驗署名指導方針，我們將可建立一套經改良的核心指導方針，隨時準備進行內部測試與迭代改進，以準備供更廣泛的大眾使用。 | |
| WE5.3.2 | 如果我們創建一個宣傳，展示將維基百科歸因於第三方內容重用者及其最終用戶的好處，我們可以透過讓至少一個額外的重用合作夥伴同意在第一季末出現在歸因案例研究或演示中來支持 WME4.1 和 WME4.2。 | |
| WE5.4.1 | 如果我們確保大多數網路請求都獲得邊緣唯一 cookie，那麼識別機器人和偽造請求將變得更加容易。 | |
| WE5.4.2 | 如果我們建立了可擴充的方式來識別已知用戶端，我們就可以允許經過驗證的機器人在一般速率限制上有例外，並且邁向有系統地執行我們的規則。 | |
| WE5.4.3 | 如果我們圍繞允許清單/拒絕清單方法重新組織內容傳遞網路上的文字請求過濾，我們可以對機器人實施更嚴格的一般速率限制並簡化流量過濾。 | |
| WE5.4.4 | 如果我們制定統一的測量策略，我們將能夠評估「負責任地使用基礎設施」的多年期策略，並定義指導指標開發和報告能力的路線圖。 | |
| WE6.1.1 | 如果我們將每日映像建置重新安置到部署伺服器並新增由選擇部署作業觸發的映像更新，我們將發現限制並為執行更連續部署所需的時間建立基準。 | |
| WE6.1.3 | 如果我們將 wikifarms 添加到合併前測試環境中，這將使開發團隊能夠針對生產進行構建，他們需要多個維基媒體專案來單獨測試他們的補丁，從而為他們提供更大的預生產信心，並減少缺陷逃逸。 | |
| WE6.2.1 | 如果我們審查並發佈生產就緒清單，明確定義服務被視為生產就緒的先決條件以及可自助服務的任務，我們將協調站點可靠性工程和開發團隊之間的期望，從而提高我們的整體營運效率和可擴展性。 | |
| WE6.2.2 | 如果我們宣布創建一個 Golang 和 nodejs 函式庫，為開發人員抽像出許多繁重的任務，他們將會提供回饋和興趣。 | |
| WE6.2.3 | 如果我們建立清單/工作表，開發人員可以提前充分準備資料持久性設計審查。 | |
| WE6.3.1 | 如果我們在第一季推出至少 70 個低流量維基百科（不包括支援語言變體的維基媒體專案），我們將對最終推出前 10 個維基媒體專案充滿信心，這將對透過 Parsoid 提供的頁面瀏覽量產生更大的影響。 | |
| WE6.4.1 | 如果我們在自己的叢集中部署維基共享資源的分割連結表，我們將增加維基共享資源的資料庫成長維持永續性的機會。 | T398709 |
| WE6.4.2 | 如果我們（站點可靠性工程）為 MediaWiki 工程團隊提供協助——透過創建文件、準備必要的基礎設施（例如 PHP 、容器鏡像）以及提供指導和審查——他們將能夠在第二季度初自信地啟動生產 PHP 8.3 升級。 | T360995 |
| WE6.4.3 | 如果我們要求具有提升的系統權限的使用者使用實體第二因素（硬體安全金鑰）進行安全殼層協定登錄，我們將降低受感染筆記型電腦造成嚴重安全漏洞的風險。 | |
| WE6.4.4 | 如果我們透過統一域名，將所有 MediaWiki 網站的頁面瀏覽量都集中到一個規範域名上，那麼我們將透過消除行動子域名稱重新導向來降低平台複雜性並減少搜尋引擎最佳化(SEO)風險。完成情況的衡量標準是：規範網域上行動存取的重新導向率從 100% 降至 0%。 | T214998 |
| WE6.4.5 | If the MediaWiki Engineering Team actively monitor and fix issues in MediaWiki related to the PHP 8.3 upgrade, the SRE team will be unblocked to proceed with the PHP 8.3 upgrade by the start of Q2. | T360995 |
| 信號和數據服務（英文簡稱為：SDS）假設
[ 信號和數據服務關鍵結果 ] | ||
|---|---|---|
| 假設簡稱 | 第一季文字內容 | 細節與討論 |
| SDS1.1.1 | 如果我們分析自動流量偵測啟發式技術在我們的頁面瀏覽量資料集中的功效，我們將能夠發展資料品質指標來描述其效能，並決定是否需要進一步投資在這些啟發式技術上。 | |
| SDS1.2.2 | 如果我們將 XML Dumps 流程從目前的「Dumps 1」基礎架構遷移到利用 MediaWiki 內容管道的資料管道，我們將能夠保證服務等級目標並關閉基於「Dumps 1」的 XML 匯出。 | |
| SDS1.2.3 | 如果我們對 MediaWiki 內容歷史和活動平台的服務等級目標進行一次演練和檢閱，我們就可以驗證消費者、度量指標和依賴的利害關係人，並找出服務等級目標可能需要的改進，這將有助於我們釐清每周交付保證中的任何缺口。 | |
| SDS2.1.1 | 如果我們與執行實驗的團隊密切配合，就能瞭解未來如何讓系統更自助，以及他們可能會遇到概念或技術上的挑戰。 | |
| SDS2.1.2 | 如果我們能夠為事件日誌實現更好的調試，那麼產品團隊就會知道他們的實驗正在按預期收集事件數據，從而增加實驗所有者的信心。 | |
| SDS2.1.3 | 如果我們改進實驗平台的 A/B 測試系統 (xLab) 元件及其相關 MediaWiki 部分的日誌記錄和可觀察性，我們將能夠為系統效能建立基準並對與實驗相關的故障做出反應。 | |
| SDS2.1.4 | 如果我們每月一次在整個組織內分享實驗故事和結果（透過產品營運會議、設計團隊會議和跨團隊演示），那麼我們將創造實驗平台的有機採用。 | |
| SDS2.1.5 | 如果我們告訴使用者，他們的儀器 (如果是在 xLab 中建立的) 包含一組會改變風險類別的屬性，我們就能阻止儀器使用者過度收集資料，並提高屬性組合需要隱私權審查的清晰度。 | |
| 未來讀者（英文簡稱為：FA）假設
[ 未來讀者關鍵結果 ] | ||
|---|---|---|
| 假設簡稱 | 第一季文字內容 | 細節與討論 |
| FA1.1.1 | 如果我們 1）為其他平台（如 Letterboxd、Goodreads 和 RateMyMusic）上的媒體收藏者提供方法，利用維基百科獨有的知識來增強他們的收藏，或 2）為這些媒體收藏者提供有趣的社交媒體共享內容，那麼我們將能夠增加維基百科在平台外的影響力。 | |
| FA2.1.1 | 果我們在第一季建立內部創建短片內容的能力（透過擴大團隊規模以及審核和識別提高當前生產流程效率的機會），我們將能夠根據財政年度 2024-2025 創建的內容的經驗採取行動，並實現財政年度 2025-2026 第二季度所製作內容的同比覆蓋率更高。 | |
| 產品和工程支援（英文簡稱為：PES）假設
[ 產品和工程支援關鍵結果 ] | ||
|---|---|---|
| 假設簡稱 | 第一季文字內容 | 細節與討論 |
| PES1.1.1 | 如果我們支援 xLab、Charts 和 ToneCheck 為 Prometheus 中的服務等級指標定義指標，並在 Pyrra 上加入這些 服務等級目標，我們將了解我們的工具在多個複雜場景中的限制和極端情況，並明確指出服務等級目標模板需要哪些迭代，這將幫助我們的 6 個迭代模型。 | |
| PES1.1.2 | 如果我們試用兩套服務等級目標警報儀表板，就能了解實施合適的工具，讓服務所有者清楚了解他們的承諾有多難，以及是否需要遷移到其他僅提供特定服務等級目標單一視圖的工具。一套儀表板將用於季度報告（其中設定了錯誤預算的實際服務等級協定），另一套規模較小的動態儀表板（稱為「滾動」）用於日常營運和警告。 | |
| PES1.1.3 | 如果我們繼續支援抽象維基百科 (Abstract Wikipedia) 小組為維基函數(Wikifunctions) 專案起草服務等級目標，我們將學習如何為目前正在新增至關鍵使用者工作流程的複雜功能——即算繪維基文章——定義一系列服務等級目標（以及其的服務等級指標）。我們同時將學習如何使用站點可靠性工程提供的儀表板和監視器，正確地視覺化相關的錯誤預算並發出警報。 | |
| PES1.1.4 | 如果我們支援資料平台群組對 MediaWiki 內容歷史專案的服務等級目標進行審查和迭代，我們將學習如何在批次和串流處理服務組合在一起更新資料集時利用服務等級目標來支援服務所有權，使其保持一致並可供下游使用者使用。 | |
| PES1.2.1 | 如果我們對願望清單進行 3 項有針對性的改進，那麼我們將鼓勵願望清單中的獨立參與者增加 30%。 | |
| PES1.2.2 | 如果我們對收到的願望進行分類並在 72 小時內指派一名維護者（例如產品經理）（包括拒絕、澄清、標記未維護的服務等），透過將新願望與維護者表進行交叉引用，並將「維護者類別」分配給最相關的產品團隊或個人參與者，維護者（例如產品經理）將能夠在 10 天或更短的時間內評估並回應願望。 | |
| PES1.2.3 | 如果我們試行辨識整個社群訊號的工作，我們將在社群知情的優先排序工作中納入更多志願者的聲音。 | |
| PES1.2.4 | 如果我們在第一季與 3 個團隊試行季度願望和社群訊號審查流程，我們將讓產品經理將社群訊號整合到他們的季度和年度計劃流程中。 | |
| PES1.3.1 | 如果到第一季末，我們能夠與傳播部門和產品團隊協調 3 次功能規劃會議，以協調維基百科二十五週年慶祝計劃的資訊傳遞、創意需求和活動時間表，那麼我們將最終確定所有 3 個活動實驗（25YiR、復活節彩蛋、WikiRun）的創意簡報。 | |
| PES1.3.2 | 如果我們建立一個由設計和功能工程代表組成的指導委員會，我們將能夠定義關於 Codex 貢獻的基準指標：知名度、使用情況、貢獻品質和數量。透過評估這些基準指標，我們將能夠制定路線圖，以促進 Codex 貢獻者群體的共同成長和多元化。 | |
第二季
維基媒體基金會年度計劃的第二季(Q2)涵蓋十月至十二月。
| 維基體驗（英文簡稱為：WE）假設
[ 維基體驗關鍵結果 ] | ||
|---|---|---|
| 假設簡稱 | 第二季文字內容 | 細節與討論 |
| WE1.1.1 | 如果在貼上檢查(Paste Check) A/B 測試開始後 ≥2 週分析一組預先確定的領先指標，我們便能辨識端到端體驗中哪些面向（若有）需要調整或深入探究，方能確信評估該功能的影響。 | |
| WE1.1.4 | 如果我們透過受控實驗在英語維基媒體專案上部署參考文獻檢查功能，我們將看到新志願者發佈的建設性編輯增加≥4%，並了解巡邏員和管理員是否有足夠的支持以更廣泛地啟用該功能。 | |
| WE1.1.7 | 如果在語調檢查(Tone Check) A/B 測試開始後 ≥2 週分析一組預先確定的領先指標，我們便能辨識端到端體驗中哪些面向（若有）需要調整或深入探究，方能確信評估該功能的影響。 | |
| WE1.1.8 | 如果我們把語調檢查模型應用於已發表的文章，我們將了解我們是否能夠識別出至少 10,000 個語調問題（每個問題的機率得分為 0.8 或更高），從而構建一個高品質（準確率 ≥ 70%）的建議庫，以幫助指導編輯改進文章的語調。 | |
| WE1.1.10 | 若我們能訪談約十位在英語維基百科與法語維基百科撰寫濫用過濾器（以及其他小工具／腳本／模板／編輯通知）以自動化巡查／審核工作流程的資深志願者，將能歸納出≥3種模式／需求，這些發現將有助於形塑由社群共同編寫的編輯檢查工具的核心價值主張。 | |
| WE1.1.11 | 若我們向≥500名成功的新手[i]發放問卷調查，並取得能代表更廣泛成功新手群體的高品質數據，我們將能識別出≥4項可執行的洞察，藉此釐清應優先改善哪些加入體驗環節。 | |
| WE1.1.12 | 如果我們能讓≥3名志願者各自評估≥30篇樣本編輯，針對我們計劃擴展語調檢查(Tone Check) 功能的10種新語言，我們將能掌握志願者與模型預測結果的吻合頻率，進而決定應向哪些新維基媒體專案推廣部署語調檢查功能。 | |
| WE1.1.13 | 鑑於我們將「添加連結」功能擴展到英文維基百科 100% 的新志願者，那麼新志願者的建設性激活和留存率將會提高，這將使新志願者的建設性編輯數量增加 ≥4%。 | |
| WE1.2.3 | 如果取消中小型維基媒體專案使用活動註冊功能時需具備活動主辦者權限的要求，則本財政年度結束前，中小型維基媒體專案上新增的活動數量至少將增加 X 場*。
|
|
| WE1.2.4 | 如果我們對協作貢獻最簡可行產品進行迭代並至少實現兩項改進，那麼將透過活動註冊工具產生更多協作機會。 | |
| WE1.2.5 | 如果我們在第二季初為維基共享資源上的活動註冊工具制定採用策略，我們將能夠與至少一個大型活動的組織者進行測試，並使五個本地組織者能夠使用該功能。 | |
| WE1.3.3 | 如果我們發起一項實驗，向新編輯展示管理員控制面板，那麼 10% 的貢獻者會連續兩週存取該控制面板。 | |
| WE1.4.1 | 若實施T396489中定義的改進方案，我們將使大型維基站點的近期變更查詢速度至少提升30%，此舉將使社群技術團隊得以部署監視清單標籤功能，同時避免近期變更資料庫超載。 | |
| WE1.4.3 | 如果我們對最近的更改和監視清單進行監控，那麼我們就可以確定人們點擊頁面的頻率基準。 | |
| WE1.5.1 | 如果我們實作一個儀表板來探索七個貢獻者指標，並使用資料建構工具標準化至少一個指標的計算，那麼我們就可以讓貢獻者產品團隊自助獲取指標見解，並制定儲存指標計算邏輯的標準。 | |
| WE1.5.2 | 若我們能在第二季確定哪些管理措施應納入「管理員」的定義範疇，那麼維基媒體運動洞察團隊便能在第三季/第四季建立「每月活躍管理員」的衡量指標。 | |
| WE2.1.3 | 如果我們了解編輯者在創建新文章和新章節時的體驗（包括動機、痛點以及他們對如何更好地支持他們的新想法的反應），那麼我們將發現用戶的需求和行為，從而提供可行的見解和策略，為產品、設計和工程提供信息，以改善文章創作的體驗。 | |
| WE2.2.12 | 如果我們把維基函數推廣到啟用了 Parsoid 的維基媒體專案，我們就可以繼續測試該系統在越來越廣泛的推廣中是否仍然具有效能和可用性。 | |
| WE2.2.13 | 如果我們向維基詞典社群宣傳詞形變化表功能的可用性，我們將能獲得寶貴的使用反饋，並深入了解使用者角色，這些洞察可應用於未來的功能推出。 | |
| WE2.2.14 | 如果我們研究社群在利用維基數據製作資訊框方面的資料框工作，並調查維基函數是否能有所幫助，我們就能確定維基函數在資訊框中的第一個實驗。 | |
| WE2.2.15 | 若我們能提升社群對在維基函數上建立與翻譯錯誤訊息能力的認知，我們將看到更多實用的錯誤訊息出現。 | |
| WE2.2.16 | 如果我們向社群演示可用的語義功能，我們將看到語法功能增加 50%。 | |
| WE2.2.17 | 如果我們提供一個自訂元件來查看維基函數上的維基數據語句，使用者將能夠更好地理解從維基數據獲取的數據，並且不會感到不知所措。 | |
| WE2.2.18 | 如果我們能夠防止記憶體消耗峰值達到 10 倍，協調器將能夠更好地處理維基數據的項目，從而強化維基函數作為抽象維基百科平台的實用性。 | |
| WE2.2.19 | 若我們允許使用者分享指向特定函數呼叫的直接連結——包含其輸入參數——貢獻者將能更輕鬆地重現、驗證及討論函數行為，進而加速除錯流程、改善測試工作流程，並促進維基函數社群的協作式問題解決。 | |
| WE2.3.1 | 如果我們最終決定創建一個新的維基媒體專案，並與社群一起確定名稱，我們將能夠更廣泛地與我們的利益相關者宣傳這個新維基媒體專案的創建，並為潛在的產品名稱變更的後勤工作做好準備。 | |
| WE2.3.2 | 如果我們為抽象維基原型定義一個最簡可行產品，其中包含測試後端和自然語言生成功能所需的最基本體驗，並允許我們進行迭代設計，那麼我們將能夠在第三季度規劃並推出即時原型。 | |
| WE2.3.3 | 如果我們開始與社群溝通，探索抽象維基使用者體驗的潛在設計，我們就能在第三季繼續推進相關工作。 | |
| WE2.4.1 | 如果我們從維基媒體德國分會和維基媒體基金會團隊收集維基數據和維基數據查詢服務的使用案例，我們將能夠定義基礎設施改進的產品需求。 | |
| WE2.4.2 | 如果我們針對維基數據和維基數據查詢服務產生關鍵績效指標 (KPI) 與現有服務等級目標 (SLO) 的匯總報告視圖，我們將能夠闡明和追蹤支援關鍵維基數據用例的技術基礎設施改進的成功標準。 | |
| WE2.4.3 | 若我們能在本季度內，採用貼近實際生產環境的標準對Blazegraph的替代方案進行評估與基準測試，便能依據數據做出遷移決策，並制定出包含具體時程與資源需求的明確實施路線圖。 | |
| WE3.1.1 | 如果我們對改良版的分頁瀏覽功能進行A/B測試，將在分頁用戶群中觀察到跨日使用率提升5%。 | |
| WE3.1.3 | 如果我們為用戶提供一種在文章頁面內瀏覽相關圖片內容的新方式，並透過A/B測試在若干維基站點上對部分未登入讀者進行測試，我們將觀察到：在接觸此功能的使用者群體中，點擊率至少達到3%。 | |
| WE3.1.4 | 如果我們向讀者展示幾種在維基媒體專案上瀏覽知識網絡的概念，我們就能得到一個包括優先考慮項目的概念列表，以便進一步開發。 | |
| WE3.1.5 | 如果我們為網路讀者提供查看維基百科內容的機器翻譯版本選項，我們將了解閱讀量是否增加（以頁面互動量增加3%為衡量標準），從而吸引讀者前往當地語言維基百科，，並可能帶動當地編輯活動增長。這項測試將以受控的A/B測試形式進行，測試時間不超過6個月，並在事先徵得同意的情況下，在13個維基百科版本中開展，使用維基百科編輯者已可使用的開放式機器翻譯服務。 | |
| WE3.1.6 | 如果我們製作一個語義搜尋和內文問答功能打造原型，並以演示介面呈現現行方案與新探索方案的對比，讀者團隊將能夠定性地評估每種方法在不同使用者旅程中的表現，並發現差距或進一步迭代的機會。 | |
| WE3.1.7 | 如果我們回顧現有關於讀者如何與維基百科上的搜尋和導航工具互動，以及他們如何使用外部搜尋在維基百科上尋找知識的研究，我們將能夠為讀者團隊提供 ≥3 項可操作的建議和發現，幫助他們確定搜尋和發現最簡可行產品的範圍，以解決讀者期望和需求方面的差距。 | |
| WE3.1.8 | 如果我們與外部參與者一起評估兩個語義搜尋原型（自然語言搜尋、問答），我們可以了解使用者是否認為改進的搜尋工具有價值，並為讀者團隊提供如何推進搜尋和發現最簡可行產品的建議。 | |
| WE3.1.9 | 若我們在質性研究中向10至20位維基百科的非專業讀者展示透過語義搜尋實現內容探索的高保真設計概念，將能觀察到使用者對此功能的正面評價，並獲得足夠信心推進搜尋與探索最簡可行產品的開發——該產品將採用由人類撰寫的簡短摘要作為搜尋查詢的基礎。 | |
| WE3.1.10 | 如果我們在非監督式使用者研究中，向十位非專業讀者展示新版圖片瀏覽體驗的即時原型，至少能為該功能的未來迭代版本挖掘出一項使用者體驗改善方案。 | |
| WE3.1.11 | 如果我們放寬搜尋中關鍵字的配對要求，那麼我們就能更好地支援自然語言查詢，並使產品團隊能夠評估這項功能，將其納入語義搜尋領域的設計、優先排序和交付工作中。 | |
| WE3.2.5 | 如果我們在 Android 應用程式上推出「年度回顧」功能，突出用戶影響並包含整合的捐贈者訊息，我們將推動新的捐贈行為——與 2024 年相比，我們將看到應用程式中的捐贈增加 5%。 | |
| WE3.2.6 | 如果我們讓 iOS 年度回顧中的捐贈者投影片更加整合、更加個人化，與 2024 年相比，我們將看到捐款金額增加 5%。 | |
| WE3.3.3 | 如果我們在 Android 應用程式中為帳號持有人推出至少一個可解鎖的頭像 (透過有意義的讀者動作賺取，如儲存一定數量的文章)，我們將可在多天內將登入使用者重複參與相關動作的比例提高 10%。 | |
| WE3.3.4 | 如果我們允許已登入的讀者將文章保存到私人閱讀清單中，我們預計網站的參與度將會提高，這體現在使用此功能的讀者內部轉介流量增加5%，以及所有用戶在統計上顯著增加。 | |
| WE3.3.6 | 如果我們能透過符合既定擴展性與可用性要求之服務提供文章主題推論數據，並配合必要的數據補全機制，便將為未來依賴此數據的個人化讀者體驗奠定必要技術基礎。 | |
| WE3.3.7 | 如果我們利用數據平台的處理能力來聚合定制的編輯指標和影響數據，並透過具有已定義服務級別目標的合適服務來提供聚合數據，我們就可以增強維基體驗 3.3.1 「年度回顧」和維基體驗 3.3.2 「活動標籤」的未來迭代版本。 | |
| WE3.3.9 | 如果我們在 Android 應用程式上發佈「年度回顧」功能，並進行 A/B 測試，向保存自訂閱讀清單的用戶提供獎勵，我們將看到獲得獎勵的用戶的整體應用程式留存率比未獲得獎勵的用戶高出 1%。 | |
| WE3.3.10 | 如果我們進行 A/B 測試，要求用戶註冊帳戶才能查看年度回顧的個人化閱讀見解，與無需註冊帳戶的用戶相比，需要註冊帳戶的用戶的整體留存率將提高 1%。 | |
| WE3.3.11 | 如果我們對 iOS 上「活動」標籤的改進版本進行 A/B 測試，該版本突出顯示閱讀、編輯和其他參與行為，我們將看到已登入讀者對該標籤的多日訪問量比原型版本增加 5%。 | |
| WE3.4.1 | 如果我們致力於混合存取點/內容傳遞網路部署，這將允許我們根據需要啟動完整的存取點和迷你存取點（實體和雲端），為未來的原型迷你存取點部署奠定基礎。 | |
| WE3.5.1 | 如果產品與技術團隊和籌款團隊能夠攜手合作，評估並記錄在我們平台上識別捐贈者的技術方案，我們將能夠推薦一個兼顧隱私、可行性和影響力的短期和長期解決方案。這種共識將有助於統一決策，實現跨平台持續的捐贈者識別，並為未來籌款相關功能的更有針對性的實驗奠定基礎。 | |
| WE3.6.3 | 如果我們能與社群展開對話，探討讀者不斷演變的需求，以及網路知識形態的變遷，便能凝聚共識聚焦於如何服務讀者，並共同商討是否及如何驗證各項構想（包括多媒體應用、搜尋與發現機制，以及機器學習等領域的創新方案）。 | |
| WE3.6.4 | 如果我們深入研究讀者使用維基百科及其他知識平台時，背後所蘊含的獨特動機、行為模式與需求——包括使用時機、原因及方式——便能為消費者策略提出優先發展領域與具體行動方案。 | |
| WE3.6.5 | 如果產品與技術團隊及募款團隊能共同制定策略，以多元化平台捐款管道、培育並表彰捐款讀者為目標，我們將確立明確且相互呼應的目標與衡量指標，並將其與消費者策略及募款策略緊密連結。 | |
| WE3.6.6 | 如果我們制定統一的衡量策略，將能評估消費者的多年期策略，並制定路線圖以引導指標開發與報告能力。 | |
| WE4.1.1 | 如果我們製作一個最小可行的非緊急流程的原型，並在與具有擴展權限的使用者一起開發這個原型時保持開放的迭代反饋循環，那麼這些群組將能支援該流程的擴展部署。 | |
| WE4.1.3 | 如果我們在 10 月底之前更新 7 個維基百科（法語、德語、西班牙語、匈牙利語、義大利語、波蘭語、葡萄牙語），我們將完成新法律頁腳推廣的第一階段，以回應《數位服務法案》的要求。 | |
| WE4.1.4 | 如果我們把事件報告系統最簡可行產品部署到至少 15 個維基站點，並聚焦於規模較大且複雜的社群，我們將觀察到該系統被社群依預期用途使用，並將成功驗證出適用於非緊急事件通報的運作模式。 | |
| WE4.1.5 | 如果我們為尚未建立濫用處理流程的維基媒體專案設計一套濫用事件通報流程圖，此舉將促使這些維基媒體專案採用事件通報系統，並讓使用者獲得清晰且可行的支援途徑。 | |
| WE4.2.3 | 如果我們分析來自 hCaptcha 帳戶創建試驗的數據，我們將了解帳戶創建管道、hCaptcha 謎題和分數的有效性，並獲得必要的數據來進一步推出 hCaptcha 帳戶創建功能。 | |
| WE4.2.5 | 如果我們進行研究、諮詢社群並探索技術解決方案，便能定義一套結構化的區塊理由，使其適用於所有維基媒體基金會的維基站點。 | |
| WE4.2.6 | 如果我們開發出在資料平台上部署以開放搜尋為基礎的叢集能力，那麼產品功能工程團隊將獲授權開發整合此能力的系統，並擁有極大的自主性、彈性以及與其他以搜尋為基礎的系統的隔離。此系統的第一個主要租戶將是 IPoid 服務。 | |
| WE4.2.7 | 如果我們在幾個維基百科上部署 hCaptcha 企業版整合作為試驗，我們將能夠收集 hCaptcha 企業版在反濫用、機器人偵測、可用性和可及性方面的功效和價值的數據。 | |
| WE4.2.8 | 若我們透過提升可用性與可觀察性，使 hCaptcha 代理系統達到生產環境就緒狀態，將於第一季為維基百科生產環境提供更穩定可靠的服務。 | |
| WE4.2.9 | 若將 hCaptcha 軟體開發套件整合至原生行動應用程式，評估原生應用程式的使用者體驗，並評估將 hCaptcha 驗證機制納入帳戶建立應用程式開發介面的可行性，我們將能充分掌握相關資訊，為後續在帳戶建立應用程式開發介面中全面推行 hCaptcha 奠定基礎。 | |
| WE4.2.11 | 如果我們在風險較高的編輯場景中啟用 hCaptcha 來偵測機器人，我們會發現 hCaptcha 可以減少自動化濫用行為。 | |
| WE4.2.16 | 如果我們與相關的維基媒體基金會團隊進行磋商，我們將能制定出經各方同意的方案，用以管理用戶對非公開資料的更細緻存取權限，並支援部署非公開的防禦性軟體規則。 | |
| WE4.2.17 | 如果我們透過分析真實案例並訪談查驗用戶，從編輯歷史原型中識別出至少兩項潛在濫用行為的警示訊號，產品安全與整合團隊便能於後續將這些訊號整合至「建議調查」功能中，並對這些訊號能創造價值抱持更高程度的信心。 | |
| WE4.3.2 | 如果部署JA4H指紋技術（該技術可彙總HTTP客戶端行為），我們將能更有效地識別並分類機器人流量。 | |
| WE4.4.1 | 如果我們能夠根據試點專案的回饋進行改進，並在所有專案中部署臨時帳戶功能，我們將能夠保護所有專案中未註冊使用者的個人識別資訊（IP 位址）的洩露，使其僅對不到 0.1% 的（已註冊）使用者可見。 | |
| WE4.4.2 | 如果我們能與相關運動利益相關者（包括維基社群與全球職能人員）保持清晰且及時的溝通，便能順利在所有剩餘維基站點部署更新、減少臨時發現的工作量，並避免回滾部署。 | |
| WE4.4.5 | 若能降低巡邏員識別惡意行為者的操作門檻——這些人正利用臨時帳號進行破壞行為——我們便能透過監測所有啟用臨時帳號的維基站點，確保還原率未見上升，從而有效遏止破壞行為的增長。 | |
| WE4.4.6 | 若我們終止 LiquidThreads 擴充功能，將解除對臨時帳戶的限制，使其能部署至所有目前使用此擴充功能的專案。 | |
| WE4.6.1 | 如果我們在 Zendesk 中實現密碼重設的同步帳戶流程自動化，這將減輕信任與安全團隊的負擔，並使他們能夠處理更多的多重要素驗證重設請求。 | |
| WE4.6.3 | 如果我們允許所有擁有已確認電子郵件地址的使用者為其帳戶啟用雙重認證，但不主動向使用者宣傳此更改，我們的復原支援服務台負載量將維持在可持續的水平。 | |
| WE4.6.4 | 如果我們持續對雙重驗證系統進行使用者體驗全面升級，並新增通行密鑰支援功能，將有更多使用者註冊多重驗證因素，從而獲得更完善的帳戶存取權保護機制。 | |
| WE4.6.5 | 如果我們設計並建構一套通用框架，用以規範地方性或全球性團體成員必須滿足的要求，我們將運用此框架來確保臨時帳戶IP檢視者群組的成員符合現有政策要求。 | |
| WE4.6.6 | 若我們研究擁有擴展權限的使用者（UWER）如何依賴使用者腳本，便能提出一項計劃——此計劃可獲得擁有擴展權限的使用者社群支持——藉此實施一項或多項重大技術干預措施，從而有效強化使用者腳本系統的安全性。 | |
| WE4.6.7 | 如果我們評估原生行動應用程式所需的用戶體驗與技術變更，以透過探索 OAuth 等替代機制使行動登入體驗與網頁平台保持一致，便能判斷整合的可行性，從而為用戶提供更安全且一致的使用體驗。 | |
| WE4.6.8 | 如果我們監測第一季建置的 Zendesk 與 MediaWiki 表單所產生的影響，便能為未來季度提出技術性介入方案，藉此更完善地自動化執行帳戶恢復流程的其餘環節。 | |
| WE5.1.2b | 如果我們在應用程式開發介面閘道中整合多種開發者識別與驗證方法，便能透過精準辨識來自不同用戶群組的請求，為每項請求設定適當的速率限制。 | |
| WE5.1.3b | 如果我們在 REST 閘道的至少 3 條路由上執行速率限制的模擬測試，將能驗證速率限制在資源消耗方面的可行性，並定義一套可實施的初始限制值，在最小化用戶影響的前提下執行管控。 | |
| WE5.1.4b | 如果我們能運用更廣泛的數據集驗證所提出的應用程式開發介面用戶分群機制，並對識別出的群組進行人工審查，便能最終確定用戶群組、改善計算方法，並更深入理解其效能。 | |
| WE5.1.5 | 如果我們與MediaWiki平台團隊合作進行流量識別與速率限制，將能透過協助平台團隊建立並推出此功能，在生產環境中部署速率限制以進行模擬測試。 | |
| WE5.2.1b | 如果我們能與新推出的 REST API Explorer 的潛在使用者互動，將有助於我們找出關鍵的使用者體驗洞察，這些洞察能顯示新設計是否易於使用，以及是否符合開發人員的思維模式。 | |
| WE5.2.2b | 若將行動應用程式開發介面導向中央應用程式開發介面閘道，我們便能開始持續監測流量與使用模式，藉此獲取洞察，為未來的決策與行動提供依據。 | |
| WE5.2.4 | 如果若我們為兩個應用程式開發介面實作標準文件範本，將能完善內容準則、釐清應用程式開發介面擁有者採用準則所需的條件，並量化在維基媒體其餘應用程式開發介面文件中實施準則所需的投入。 | |
| WE5.2.5 | 若我們嘗試為MediaWiki REST API定義並應用OpenAPI規格的語法檢查規則，將能展示一種透過程式化方式強制執行應用程式開發介面風格指南的方法，從而提升維基媒體基金會及其社群所發布應用程式開發介面的品質與一致性。 | |
| WE5.3.1 | 如果我們在擴充與精簡使用者體驗歸因準則的同時更新現有規範，便能建立一套核心的優化準則，可立即投入內部測試並透過反覆精進，為更廣泛的公開應用做好準備。 | |
| WE5.3.1b | 若我們發布並反覆修訂使用者體驗指南草案與示範版本，便能建立核心框架，使其具備內部測試與迭代改善的條件，為更廣泛的公開應用做好準備。 | |
| WE5.3.2 | 如果我們製作一份提案，展示將維基百科署名於第三方內容重用者及其最終用戶的好處，我們就可以通過促使至少一個額外的重用合作夥伴同意在第一季末出現在署名案例研究或演示中來支持 WME4.1 和 WME4.2。 | |
| WE5.4.2b | 如果我們建立可擴展的機制來識別已知客戶，便能對來源經核實的機器人開放一般速率限制的例外情況，並逐步邁向規則的系統化執行。 | |
| WE5.4.5 | 如果我們開始對不同類型的客戶實施量身定制的速率限制，我們將減輕網路爬蟲對我們基礎設施的負擔。 | |
| WE5.4.6 | 如果在第二季結束前，我們已將排名前N名的爬蟲程式歸類為已知機器人，我們就可以限制它們使用的資源量。 | |
| WE5.4.7 | 如果我們在媒體基礎架構上確立一套標準化的允許縮圖尺寸集，並預先生成耗費資源最多的尺寸，同時對不同圖像尺寸的生成實施速率限制，便能有效減輕媒體服務基礎架構的負擔。 | |
| WE6.1.2 | 如果我們將 wikifarms 添加到合併前測試環境中，這將使開發團隊能夠針對生產進行構建，他們需要多個維基媒體專案來單獨測試他們的補丁，從而為他們提供更大的預生產信心，並減少缺陷逃逸。 | |
| WE6.2.1 | 如果我們審查並發佈生產準備清單，明確定義服務被視為生產就緒的先決條件以及可自助完成的任務，我們將統一網站可靠性工程和開發團隊之間的期望，從而提高我們的整體營運效率和可擴展性。 | |
| WE6.2.2 | 如果我們宣布創建一個 Golang 和 nodejs 函式庫，為開發人員抽像出許多繁重的任務，他們將會提供回饋和興趣。 | |
| WE6.2.4 | 如果我們應用並積極支持資料持久性設計的審查，我們可能會找到通往生產的鋪平道路。 | |
| WE6.3.2 | 如果我們能開發新指標、強化Parsoid的快取基礎架構，並在兩個「十大」維基百科站點部署，便能為信心框架建立效能準則。此舉不僅有助驗證我們是否具備部署至其他大型維基站點的準備度，更能展現我們處理大規模高流量負載的能力。 | |
| WE6.3.3 | 如果我們能在第二季實施關鍵的語言變體支援改進措施，並成功將Parsoid部署至至少三個語言的維基百科，我們將能識別並解決關鍵技術挑戰，從而能有信心將其推廣至所有其他語言的維基百科。 | |
| WE6.4.6 | 如果網站可靠性工程團隊能透過以下方式協助 MediaWiki 工程團隊——包括進行容量與流量管理、準備及審查配置變更，以及協同調查與排除問題——我們將共同於第二季完成 PHP 8.3 的生產環境升級，並制定一套建議方案，以減少未來升級對網站可靠性工程團隊關鍵路徑依賴性。 | T360995 |
| WE6.4.7 | 如果我們能將至少90%具備全球根權限的使用者遷移至使用硬體支援的SSH金鑰存取維基媒體生產伺服器，我們將降低筆記型電腦被入侵導致嚴重安全漏洞的風險。 | |
| WE6.4.8 | 如果 MediaWiki 工程團隊積極監控並修復 MediaWiki 中與 PHP 升級相關的問題，這將使網站可靠性工程團隊團隊能夠在 2025 年 11 月之前完成生產環境的 PHP 8.3 升級。 | T360995 |
| 信號和數據服務（英文簡稱為：SDS）假設
[ 信號和數據服務關鍵結果 ] | ||
|---|---|---|
| 假設簡稱 | 第二季文字內容 | 細節與討論 |
| SDS1.2.1 | 如果我們將 XML Dumps 流程從目前的「Dumps 1」基礎架構遷移到利用 MediaWiki 內容管道的資料管道，我們將能夠保證服務等級目標並關閉基於「Dumps 1」的 XML 匯出。 | |
| SDS1.2.2 | 我們進行走查並檢視MediaWiki內容歷史紀錄與活動平台／活動閘門的服務層級目標，便能驗證相關客戶、衡量指標及依賴方，同時找出服務層級目標可能需要改進之處，這將有助釐清我們每週交付保證中的任何缺口。 | |
| SDS1.3.1 | 如果我們引入客戶端訊號並將其與伺服器端的網頁請求日誌進行比對審核，便能發現更多可被歸類的機器人行為模式。 | |
| SDS1.3.2 | 如果我們以當前機器人與人類的流量分布作為基準線，並針對分布變化建立自動化警示機制，便能將下波未預見自動化流量模式的偵測時間從數週縮短至數分鐘。 | |
| SDS1.3.3 | 如果我們將網頁請求的回填機制自動化並應用於五月份日誌，我們將把未來事件的修復時間從幾個月縮短到幾天，從而解決「5 月份頁面瀏覽量上升」事件。 | |
| SDS1.3.4 | 如果我們建立一套規範化、可操作化的內部稽核流程來審核機器人分類結果，將有助於建立對解決方案的信任，並預先應對那些無法自動偵測到的流量模式變化。 | |
| SDS1.3.5 | 如果我們分析基本的客戶端訊號並將其納入啟發式演算法，便能在數據平台中偵測到更多機器人模式。 | |
| SDS1.3.6 | 如果我們導入、分析並將Spur.us的IP信譽評級納入啟發式演算法，便能在數據平台中偵測到更多機器人模式。 | |
| SDS1.3.7 | 如果我們將邊緣端傳回的單一訊號導入、分析並整合至啟發式演算法中，便能在數據平台中偵測到更多機器人行為模式。 | |
| SDS1.4.1 | 如果我們能重新驗證維基媒體生態系統內現有趨勢分析——包括頁面瀏覽量、貢獻者與讀者群指標、流量等數據——便能為維基媒體運動最重要的洞見提供關鍵論點，並予以堅實支持。 | |
| SDS1.4.2 | 如果我們能重新驗證維基媒體生態系統內現有趨勢分析——包括頁面瀏覽量、貢獻者與讀者群指標、流量等數據——便能為維基媒體運動最重要的洞見提供關鍵論點，並予以堅實支持。 | |
| SDS2.1.1 | 如果我們與執行實驗的團隊密切配合，就能瞭解未來如何讓系統更自助，以及他們可能會遇到概念或技術上的挑戰。 | |
| SDS2.1.2 | 如果能為事件記錄實作更完善的除錯機制，產品團隊便能確知其實驗正如預期地收集事件數據，從而提升實驗負責人的信心。 | |
| SDS2.1.3 | 如果我們能強化實驗平台中A/B測試系統（xLab）組件及其相關MediaWiki模組的記錄與可觀察性功能，便能建立系統效能基準線，並針對實驗相關的故障狀況採取應對措施。 | |
| SDS2.1.4 | 如果我們每月一次在整個組織內分享實驗故事和結果（透過產品營運會議、設計團隊會議和跨團隊演示），那麼我們將創造實驗平台的有機採用。 | |
| SDS2.1.5 | 如果我們告訴使用者，他們的儀器 (如果是在 xLab 中建立的) 包含一組會改變風險類別的屬性，我們就能阻止儀器使用者過度收集資料，並提高屬性組合需要隱私權審查的清晰度。 | |
| SDS2.1.6 | 如果成長團隊與實驗實驗室合作，針對兩個使用案例進行儀器化工作（其中一個案例採用A/B測試以深入了解分桶功能，另一個案例則採用長期儀器化以探索對關鍵績效指標（KPI）類指標的支援能力），我們便能評估該方案是否足以滿足需求，從而取代我們在GrowthExperiments中自建的實驗環境。 | |
| 未來讀者（英文簡稱為：FA）假設
[ 未來讀者關鍵結果 ] | ||
|---|---|---|
| 假設簡稱 | 第二季文字內容 | 細節與討論 |
| FA1.1.4 | [承接上一財政年度] 若我們在Roblox平台打造全新的維基百科體驗，將能驗證此舉是否為向年輕世代（Alpha世代）受眾推廣品牌之有效途徑。 | |
| FA1.1.2 | 若我們在itch.io建立一個專門提供維基百科新體驗的中央樞紐，便能吸引超過50位非維基百科用戶參與並提供反饋。這將有助我們了解遊戲設計中哪些元素有效/哪些無效。 | |
| FA2.2.1 | 如果我們在短影片平台投入社群管理資源，那麼到2025年12月第二季度末 （2025年12月），TikTok平台新觀眾觀看比例將實現季度環比增長30%。同時在所有短影音平台上，我們將在外部內容的品牌留言區獲得總計50,000次互動（含讚好與回覆評論），此舉將提升品牌能見度，並有效觸及當前尚未覆蓋的受眾群體。 | |
| FA2.2.2 | 如果我們能制定並通過維基百科創作者合作夥伴計劃的內部策略及對外宣傳素材（包含向創作者傳達的價值概述、合作標準、合約流程，以及創作者內容在自有與創作者頻道中的呈現方式），便能建立完善的創作者策略，藉此透過知識內容在社交媒體觸及全新受眾。 | |
| 產品和工程支援（英文簡稱為：PES）假設
[ 產品和工程支援關鍵結果 ] | ||
|---|---|---|
| 假設簡稱 | 第二季文字內容 | 細節與討論 |
| PES1.1.5 | 如果將MediaWiki內容歷史與Wikifunctions的服務層級目標納入Sloth/Pyrra系統，我們將有另外兩項服務層級目標進入生產。 | |
| PES1.1.6 | 如果我們運用既有SLO的回溯數據來測試Sloth系統，將能釐清Pyrra或Sloth（或其他方案）是否適合用於我們固定時間窗的錯誤預算管理模式。此舉亦能探索如何透過自助式方法協助服務負責人建立服務層級目標指標，並將其應用於決策過程。 | |
| PES1.2.4 | 如果我們於第一季與三個團隊試行季度願望與社群訊號審查流程，將促使產品經理將社群訊號整合至其季度與年度規劃流程中。 | |
| PES1.2.5 | 如果在願望清單擴充功能中新增篩選與排序願望的功能，結合現有的標籤分類與投票機制，這三項改進將使願望清單的獨特參與者數量至少提升30%。 | |
| PES1.3.3 | 如果我們能在平台上創建至少5項基於用戶互動觸發的精妙干預措施，便能為入口頁面與生日模式小工具定義觸發條件。可用性測試將幫助我們了解哪些互動環節能與品牌建立正面的連結。這項假設的完成期限為十月底的維基媒體北美地區會議。 | |
| PES1.3.4 | 如果我們與通訊部門成員合作，打造一個探索維基百科歷史、現狀與未來的沉浸式網站，目標鎖定活動目標區域內18至34歲的線上受眾，將能透過社群分享及其他線上活動，模擬出與維基百科更深層的連結。此舉不僅有助於達成通訊部門「提升品牌曝光度10個百分點」的關鍵績效指標，更能驗證動態內容策略是否能增強品牌好感度。 | |
共同規劃
2025年1月的更新資訊。
.jpg)
年度計劃是維基媒體基金會對來年希望實現的目標的描述。我們努力使整個計劃具有參與性、願望性和可實現性。每年，我們都會邀請請貢獻者分享他們的觀點、希望和具體要求，作為我們制定計劃的依據。我們尋求意見的方式包括產品團隊與社群對話、社群願望清單、社群對話如維基共享資源的對話系列、會議，以及如本頁一樣的維基頁面。
對於我們的下一個年度計劃，從 2025 年 7 月到 2026 年 6 月，我們正在思考如何才能最好地服務於跨世代願景，考慮到世界和互聯網的快速變化，以及這如何影響我們的自由知識使命。
正如我去年所述，我們需要專注於我們的與眾不同之處：即使在虛假消息和不實資訊在互聯網上激增、各種平台爭相吸引新世代注意力的情況下，我們仍有能力提供值得信賴的內容。這包括確保我們透過擴大缺失資訊的覆蓋範圍（當中可能因不公平、歧視和偏見而造成的缺失資訊）實現匯集和向世界提供所有人類知識總和的使命。在人工智慧和豐富體驗驅動的網路不斷變化，我們的內容同時需要發揮作用並保持活力。最後，我們需要為我們的產品和募款建立一個共同的策略，找到可持續資助我們維基媒體運動的方法，以便我們能夠長期支持這項工作。
為了就來年的工作重點做出選擇和取捨，我們收集了一些問題，並思考如何分配有限的資源以達到最大的影響力。
如果您對產品與技術部門將根據此處設定的優先順序建立的功能或服務特別感興趣，您將三月份於有時間對具體目標和關鍵結果提出意見。（以下為本年度計劃的目標和關鍵結果，以供參考。）
如果您想思考一下我們技術環境中的挑戰與機遇，以及我們在下一個年度計劃中應該設定的方向，請與我們一起思考以下問題。
我們不斷從社群對話、我們收集的資料、我們進行的研究訪談等多種途徑中獲取有關這些問題的資訊——這已經不是我們第一次詢問和了解這些問題，而且我們已經就其中的許多問題開展了工作！我們現在希望再次詢問這些問題，並持續學習，因為這些問題是我們在規劃階段的首要考慮。
問題：
- 指標和數據
- 數據和指標可以透過哪些方式更好地支持您的編輯工作？您能否想到有關編輯、閱讀或整理的資料，可以幫助您選擇如何花費時間，或何時需要注意某些事情？這可能是有關您自己或他人活動的數據。
- 編輯
- 什麼時候編輯讓您感到最有成就感和樂趣？什麼時候最令人沮喪和困難？
- 我們希望貢獻者的工作能獲得更多的回饋和認可，這樣就不會覺得沒有人注意到他們在維基上所付出的努力。什麼樣的回饋和認可會激勵您？是什麼促使您繼續編輯？
- 由於整個維基非常龐大，編輯很難決定每天要花時間在哪些維基專案工作上。有什麼資訊或工具可以幫助您選擇如何花費時間？如果有一個中央、個人化的地方，可以讓您找到新的機會、管理您的任務，並了解您的影響，這會不會很有用？
- 我們希望改善維基上的協作體驗，讓貢獻者更容易找到彼此，並共同完成專案，無論是透過一起處理積壓的工作、編輯馬拉松、維基專案，甚至是兩個編輯坐下來一起工作。您認為我們該如何幫助更多的貢獻者找到彼此、連結並一起工作？
- 閱讀/學習
- 維基的載入速度有快有慢，取決於人們住在世界何處。您認為世界上有哪些地方最需要改善效能？
- 我們該如何幫助新一代讀者發現維基百科內容的趣味性與吸引力？我們過去曾討論過有關互動式內容和影片的想法，今年我們專注於圖表並嘗試新的方式來展示現有的維基百科內容。我們如何繼續沿著這條軌道，以維基媒體獨有的新方式使用我們現有的內容？
- 管理
- 維基百科可能需要做些什麼改變，才能讓更多人願意參與進階的志願者角色，例如巡查員或管理員？
- 關於編輯或使用者的哪些資訊或情境，可以幫助您更快速、輕鬆地做出巡查或管理決策？
- 外部趨勢
- 在維基媒體以外的世界，您注意到哪些最重要的變化？這些可能是科技、教育或人們學習方式的趨勢。
- 除了維基媒體運動之外，您同時參與哪些其他線上社群？我們可以從其他社群平台上的工具和流程中學到什麼經驗教訓？
- 您如何在維基媒體工作內外使用人工智能工具？您覺得人工智能在哪些方面有用？
- 維基共享資源
- 我們可以與維基共享資源社群一起做出什麼決定，以創造一個支持創造百科知識的可持續專案？
- 維基數據
- 您希望維基數據未來如何發展？它如何對建立值得信賴的百科全書內容發揮最大作用？