OCaml 治理

OCaml 專案的架構、相關角色和職責。

I. 導論

A. 概觀與範圍

OCaml 生態系統持續擴張，涵蓋越來越多的集體努力，旨在支援、擴展和豐富該語言及其使用者群。本文檔提供以下項目的治理細節：

  1. OCaml.org 網域名稱及其相關專案。
  2. OCaml 平台 - OCaml 程式語言的建議工具集。

本文檔概述了報告結構、詳細說明了相關角色，並描述了每個屬於此治理範疇的專案的職責。目標是在高效運作與全面透明之間取得平衡，避免不必要的複雜性，同時堅持清晰有效的治理模型。

B. 目的 - 一份代表現實的文件

在任何給定時間，本文檔都必須反映當前現實。它不旨在成為理想化的，也不反映人們可能期望看到的結構。這是一個重點，因為本文檔的效用僅限於它代表事物真實的樣子，而不是人們可能期望它們在未來成為什麼樣子。隨著環境的變化，本文檔也應更新，以使其始終反映事物的現況。

D. 指導原則

OCaml 治理，包括 OCaml.org 和 OCaml 平台，都以開放性、社群關注和相容性等關鍵原則為指導。每個屬於 OCaml 治理範疇的專案都應與這些原則保持一致，培養一個開放、協作，並致力於 OCaml 語言及其應用持續發展和進步的社群。

II. 角色與職責

A. 所有者與委託人

OCaml.org 網域和 OCaml 平台的所有者是 OCaml 語言的首席開發人員 Xavier Leroy。OCaml.org 子網域和 OCaml 平台內的專案由社群管理，這意味著社群積極參與這些計畫的日常維護，但總體戰略方向由所有者制定。

所有者的角色是解決可能在 OCaml.org 或 OCaml 平台上出現的爭議，特別是確保這些網域內的專案能夠以協調的方式進展。社群的角色是透過積極參與、貢獻和討論來引導所有者的決策。為了培養一個健康且不斷成長的社群，所有者將明確並公開目標和決策。

預期專案本身將自我管理，並解決其社群內的問題，而無需訴諸所有者。如果需要所有者介入，他/她將擔任仲裁人。

B. 委託人

所有者可以選擇將權限委託給其他人來管理網域並以所有者的名義行事，但所有權仍歸所有者所有。這些委託人可以自由選擇如何安排自己，並與所有者達成協議。在發生爭議的具體情況下，委託人將與所有者協商，如果需要，所有者將擔任仲裁人。

目前，Xavier Leroy 已將 OCaml.org 和 OCaml 平台的責任委託給 Anil Madhavapeddy，後者已接受此角色。

C. 維護者

在 OCaml 治理下的專案將有自己的維護者，他們擁有相關儲存庫的提交權限，並負責

  • 管理特定專案。
  • 直接將程式碼寫入儲存庫。
  • 引導並篩選他人的貢獻。
  • 確保所有者/委託人了解社群需求。

一般來說，維護者僅對其負責的特定專案擁有權限，但預期不同專案的維護者會經常合作，尤其是在重大變更或公告的情況下。通常，對專案做出實質貢獻的個人將被邀請成為維護者。

D. 貢獻者

貢獻者是 OCaml 社群中更廣泛的成員，他們為 OCaml 治理下的專案做出有價值的貢獻，但通常沒有權限直接變更專案的程式碼庫或文件。任何人都可以成為貢獻者，並且沒有承諾的期望、沒有特定的技能要求，也沒有選擇過程。唯一必要的步驟是對專案進行或建議一些改進或變更。

貢獻者可以透過電子郵件列表、問題追蹤器和維基頁面等工具與專案互動。維護者可以自由地將討論引導到他們自己的專用郵件列表或偏好的溝通平台，他們認為合適。那些貢獻成為公共 Git 儲存庫一部分的人將在公共網站上以某種形式被感謝。

預期會詢問特定專案的定期貢獻者是否願意成為維護者，如上所述。沒有義務接受此類邀請。

E. 使用者

使用者是最重要的群體，它包括更廣泛的社群，即以任何方式與 OCaml 專案互動的任何人。這涵蓋了所有網站訪客、平台工具的使用者、套件使用者和郵件列表成員。沒有使用者，專案就沒有任何目的，因此應評估任何重大決策對該群體的影響。

在可行的情況下，應鼓勵使用者盡可能提供回饋並參與專案。與專案大量互動的使用者可能會繼續成為貢獻者。

應該注意的是，這些角色並非互斥，例如維護者和貢獻者必然也是使用者。

III. OCaml.org

定義 - OCaml.org 內的專案以其子網域為特徵。預計大多數新工作將屬於現有的子網域，因此已經有一組維護者和貢獻者（如上所述）。

溝通 - 所有專案的維護者都必須監控 ocaml/infrastructure GitHub 問題追蹤器。問題追蹤器是交換有關 OCaml.org 專案資訊和決策的主要模式。如果專案希望建立自己的問題追蹤器，他們可以自由地在 GitHub 上執行此操作（見下文）。

治理 - 專案可以自由選擇其治理模式，只要它與 OCaml 治理的治理和指導原則相容。

A. 消除歧義 - OCaml.org 的含義

在使用術語「OCaml.org」時，可能會有多種不同的解釋。為了減少混淆，以下描述了這些解釋，並解釋了該術語對於本文檔的含義。

第二級網域名稱 - 這是一個我們熟悉的網域名稱「OCaml.org」，它具有相關的子網域和記錄（注意：為了清楚起見和教化，此處的頂級網域是「.org」）。

社群網站 - 這是面向社群的網站，可以在 ocaml.org 找到，通常簡稱為「OCaml.org」。

基礎架構 - 這可能指的是虛擬機器 (VM)、服務或其他以某種方式透過第二級網域名稱本身路由的東西。一個明顯的例子是託管社群網站的 VM，另一個例子是託管 Opam 套件管理工具使用的 tarball 和檔案的 VM 和系統。

為了本文檔的目的，我們採用第一種含義 - 本文檔與第二級網域「OCaml.org」的治理有關。因此，任何涉及以某種形式使用網域名稱的事物都受網域名稱本身的治理影響。這包括任何面向公眾的網頁、URL 和其他資源。這很重要，因為在某種程度上，OCaml.org 是它託管的專案的總和。

為了避免網域名稱本身與社群網站專案之間的混淆，本文檔中的術語「OCaml.org」僅指第二級網域名稱本身。任何提及社群網站專案網域的地方都將包含子網域「www.ocaml.org」，即使它被設定為重新導向到 ocaml.org。

B. 啟動專案

任何新工作的提案都應在 ocaml/infrastructure GitHub 問題追蹤器上提出和討論。如果維護者之間達成共識，認為該工作適合現有的專案，則該專案的維護者可以繼續進行。

如果需要新的子網域，則應在基礎架構列表中提出一個簡短的提案，其中涵蓋

  • 專案的目標和用途（包括所需的子網域名稱）
  • 所需的特定資源以及持續時間（例如，VM）
  • 對現有專案的任何影響或關聯
  • 有關初始維護者的資訊
  • 程式碼/內容的擬議授權安排詳情

上述資訊旨在激發討論，因此最好簡潔。經過討論，並且如果所有者/委託人同意，則可以配置資源。所有者/委託人沒有義務提供子網域以外的任何資源。

C. 關閉專案

專案可以關閉

  • 如果它已完成其目標，並且維護者要求將其關閉
  • 如果沒有維護者繼續支援它，並且沒有人願意承擔這個角色
  • 由所有者/委託人以任何理由關閉

在所有情況下，都必須事先向基礎架構列表發送通知，包括合理的時限和關閉原因。關閉僅表示撤銷或重新導向子網域和/或關閉或回收提供的任何資源（例如，VM）。

D. 現有專案

專案由其子網域引用，當前專案的摘要維護在基礎架構維基頁面上：https://github.com/ocaml/infrastructure/wiki

IV. OCaml 平台

OCaml 平台是 OCaml 程式語言的建議工具集。它旨在為 OCaml 開發人員提供一個穩定且一致的環境，使他們能夠專注於構建高品質的軟體。OCaml 平台中的工具各自有其獨立的生命週期。

本節的目的是概述在 OCaml 平台內孵化、推廣和棄用工具的過程和標準。它為工具的生命週期提供了指導方針。

A. OCaml 平台工具的一般要求

除了工具生命週期中每個階段的要求外，OCaml 平台中的所有工具都必須滿足一些通用要求。這些要求確保工具與平台的品質和標準一致。

  • OCaml 平台只包含工具。這些工具使用的函式庫將由它們的傳遞依賴項提供支援。每個工具都會自行決定使用哪些函式庫。這樣做，它就承諾在必要的時間內支援這些函式庫。
  • 工具必須有完善的文件，包括清晰的安裝說明和使用範例。
  • 工具必須具有與 OCaml 平台相容的寬鬆開放原始碼許可證。相容的許可證包括允許在不同條款下分發修改版本，且無需原始碼的許可證。特別是，強制要求必須提供修改版本完整原始碼的許可證與 OCaml 平台不相容。相容的許可證範例包括 MIT、ISC、Apache License。與 OCaml 平台不相容的許可證包括 GPL v2 和 v3。
  • 平台工具必須採用 OCaml 行為準則，並嚴格遵守其指導方針。
  • 工具必須經過測試，並且與最新版本的 OCaml 相容，並承諾遵循 OCaml 版本發布準備流程，其中包括在新編譯器版本發布的 alpha 版本期間發布相容或預覽版本的平台工具。
  • 工具必須考慮到向後相容性，並且在首次穩定版本發布後完全向後相容。

B. 工具生命週期階段

1. 孵化 (Incubate)

定義

孵化階段是 OCaml 平台中工具生命週期的第一個階段。填補 OCaml 生態系統空白但尚未準備好大規模發布和採用的新工具會在該階段孵化。此階段的工具具有快速迭代開發週期，並且在首次主要發布之前可能具有不可靠的向後相容性。

孵化要求

工具必須滿足以下要求才能被考慮在 OCaml 平台中孵化

  • 至少有兩位維護者致力於該工具的長期維護
  • 有明確定義的用途和範圍 - 該工具必須填補 OCaml 開發人員工作流程中的空白，或提供執行現有工作流程的不同方式。如果與「活動 (Active)」工具重複，則兩個工具的維護者應進行討論並解決重複問題
  • 有明確的未來開發和維護計畫，包括建立遷移路徑以及明確的社群需求以晉升為「活動 (Active)」
  • 運作中的實作以及充足的文件和測試

從孵化階段移除工具

如果不再符合孵化的標準，則可能會從孵化階段移除工具。請注意，並非所有孵化工具都會晉升為「活動 (Active)」，但社群仍然會了解一些有關所需或有用功能的資訊。

2. 活動 (Active)

定義

「活動 (Active)」階段是 OCaml 平台中工具生命週期的第二個階段，它是 OCaml 社群每天使用的主力工具的所在地。這些工具是關鍵專案，受到高度依賴，並推薦給新專案和新手使用。「活動 (Active)」工具以其強大的向後相容性保證和對使用者工作流程的最小干擾而聞名。

對「活動 (Active)」工具的任何變更都會附帶完整的更新說明，並且它們的中繼資料檔案會可靠地進行版本控制，以允許使用者控制何時升級到新版本。「活動 (Active)」工具的開發社群始終開放，並鼓勵任何人成為維護者。

「活動 (Active)」工具維護者會定期舉行開發人員會議。任何有興趣為專案做出貢獻的社群成員都歡迎加入開發人員會議。這些開發人員會議的會議記錄會記錄在 GitHub 上，並且可以查閱。

進入「活動 (Active)」階段的工具可以託管在 OCaml GitHub 組織上，並且權限透過 GitHub 團隊進行管理，只有專案的主要維護者和 OCaml GitHub 組織管理員可以更新。

從孵化階段晉升為「活動 (Active)」的要求

要從孵化階段晉升到「活動 (Active)」階段，工具必須滿足以下要求

  • 該工具不得重複平台中另一個「活動 (Active)」工具已提供的任何功能。與平台中其他工具的任何重複和重疊都必須在孵化階段解決。
  • 該工具必須已達到穩定版本，以版本高於 1.0 和強大的向後相容性強制執行來表示。
  • 該工具必須有完善的文件，並有明確的未來開發藍圖。
  • 該工具必須擁有強大且活躍的開發社群。

是否晉升工具的最終決定由擁有者和代表（們）在與開發社群諮詢後，根據該工具的整體穩定性、OCaml 社群的採用情況以及對平台原則的遵守情況做出。

3. 維護 (Sustain)

定義

「維護 (Sustain)」工具是已經使用多年的專案，並且被認為是極其穩定的。它們為 OCaml 社群提供基本功能，雖然它們沒有積極開發，但它們可以繼續長期可靠地使用。

「維護 (Sustain)」工具是 OCaml 平台生態系統的重要組成部分，因為它們非常好地服務於它們的用途。雖然可能存在較新的替代方案，「維護 (Sustain)」工具仍會被維護以支援較新的編譯器版本。如果「維護 (Sustain)」工具提供的功能在「活動 (Active)」階段有替代方案，建議使用「活動 (Active)」替代方案，因為它可能提供效能或可用性優勢。

從「活動 (Active)」晉升為「維護 (Sustain)」的要求

要從「活動 (Active)」階段晉升到「維護 (Sustain)」階段，工具必須滿足以下要求

  • 該工具已在「活動 (Active)」階段運行了很長一段時間，通常是幾年。
  • 該工具已進入維護階段，不再開發新功能。

4. 已棄用 (Deprecated)

定義

「已棄用 (Deprecated)」階段是 OCaml 平台中逐漸淘汰工具的階段，並提供通往更好工作流程的清晰路徑。這些工具不再在平台中積極維護，但仍可能由社群維護者維護。

從「維護 (Sustain)」晉升為「已棄用 (Deprecated)」的要求

要考慮棄用，工具必須滿足以下要求

  • 該工具已被「活動 (Active)」替代方案取代，並具有清晰的遷移路徑。
  • 該工具必須在「維護 (Sustain)」階段運行了足夠長的時間，並且已向使用者發出足夠的通知，以便讓他們自行安排遷移。

V. 流程

A. 決策制定和溝通

大多數討論的首選方法是透過大致共識和運行程式碼。討論應公開進行，並在 OCaml Discuss 論壇、相關專案郵件列表或相關問題追蹤器上進行。鼓勵使用者和貢獻者參與並表達意見。通常，專案的維護者會在考慮更廣泛的意見後做出最終決定。

所有 OCaml 治理下的專案都應記錄下來，以便使用者可以了解它們，並了解它們的用途以及如何做出貢獻。

B. 貢獻流程和許可

OCaml 治理下的每個專案都需要定義清晰的貢獻流程和許可協議，以便貢獻者了解如何與維護者互動。通常，這將涵蓋溝通發生的地點以及提交補丁的流程。鼓勵社群的貢獻，並且可以採取多種形式，包括錯誤修復、新功能、內容
或文件。

所有 OCaml 治理下的專案都應為開放原始碼，並且許可安排應反映這一點。

C. 爭議解決

維護者應對其專案做出決策。目的是讓任何維護者透過每個專案內的共識流程來解決分歧。

在極少數情況下，如果專案的維護者無法就前進的方向達成一致，則建議採用以下方法

  • 需要闡明具體的問題，以便清楚知道需要討論的內容。
  • 將徵求其他 OCaml 專案維護者的意見。
  • 如果討論仍然無法解決，則擁有者（或其代表）將擔任仲裁人。

在上述過程中，預期所有人都會合理行事，並尊重彼此的努力和觀點。一般來說，我們期望在社群中產生共識以解決衝突。

版本 1.0.0 - 2015 年 9 月

本文件的第一個版本已於 2015 年 9 月由現任維護者組達成共識。您可以回顧討論或查看相關問題。

版本 1.0.1 — 2022 年 3 月

  • 解決標題大小寫和文法的一致性問題。

版本 2.0.0 — 2023 年 6 月

  • 納入 OCaml 平台治理。
  • 重新命名文件「OCaml 治理」，以反映 OCaml 平台的納入。
  • 更新 OCaml.org 的治理，以反映使用 ocaml/infrastructure GitHub 問題追蹤器取代基礎設施郵件列表。

版本 2.0.1 — 2023 年 10 月

  • 刪除「活動 (Active)」工具必須託管在 OCaml GitHub 組織上的要求。