RISC-V 應該把 mentorship 做成有薪、限期、公開的工程協作

RISC-V International 的 mentorship 計畫之所以有效，是因為它把指導做成短期、結構化、可交付的工程工作，而不是模糊的善意活動。

我支持 RISC-V 把 mentorship 維持成有薪、限期、公開的制度，因為這樣才像真正的工程協作，而不是情緒性幫忙。它把工作定義成三個月、每週 30 小時的專案，並由 RISC-V International 與 LFX Mentorship 承接，這代表參與者一開始就知道要交付什麼、何時交付、誰來審核。對一個需要擴張生態的技術標準組織來說，這種清楚比熱情更重要。

第一個論點

短期有薪，比長期空泛更適合 mentorship。三個月、每週 30 小時，這個尺度剛好夠完成一個有意義的工程成果，也不至於把新人綁死在沒有邊界的學習關係裡。對 RISC-V 這種涵蓋工具鏈、驗證、文件與生態支援的領域來說，最需要的不是漫長陪跑，而是能被拆解、能被 review、能被重用的具體產出。

薪資更不是附加價值，而是制度核心。頁面明確寫出，獲選 mentee 會拿到 paid position，其他參與者則可能以 unpaid 方式加入累積經驗。這種設計傳遞的訊號很直接：如果這項工作對生態有價值，就不該只靠參與者自掏腰包。很多技術社群把入門成本轉嫁給年輕工程師，最後篩掉的不是能力，而是負擔得起的人。RISC-V 反過來做，才有機會擴大貢獻者基礎。

第二個論點

公開提案入口，讓 mentorship 連到真實需求，而不是內部排隊。RISC-V 允許 Premier、Strategic、Community member 提案，這意味著專案來源不是封閉的師徒圈，而是直接來自正在做事的組織。結果就是，計畫更容易對準實際痛點，例如工具、測試、文件或生態整合，而不是只服務某個中心委員會的偏好。對標準組織來說，這種開放性就是需求發現機制。

對 mentor 而言，這種制度也不是做公益而已，而是提升產能。RISC-V 把 mentor 的收益講得很實際：加速生態工作、培養下一代工程師、建立更多元的開發者管道。這些都不是抽象口號。當一位資深工程師能把明確切好的工作交給可勝任的 mentee，他拿到的是吞吐量、文件、與 onboarding 的槓桿。在人才稀缺的技術領域，能降低瓶頸的 mentorship，本質上就是能力擴張。

第二個論點

公開時程讓制度可信。RISC-V 把 proposal window、通知日期、申請期間與 session 節點都列出來，這表示它把 mentorship 當成一個真正的 program 在管理，而不是社群貼文裡的善意承諾。這對公司、學校與獨立開發者都很重要，因為大家需要配合學期、排班與 release cycle。可預期性不是行政細節，而是參與門檻的一部分。

季節性節奏也避免 mentorship 變成永遠開放、永遠混亂的入口。春、夏、秋三個 session 提供固定窗口，既不會稀釋資源，也不會讓申請者無所適從。這種設計的好處很現實：組織可以集中審查提案，參與者可以提前準備，整體品質自然上升。當一個 program 需要同時兼顧全球時區、志工時間與專案節奏，固定窗口比隨時收件更成熟。

反方可能怎麼說

反對者會說，有薪 mentorship 會扭曲動機。只要有 stipend，申請者就可能把目標從學習與貢獻轉成拿錢，贊助方也可能把 mentee 當成便宜勞力，最後把教育包裝成外包。這個擔心不是空穴來風，因為開源社群確實常見低估勞動價值、把「指導」變成模糊工時的問題。

另一個批評是公平性。頁面也承認，除了被選中的 paid mentee，還可能有其他 unpaid participants。看起來像是同一個專案裡出現兩種待遇，容易引發不滿，也可能強化原本就存在的進入門檻。

但這些批評並沒有否定模型，只是指出它必須被嚴格管理。RISC-V 已經用三個控制點把風險壓低：範圍短、時程固定、流程公開。paid 的角色不是遮掩勞動，而是承認勞動；unpaid 的參與也不是剝削，而是把額外加入的學習路徑說清楚。真正該拒絕的不是薪資，而是模糊、無邊界、沒有交付的 mentorship。只要專案定義清楚，這個制度的限制是可接受的，且比假裝「大家都是來學習的」更誠實。

你能做什麼

如果你是工程師、PM 或創辦人，請把 mentorship 當成可交付的專案來設計：先定義一個三個月內能完成的 artifact，再指定 mentor 時間、審查節點與預算。不要提「培養人才」這種空話，除非你能說出輸出物、驗收標準與後續維護責任。若你在 RISC-V 生態裡推案，就把最痛的一個問題切小、付費、公開，做完後把成果釋出，讓下一個團隊直接站在上面往前走。