将第三方代码捐赠给 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 样板