# Apache 项目成熟度模型
## 原文链接
https://community.apache.org/apache-way/apache-project-maturity-model.html
### 翻译：刘天栋 Ted，审核：姜宁 Willem
\\

Apache 项目成熟度模型为评估 Apache 项目社区及其维护的代码库的整体成熟度提供了一个建议框架。虽然该模型专门针对 Apache 软件基金会（ASF）的项目，但其中许多因素适用于任何开源项目。

## 概述
本成熟度模型的目标是以简洁、高层次的方式描述阿帕奇项目是如何运作的，并提供一个基本框架，供项目选择用来评估自己。

它也可以在 ASF 之外使用，适用于希望采用部分或全部这些原则的项目。那些计划在某个时候转入 ASF 的项目可以开始采用这些原则，为转入 ASF 做准备。

它并不描述我们的项目如何运作的所有细节，而是旨在捕捉 Apache 项目的不变量，并在需要时指出其他信息。为了尽可能简明扼要，我们使用脚注来说明不属于核心模型的内容。

与其他成熟度模型相反，我们没有定义分阶段的部分合规水平。成熟的 Apache 项目符合本模型的所有要素，欢迎其他项目采用适合其目标的要素。

请注意，我们在下文中尽量避免使用 "必须 "一词。该模型描述的是一个成熟项目的状态，而不是一套规则。

在 ASF 孵化的项目可能并不符合这一模式的所有部分；但孵化的一个主要目标是拉近项目社区与项目的距离。

我们欢迎在 [comdev 邮件列表](https://lists.apache.org/list.html?[e-mail]) 中提出有关此模型的问题和反馈。

## 1. 代码 CODE

| 代号 | 描述 |
| ---- | ------------------------------------------------------- |
| CD10 | 本项目为免费向公众分发而生产开源软件 |
| CD20 | 容易被公开发现和取得 |
| CD30 | 公开的标准工具，可重复生产的方式来构建 |
| CD40 | 完整历史能透过版本管理系统取得，能被重新创建 |
| CD50 | 透过源代码管理系统明确每一行代码的出处，及其提交者（含第三方）的可信的签字认证 |

## 2. 许可证及版权（著作权）Licenses and Copyright
| 代号 | 描述 |
| ---- | ------------------------------------------------------ |
| LC10 | 代码发布声明引用 Apache 许可证 v2.0 |
| LC20 | 项目代码必须采用和依赖的库，不得产生比 Apache 许可证更多的限制 |
| LC30 | 上述的库也可和开源软件一样的方式取得和使用 |
| LC40 | 提交者受到个人贡献者协议 (Individual Contributor Agreement - ICLA) 的约束，该协议定义了提交者可以提交哪些代码，以及需要辨识非自身的代码 |
| LC50 | 清楚定义和记录本项目生产的一切事物的版权所有权 |

## 3. 发布版 RELEASES
| 代号 | 描述 |
| ---- | ------------------------------------------------------- |
| RE10 | 包含以标准和开放的可读的归档 (archive) 格式分发的源代码 |
| RE20 | 由项目管理委员会批准 (参考 CS10)，以形成基金会的标准举措 |
| RE30 | 经过正式签署及/或分发，并伴随着可靠、能验证该下载项目归档 (archives) 的项目摘要 |
| RE40 | 便利二进制文件 (Convenience binaries ) 可以和源代码一起分发，但不能被视为 Apache 发布版 – 而只是为用户之便利使用而提供，不带任何保证 |
| RE50 | 发布流程需被完整记录，且可被新用户独立地重复制作相同而完整的版本 |

## 4. 质量 QUALITY
| 代号 | 描述 |
| ---- | ------------------------------------------------------- |
| QU10 | 对项目的质量保持开放且诚实的态度。只要能清楚的沟通，不同软件模块有不同层次的质量和成熟是理所当然而且可以接受的 |
| QU20 | 生产高安全性的软件是项目的优先考量 |
| QU30 | 提供完整记录、安全且私密的渠道以报告并回应安全问题 |
| QU40 | 对向下兼容优先考量，也记录不兼容的改动，并提供工具与文档协助用户顺利转移到的新功能 (或特性) |
| QU50 | 对记录在案的 Bug Report 努力地且即时回应 |

## 5. 社区 COMMUNITY
| 代号 | 描述 |
| ---- | ------------------------------------------------------- |
| CO10 | 有一个广为人知的官网，指向所有根据成熟度模型而运营项目所需的信息 |
| CO20 | 欢迎所有怀有信心，尊重他人并能为项目增加价值的贡献者 |
| CO30 | 贡献不仅只是源代码，还包含了文档、建设性的 Bug 报告、建设性的讨论、营销和其他一切能对项目增加价值的行动 |
| CO40 | 努力推动精英治理，并以赋予更多权利和责任给能对项目增加价值的贡献者为目标 |
| CO50 | 清楚记录如何一视同仁地赋予贡献者更多权利，如提交的权限或决策权力 |
| CO60 | 社区根据有决策权成员 (参考 CS10) 的共识来运营。独裁者 (无论是否仁慈) 在项目中不受欢迎 |
| CO70 | 努力并即时地回答用户的问题 |

## 6. 共识 CONSENSUS
| 代号 | 描述 |
| ---- | ------------------------------------------------------ |
| CS10 | 项目维护一个公开的名单：由有决策权的贡献者组成项目管理委员会 (PMC) |
| CS20 | 由 PMC 成员依共识形成决策，并记录与该项目的主要沟通渠道 (如邮件列表)。项目社区的意见会被考量 |
| CS30 | 当讨论不足以形成决策时，有文档记录的投票规则则用来建立共识 |
| CS40 | 项目里, 否决只适用于代码提交，同时需要提出合理的技术解释 |
| CS50 | 所有重要讨论，异步发生并以文字形式记录于该项目的主要沟通渠道 (如邮件列表)。凡是在线下，面对面或私聊讨论而影响该项目者，皆须记录于该渠道 |

> 注：
> 1. 版本发布、成为提交者 (Committer)、成为项目委员会 (PMC) 成员，皆须经过 +1 Binding (具约束力) 投票
> 2. 其它议题可以采取懒人共识 (Lazy Consensus，亦即没人反对即代表通过)
## 7. 独立性 INDEPENDENCE
| 代号 | 描述 |
| ---- | ------------------------------ |
| IN10 | 项目独立于任何公司或组织的影响 |
| IN20 | 贡献者只代表个人，而非任何公司或组织的代表 |