覺得這篇文章有幫助嗎？
分享出去吧！
重要：這些資訊已經過時。請參閱我們的最新部落格文章，以取得最新資訊。
TL;DR；我們接下來幾個月會重新設計志工模式，讓我們的核心志工暫時不必再忙著審查社群貢獻。 如果你使用 Exercism 純粹是為了學習或引導，這裡沒有你需要知道的事（不過如果你有興趣，還是讀一下吧！）。 如果你是語言軌道的維護者、想為 Exercism 貢獻，或想回報 bug 或問題，那請務必讀完這篇 🙂
過去半年來，我們花了許多時間探索 Exercism 的未來，想像每個語言軌道都能達到最理想狀態會是什麼樣子。 我們對目前為止所打造的一切感到無比自豪。 已經收到的 85,000 則感言，說明了我們社群在建構語言軌道，以及透過這些軌道引導這麼多學生時，所完成的傑出工作。 最重要的是，我們相信這一切才只是可能的開端。 對於 Exercism 能成為什麼樣子，我們有遠大的想法、滿懷的希望與興奮。 但要實現它們，我們得先解決一些潛藏已久的根本問題。
其中最迫切的，是要以健康且永續的方式，解決我們志工社群規模成長的挑戰。 Exercism 是站在數百位全心投入的志工肩膀上建立起來的，但如今其中很大一部分人都感到身心俱疲，許多人也因此離開。 箇中原因千百種，有些和 Exercism 直接相關，有些是生活時間壓力使然，也有些和當前世界正在發生的一切脫不了關係。 但我們已經非常清楚，必須設計並發展出一套更好的方式，讓我們一起打造這個平台。
長久以來，我們一直試著用開源軟體（OSS）的模式來打造 Exercism，也就是由維護者審查來自廣大社群的貢獻。 這帶來了許多問題，也讓維護者和貢獻者雙方都感到挫折。 如果你想知道細節，我在下方有更深入的探討，但簡單來說：我們的核心志工如今把時間花在當被動的守門人，而不是創新的創造者。 這對他們來說樂趣少了很多，也意味著 Exercism 失去了這些人過去為平台帶來的魔力。
要解決這個問題，我們需要做兩件事：
- 我們需要設計一套新的志工制度，比傳統 OSS 模式更適合 Exercism。 到目前為止，我們已經投入不少心力嘗試過，但失敗了。 所以接下來幾個月，我們會撥出一些時間，和志工一起好好地把這套制度設計出來。
- 我們接下來幾個月會大致暫停更廣泛的社群貢獻，讓我們的核心志工能專注用自己想要的方式建構和發展軌道（或者，如果他們只是想喘口氣，就放個長假！）
我的期望是，透過退一步、真正把這件事設計好，加上募款以擴充我們的教育團隊，我們能讓 Exercism 成為一個很棒的志工園地，並協助確保它的未來。 在這段期間，這些變動應該能讓軌道比過去一年有更好的成長與進步，也讓我們的維護者不再持續耗竭，反而在投入 Exercism 時感到更快樂、更有活力、也更有連結感。
具體的變動
我們正在推動三項具體的變動。
使用論壇，而不是 GitHub Issues
我們會把 GitHub 完全空出來，讓維護者專心處理他們想推進的 Issue。 我們會關閉大量先前開給社群處理的 Issue（並加上標籤，方便未來需要時能輕鬆重新開啟），同時在大多數儲存庫裡不再允許非經邀請的新 Issue 或 PR。 如果你想討論或回報什麼，請改用論壇。 如果你開了非經邀請的 Issue 或 PR，它會被自動關閉，並引導你到論壇。
暫停更廣泛的社群貢獻
軌道會分成三類：
- 多數有活躍維護者的軌道會暫停社群貢獻，讓維護者能自主運作或好好休息。 （這些軌道的維護者可以要求取消強制的一人審查規定。請在 Slack 上找 Erik 談。）
- 有些有活躍維護者、且他們確實想繼續接受社群貢獻的軌道，會維持開放（如果你是維護者，比起第一種模式更想採用這種模式，請在 Slack 上聯絡 Jonathan Middleton 討論）。
- 對於沒有活躍維護者的軌道，這段期間軌道的開發基本上會暫停。
在所有情況下，我和 Erik 都會繼續在合併前，為 Tooling 儲存庫的 PR 做把關確認。
唯一的例外是，我們會繼續接受解法與文章的 PR，並推動一項涵蓋整個組織的樂觀合併政策，目標是在 Exercism 各處建立起基本的解法內容，並允許逐步改善，規則如下：
- 如果程式碼能解出練習，而且在語法和語意上都很道地（也就是看起來像 $LANG 的程式碼），就應該合併。 如果不是，就應該由 PR 作者修改。
- 如果維護者想對內容做調整（例如改善建議、微調內容、突顯更好、替代或更道地的解法），應該透過後續的 PR 來進行。
設計新的志工制度
我們會組成一個社群委員會，一起為我們未來設計一套永續、健康的志工框架，釋放 Exercism 的潛力。 如果你對 Exercism 的未來有承諾，也想參與這個過程，請聯絡 Jonathan。
接下來幾個月，我們會照這些做法來走。 這段期間我們會持續思考所有事情，並計畫在 2023 年 6 月前做出一些新的決定。 如果你有任何想法，歡迎在論壇開一個主題！
後記：為什麼我們的 OSS 模式行不通
我們過去的模式是圍繞著 OSS 模式建立起來的。 它依賴的是一群進入 Exercism、在軌道建構上做出優秀成果，然後被賦予維護者權限的志工，有了權限之後，他們便能接受我們廣大使用者社群的貢獻來改善軌道。
這在紙上談兵時看起來很棒，但實際上有些重大的問題。 最首要的問題是，那些為 Exercism 注入最多魔力的人，最後反而沒時間寫程式或創造 Exercism，因為他們的時間都花在回應社群貢獻上。 這幾乎從來不是維護者一開始加入 Exercism 的原因，也不是他們享受的工作。 這有點像一個熱愛開發的人被「升遷」為團隊主管，變成管理人員而不是寫程式。 當下看起來也許是很好的升遷，但結果往往證明，人們對當主管的喜愛程度，遠不及寫程式。
它還建立在一個假設上：廣大社群貢獻的總和，會大於某位維護者原本能獨自做出的貢獻。 但在 Exercism，情況幾乎從來不是如此。 Exercism 本身很複雜，教育本身也很難，兩者加在一起，就讓為 Exercism 貢獻成為一件既複雜又困難的工程。 不論是 Exercism 在技術上如何運作，或是它在教育上的方針，都有大量東西要學習和理解，這也意味著大多數人第一次貢獻時，都還在摸索。 這表示他們最初的貢獻相對較小，但也幾乎總是需要花很多工夫審查和微調。 對維護者來說，這是很耗時的工作。 事實上，審查所花掉的總時間（還有其中所需的脈絡轉換），意味著維護者審查這個 PR 所投入的精力，通常比自己動手做還要多。 當然，這也有一些例外，但在 99% 的情況下都是如此。 而且對維護者來說，這往往更痛苦，因為這個 PR 解決的問題並不在他們優先清單的前幾名，結果就是他們心裡知道真正要緊的事反而做不成。
最後，OSS 模式仰賴貢獻者從小事做起，最終累積到足夠的知識和穩定度，進而成為維護者。 在軟體函式庫這類 OSS 專案裡，這套做法相對行得通（例如有人在工作環境中使用某個函式庫，持續為它加入改善，到最後累積的知識和原創者一樣多）。 但對 Exercism 來說，這從來沒發生過。 儘管過去 12 個月合併了來自數千位貢獻者的 PR，只有極少數人後來成為固定貢獻者，成為維護者的更是少之又少。 這同樣主要歸因於 Exercism 的複雜度，但也因為它並不是一套範圍明確的軟體，而傳統上這套模式是在那樣的軟體上才行得通。
這一切都讓維護者無比灰心，也對 Exercism 造成傷害。
軌道停滯不前，而我們那些原本對建構充滿熱情的核心志工，也在工作變成審查他人的成果、協調互相競爭的優先事項、以及應付各種意料之外的要求之後，大多失去了那份熱情。 在建構 v3 的期間，維護者能相對自主地工作，因為他們的工作大多在幕後進行，這帶來了極高的生產力，也讓大多數人真的很享受貢獻的過程。 自從 v3 上線之後，儘管許多志工投入 Exercism 的時間一樣多，這段時期卻沒那麼愉快、生產力也低得多，主要原因是大量精力都被耗費在回應他人的貢獻或 Issue 上。 我們的志工現在把時間花在當被動的守門人，而不是創新者，這樂趣少了很多。
這些就是我們必須解決的挑戰，而且個個都不容易。 我們需要找出一條路，讓想投入數百小時建構 Exercism 語言軌道的人能夠如願，而且樂在其中。 我們需要找出一條路，讓 bug 修正和小型貢獻能進入我們的程式碼庫，而不需要佔用那些核心志工的注意力。 我們也需要找出一條路，吸引新的志工加入 Exercism，並在他們選擇長期投入貢獻時給予支持。 我們需要整體減少守門的情形，同時也要尊重那些為軌道付出極多心力的人，他們有強烈且深思熟慮的意見。 我們需要讓管理和運作整套志工制度這件事變得有趣。 我們還需要解決其他一連串問題。 這需要時間，也會是項挑戰，但當我們成功做到時，那會非常了不起。
