專案角色

ROOST 希望為其託管的每個開源專案清楚定義角色與相應期待。這套角色設計不打算過度限制參與方式，主要目的是說明 ROOST、維護者與其他參與者各自負責的事項，同時保留未來成長與調整的空間。

ROOST

ROOST 是開源信任與安全專案的非營利託管者與協作者。ROOST 提供基礎設施，例如程式碼託管與溝通管道；產業連結，例如串連其他開源專案、平台營運者、信任與安全專家及模型開發者；信任與安全及開源領域的專業知識；以及由員工或約聘工程師提供的部分工程資源。

ROOST 作為開源 repository 的託管者，在技術上擁有 repository 的最終管理權。不過，各專案均以開源授權發布，任何人都可以建立 fork。這項安排對 ROOST 的管理權形成實質制衡，也促使 ROOST 持續為貢獻者提供合適的參與環境並回應其利益。

ROOST 技術設計委員會（Technical Design Committee，TDC）由 ROOST 董事會任命，成員具備相關產業經驗。委員會與 ROOST 及各專案維護者協商，協助統籌開源工作的整體技術方向與路線圖。

ROOST 託管的每個開源專案都有一位或多位維護者，負責日常開發與決策。維護者通常是專案的主要開發者，但不是必要條件。相較於親自撰寫多數程式碼，維護者也可能主要扮演協作者或管理者。

維護者需在技術設計委員會制定的整體路線圖下，具體規劃專案路線圖、專案管理與版本發布。維護者在 ROOST 設定的分支保護規則範圍內擁有 commit 權限，因此負責持續決定哪些程式碼可以合併。

維護者最初由 ROOST 任命，可以由個人或團隊擔任。由團隊擔任時，決策採大致共識；如需協調或處理無法形成共識的情況，可請技術設計委員會協助。所有決策均記錄於專案 issue tracker，以維持透明度。

各專案的 CODEOWNERS 檔案會公開列出維護者，兼顧透明度與自動化權限管理。維護者可自行任命其他維護者或接任人選。若發生長期未活動、職缺或不當行為，ROOST 最終仍可移除維護者或任命新人，但預期這類情況極少發生。

隨著社群成長並產生實際需要，ROOST 可能設立由共同興趣或專業領域成員組成的團隊。團隊可能取得特定權限，例如在其領域內維護專案或參與決策。

任何展現參與意願與貢獻能力的人，都可以被視為貢獻者。貢獻者可以透過發起討論、提出 issue 或建立 pull request，向專案提出變更；相關變更仍需維護者核准才能合併。

若專案需要增加維護者，已有多次貢獻獲得合併，或曾做出重要貢獻的固定貢獻者，會是適合的維護者或共同維護者人選。

社群成員包括在 Discord、GitHub 等空間與 ROOST 專案互動的所有人。他們沒有明確的專案權限，但會受邀參與討論、社群氛圍確認與公開會議。

ROOST 開源專案原則上以個人貢獻者與維護者為運作單位。特定組織可能聘用某位貢獻者或維護者，但該組織不會因此自動被視為專案貢獻者或維護者。ROOST 與相關組織仍可支持並公開說明其參與，但此原則能協助釐清責任，尤其適用於參與者轉換工作關係的情況。

為方便管理權限或提供尚未公開 repository 的早期存取，ROOST 可能在 GitHub 組織內為合作夥伴建立團隊。