社群願望清單/願望撰寫指南
如何寫出好願望
我們歡迎您提出並樂意聽取您對維基媒體專案的改進建議。我們社群技術團隊期望將工作細分為更小的部分，願望不應僅限於修復單一錯誤，也不該是為期超過一年的大型專案。我們深知工具退役需要大量工作，因此我們也接受技術退役願望，以評估相關需求。無論如何，維基媒體基金會將會集體對工作進行分級篩選，並將願望轉交給相關的內部利益關係者，以提升對社群需求的認知。
優先順序
為了決定願望的優先順序，我們會將您提交的願望與年度計畫中所訂定的策略目標進行比對。您不需要在提交願望前預先閱讀年度計畫，但如果您想更了解願望的分級篩選流程，您可以自行查閱。此外，我們還會考量以下三大因素，以決定是否採納並著手實現您的願望：
- 對社群具有明確且可衡量影響的願望，例如提升參與度（編輯、搜尋、探索等），而非難以衡量（甚至無法衡量）其影響的願望；
- 完全沒有替代方案來緩解根本問題的願望，而非已有替代方案（無論是否直觀）的願望；
- 針對關鍵功能或使用者群體具有廣泛適用範圍的願望，而非僅對少數特定使用者群體（例如新興功能、進階使用者）相關的願望。
更具體的標準：
| 優先級 | 影響 | 嚴重程度 | 社群影響範圍 |
|---|---|---|---|
| 最高 | 對OKR指標有可衡量的影響 | 無可行的替代方案，且情況可能進一步惡化 | 對於某項核心功能或主要使用者群體而言，問題普遍存在且可重現 |
| 高 | 非核心指標可追蹤或可能存在關聯性 | 存在複雜的替代方案，會降低使用者體驗或造成技術負債 | 確實可重現，但並未影響大多數使用者 |
| 中 | 尚不清楚願望是否會產生任何可衡量的影響 | 存在直觀的替代方案，讓使用者能繞過問題 | 無法穩定重現，可能是較小眾的使用情境 |
| 低 | 沒有可衡量的影響 | 無嚴重性，僅是為了讓功能愈臻完善 | 範圍不明，或可能是特殊使用情境 |
這並非詳盡清單，僅是為了讓您對我們篩選願望的流程有基本認識。所有提交的願望，無論獲得多少支持票，都會經過這些篩選流程。您可以根據上述提示，提供更多背景資訊以協助我們評估您的願望。
範圍外的願望
我們不大可能處理技術性編輯或涉及方針變更的工作。開發全新的應用程式或演算法通常超出我們的業務範圍。基金會不會製作小工具或機器人，但我們歡迎您提出相關願望，供社群成員參考評估。
聚焦問題本身，而非具體的解決方案
儘管沒有撰寫「好願望」的正式標準，但我們鼓勵提案者明確表達他們面臨的單一問題，而非直接提出特定的解決方案，如此能為志願者和工作人員提供合作解決問題的空間。潛在的解決方案可在討論頁進行探討與協作，並根據對話所達成的共識，更新與擴充願望描述。
撰寫願望時，展現同理心、明確表達使用者面臨的挑戰和目標，可以避免願望過於小眾或具體，也能避免其他使用者對解決方案吹毛求疵。
在下方的範例中，問題主導型（problem-led）和解決方案主導型（solution-led）的願望皆暗示要改善「新手編輯者」的體驗。
問題主導型的範例能讓解決方案保持開放，並鼓勵多方協作；而解決方案主導型的範例則可能收到來自抗拒重新命名「使用者沙盒」的貢獻者的負面回饋。對於可透過多種技術手段解決的問題，建議避免過於狹隘地限定解決方案，並避免僅描述多種互斥解決方案中的其中一種。
因此，問題主導型的願望更有機會被分配到重點領域。
| 問題主導型的願望（建議） | 解決方案主導型的願望（不建議） | |
|---|---|---|
| 標題 | 讓新手更容易建立第一篇條目 | 將沙盒重新命名為「草稿編輯器」 |
| 描述 | 使用者沙盒很難找到，尤其是對於新手編輯者來說。一旦找到自己的沙盒，新手編輯者會看到許多免責聲明，使他們很難有信心寫出高品質的條目。這會影響新手能否入門維基百科以及他們作為貢獻者的自信。 | 「沙盒」一詞會讓新使用者感到困惑。我們應將其重新命名為「草稿編輯器」，這樣人們更有可能進而起草條目。 |
| 類型 | 系統變更 | 功能請求 |
| 專案 | 維基百科 | 維基百科 |
| 受影響使用者 | 新手編輯者以及審核新編輯的下游巡查員 | 編輯者 |
| Phab工單 | 非必填 | T123456 |
此外，願望中應避免涵蓋多個問題。投票者可能認同某些問題與想法，卻對其他部分持反對意見。同樣，若願望涉及多個軟體部件，基金會與利益相關者可能會認為願望面向過多，難以處理。