22/C4

集体代码构建契约 (C4)

状态：已弃用
编辑：Pieter Hintjens ph@imatix.com

集体代码构建契约（C4）是 github.com Fork + Pull 模型的演进，旨在为自由软件项目提供最佳的协作模型。这是 C4 规范的第 1 版。

注意：本 RFC 已被 https://rfc.zeromq.cn/spec:42/C4 取代。

许可证

本规范是自由软件；您可以根据自由软件基金会发布的 GNU 通用公共许可证的条款重新分发和/或修改它；可以是许可证的第 3 版，或者（由您选择）任何后续版本。

分发本规范是希望它会有用，但**不提供任何担保**；甚至不包含适销性或特定用途适用性的默示担保。详情请参阅 GNU 通用公共许可证。

您应该随本程序收到一份 GNU 通用公共许可证的副本；如果没有，请参阅 https://gnu.ac.cn/licenses。

语言

本文档中的关键词“必须”、“禁止”、“要求”、“应”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”应按 RFC 2119 中的描述进行解释。

目标

C4 旨在为开源软件项目提供一个可重用的最佳协作模型。它有以下具体目标：

通过减少新贡献者的摩擦并创建一个具有强大正反馈的规模化参与模型，最大化项目社区的规模和多样性；
通过分离不同的技能集来减轻对关键个人的依赖，从而在任何所需领域拥有更大的能力池；
通过增加决策过程的多样性，使项目开发更快、更准确；
通过允许安全的实验、快速失败和稳定代码的隔离，支持项目版本从实验性到稳定的自然生命周期；
降低项目仓库的内部复杂性，从而使贡献者更容易参与并减少出错范围；
强制执行项目的集体所有权，这增加了对贡献者的经济激励，并降低了被敌对实体劫持的风险。

设计

前言

项目**应**使用 Git 分布式版本控制系统。
项目**应**托管在 github.com 或同等平台（本文中称之为“平台”）上。
项目**应**使用平台的 Issue 跟踪器。
项目**应该**有清晰记录的代码风格指南。
“贡献者”是希望提供补丁的人，补丁是一组解决某个明确问题identified的一组提交。
“维护者”是将补丁合并到项目的人。维护者不是开发者；他们的工作是执行流程。
贡献者**禁止**对仓库拥有提交权限，除非他们同时也是维护者。
维护者**应**对仓库拥有提交权限。
根据本契约的条款，每个人，无论有何区别或歧视，**应**有平等的权利成为贡献者。

许可与所有权

项目**应**使用分享许可协议，例如 GPLv3 或其变体（LGPL、AGPL），或 MPLv2。
对项目源代码的所有贡献（“补丁”）**应**使用与项目相同的许可证。
所有补丁均归其作者所有。**禁止**任何版权转让流程。
项目中的版权**应**由所有贡献者集体拥有。
每位贡献者**应**负责在项目贡献者列表中标明自己。

补丁要求

维护者和贡献者**必须**拥有平台账户，并且**应该**使用其真实姓名或广为人知的别名。
补丁**应该**是针对正好一个已识别并同意的问题的最小且准确的解决方案。
如果项目定义了代码风格指南，补丁**必须**遵守这些指南。
补丁**必须**遵守下文定义的“公共契约的演进”指南。
补丁**禁止**包含来自其他项目的非普通代码，除非贡献者是该代码的原始作者。
补丁**必须**在至少主要目标平台上干净地编译并通过项目自测。
补丁提交消息**应该**包含一行简短（少于 50 个字符）的摘要，可选地后跟一个空行，然后是更详细的描述。
“正确补丁”是指满足上述要求的补丁。

开发流程

项目的变更**应**遵循准确识别问题并应用最小、准确解决方案的模式。
要请求变更，用户**应该**在项目平台的 Issue 跟踪器上记录一个 Issue。
用户或贡献者**应该**通过描述他们面临或观察到的问题来撰写 Issue。
用户或贡献者**应该**就其观察的准确性以及解决问题的价值寻求共识。
用户**禁止**记录未明确文档化且不可证明的功能请求、想法、建议或任何问题解决方案。
因此，项目的发布历史**应**是记录和解决的有意义的 Issue 列表。
要处理某个 Issue，贡献者**应**fork 项目仓库，然后在他们的forked仓库上工作。
要提交补丁，贡献者**应**创建平台的 Pull Request 回到项目。
贡献者**禁止**直接向项目提交变更。
如果平台将 Pull Request 实现为 Issue，贡献者**可以**直接发送 Pull Request，而无需单独记录一个 Issue。
要讨论补丁，人们**可以**在平台的 Pull Request 上、提交上或其他地方评论。
要接受或拒绝补丁，维护者**应**使用平台的界面。
维护者**不应该**合并自己的补丁，除非在特殊情况下，例如其他维护者长时间（超过 1-2 天）没有响应。
维护者**禁止**对正确补丁做出价值判断。
维护者**应**快速合并其他贡献者的正确补丁。
贡献者在为某个 Issue 创建 Pull Request 后，**可以**将该 Issue 标记为“就绪”。
创建 Issue 的用户**应该**在检查补丁成功后关闭该 Issue。
维护者**应该**要求改进不正确补丁，如果贡献者没有建设性地回应，则**应该**拒绝不正确补丁。
任何对正确补丁有价值判断的贡献者**应该**通过自己的补丁来表达。
维护者**可以**直接向项目提交对非源代码文档的变更。

创建稳定版本

项目**应**有一个分支（“master”），该分支始终包含最新的正在开发版本，并且**应该**始终能够构建。
项目**禁止**出于任何原因使用主题分支。个人forks**可以**使用主题分支。
要创建稳定版本，某人**应**通过复制仓库来fork仓库，从而成为该仓库的维护者。
为稳定化而fork项目**可以**单方面进行，无需项目维护者的同意。
稳定化项目**应该**按照与主项目相同的流程进行维护。
对声明为“稳定”的稳定化项目的补丁**应**附带可重现的测试用例。

公共契约的演进

所有公共契约（API 或协议）**应**被文档化。
所有公共契约**应该**为可扩展性和实验预留空间。
修改稳定公共契约的补丁**不应该**破坏现有应用程序，除非有压倒性的共识认为这样做有价值。
为公共契约引入新功能的补丁**应该**使用新的名称。
旧名称**应该**以系统的方式弃用，即将新名称标记为“实验性”直到稳定，然后将旧名称标记为“已弃用”。
当足够的时间过去后，旧的已弃用名称**应该**标记为“遗留”，并最终移除。
旧名称**禁止**被新功能重用。
当旧名称被移除时，如果应用程序使用它们，其实现**必须**引发异常（断言）。

项目管理

项目创始人**应**作为管理员管理项目维护者集合。
管理员**应**通过提拔最有效的维护者来确保自己的传承。
做出正确补丁的新贡献者**应**被邀请成为维护者。
管理员**可以**移除长时间不活跃的维护者，或重复未能准确应用此流程的维护者。
管理员**应该**阻止或禁止在项目中给他人带来压力和痛苦的“恶意行为者”。这应该在公开讨论后进行，并给所有各方发言的机会。恶意行为者是指重复无视项目规则和文化、不必要地好辩或敌对、或冒犯他人，并且在被他人要求纠正其行为时无法自纠的人。

实现

ZeroMQ 社区在许多项目中使用 C4 流程。
OSSEC 使用 C4 流程。
Machinekit 社区使用 C4 流程。