將第三方程式碼捐贈給 cert-manager

cert-manager 專案歡迎外部貢獻，並從數百位不同貢獻者的數千次提交中獲益良多。大多數程式碼通常是透過對特定儲存庫（無論是主要的 cert-manager 儲存庫還是相關儲存庫之一，例如網站）的提取請求來提交的。

但是，某些貢獻不太適合這種工作流程。這很可能是因為它們的功能不屬於任何特定的現有 cert-manager 儲存庫，同時仍然與 cert-manager 專案相關。

本文件旨在說明如何捐贈程式碼給 cert-manager 專案，並為可持續的貢獻提供一個框架，使 cert-manager 的維護者和使用者都能在未來進行測試和依賴。

本文件中提出的要求部分基於 CoreDNS、Envoy、Kubernetes 和 containerd 的做法。

要求

程式碼（包含任何依賴項）必須有適當的授權許可。
我們偏好使用 Apache 2.0 授權，因為這是 cert-manager 所使用的，但授權必須是 OSI 認可的。
程式碼必須符合 CNCF 標準和盡職調查要求。
您不需要過於仔細地審查這一點；這裡的意圖是確保任何程式碼捐贈都不會對 cert-manager 作為 CNCF 專案的進展產生負面影響。請參閱 CNCF 盡職調查範本。
必須由現有的維護者贊助。
任何第三方程式碼捐贈的採用都必須由 cert-manager 的現有常規貢獻者贊助。這確保了捐贈程式碼的一方有一個單一聯絡點。
必須通過 cert-manager 符合性測試。
這可能不適用於所有捐贈，但如果存在符合性測試，任何捐贈的程式碼都必須通過這些測試。例如，對於外部簽發者。
在接受捐贈後至少 3 個月內，必須提供專案問題的聯絡人。我們不預期在接受捐贈後需要經常聯絡，但如果我們需要，有一個可以聯絡的人是很重要的。
捐贈必須是定義的擴充類型，或證明其不屬於主儲存庫的原因。
例如，一個 ACME DNS 解析器、一個自訂簽發者或一個 ACME HTTP 解析器。
程式碼的品質必須與 cert-manager 本身相似。例如，可以透過在程式碼庫上執行與 cert-manager 使用的靜態分析工具類似的工具來強制執行這一點。
程式碼必須有一個重要的測試套件，包括單元測試和端到端測試。這些測試必須能夠在針對儲存庫提出 PR 後完整運行。我們不需要 100% 的程式碼覆蓋率，但應該有針對重要功能的測試。
專案必須採用 cert-manager 安全策略並連結回該策略，例如 istio-csr SECURITY.md。
所有提交都必須有 DCO 簽核或覆蓋。為了確保所有程式碼都能合法捐贈，所有提交都應有 DCO 簽核，否則每位貢獻者在捐贈前都應做出肯定的聲明。請參閱下文。

偏好

這些項目並非絕對必要，但如果接受程式碼捐贈，它們絕對會有幫助。

應該使用 Go 語言編寫。
我們並非需要使用 Go 語言編寫程式碼，但我們更偏好這樣做。由於 cert-manager 本身是用 Go 語言編寫的，用 Go 語言捐贈程式碼可以讓我們在 Go 程式碼上使用現有的經驗和工具。

DCO 簽核

作為確保捐贈者有權限捐贈程式碼的一種方法，我們要求在捐贈時必須有 DCO 簽核或類似的等效簽核。

cert-manager 的 DCO 簽核流程會是適當的。現有的貢獻者可以透過創建一個空的簽核並註明先前的程式碼應被視為該提交所簽核的來啟動此流程。

git commit --allow-empty --signoff --message="bootstrapping DCO signoff for past commits"

捐贈後

捐贈的儲存庫中的程式碼檔案必須更新，以包含相關的 cert-manager 樣板。