CouchDB 章程

本文件于 2014 年 7 月 31 日由 CouchDB PMC 正式通过。

完整的变更日志可在 GitHub 上获取。

目录

1. 简介

本文件定义了 Apache CouchDB 项目运作的章程。它定义了项目中的 角色和职责，谁有投票权，投票 如何进行，如何解决冲突，以及针对特定 决策类型 的投票规则。

本文件面向所有希望参与项目的人员。如果您是第一次阅读本文件，请先阅读本简介，然后阅读所有加粗的文本以了解章程的摘要。 然后，当您需要更多详细信息时，请阅读加粗文本之后的扩展说明。

CouchDB 是 Apache 软件基金会 (ASF) 的一个项目。Apache CouchDB、CouchDB 和 CouchDB 徽标是 ASF 的商标。项目资源根据 Apache 许可证 2.0 授权给公众。发布以官方签名的源代码存档形式进行。有关基金会的运作和背景，请参阅 ASF 常见问题解答。

CouchDB 遵循一套共同原则，统称为 Apache 之道

• 协作软件开发
• 商业友好型标准许可证
• 始终如一的高质量软件
• 尊重、诚实、基于技术的互动
• 忠实地实施标准
• 安全作为一项强制性功能

我们重视社区胜过代码。一个强大而健康的社区应该是所有参与者都乐于参与且有益的场所。随着时间的推移，健康的社区将产生代码以及与代码相关的一切。

项目的走向和我们做出的决定由您决定。如果您正在 邮件列表 上参与，您有权做出决定。所有关于项目的决定都在邮件列表上做出。没有首席开发人员，也没有任何一个人负责。

任何人都可以订阅公共邮件列表，事实上，我们鼓励您这样做。例如，开发邮件列表不仅仅是为开发人员准备的。它是为所有对项目开发感兴趣的人准备的。欢迎所有人的声音。

最后，使用这些章程来强制执行任何规则的字面意思而不是精神（也称为“规则律师”）是不可接受的行为。

2. 角色和职责

ASF 定义了一组角色，并附带相应的权利和责任。这些角色规定了个人可以在项目中执行哪些任务。角色在以下部分定义。

您的角色是由您的同行授予您的，以表彰您过去对项目的贡献以及您在社区中的信任地位。它与您的工作、您目前的雇主或您目前的活动水平无关。我们对您作为个人感兴趣，我们理解您与项目的互动可能会随着时间的推移而改变。

角色永远不会因为不活跃而被撤销，除非这种不活跃给项目带来了问题。幸运的是，我们的决策过程意味着不活跃很少成为问题。如果 项目管理委员会（或 PMC，见下文 2.4）认为个人不再能够负责任地履行角色职责，则角色将被撤销。

我们理解您在生活中扮演着许多角色。我们使用帽子隐喻来谈论这些角色。例如，您可能戴着工作帽以及几顶 ASF 帽子。我们希望您知道何时戴上合适的帽子，并在与项目互动时以符合基金会利益的方式行事。未能做到这一点是严重的失职。

有时告诉人们你戴着哪顶帽子是个好主意。例如，PMC 主席可能会在非正式的电子邮件中声明他们没有戴着 PMC 主席的帽子，只是为了明确说明这些陈述应该如何解释。

我们希望您以诚信行事。对于一个如此依赖信任的社区来说，这一点非常重要。

2.1. 用户

项目中最重要的参与者是使用我们软件的人。

用户可以通过谈论项目、提供反馈和帮助他人来参与。这可以在 ASF 或其他地方进行，包括积极参与 用户邮件列表、第三方支持论坛、博客和社交媒体。以这种方式参与的用户会自动成为贡献者。

2.2. 贡献者

贡献者是指对社区、项目、文档或代码做出贡献的人。

成为贡献者没有特殊要求。如果您对项目有很棒的想法，您可以立即开始工作。无需征求许可。大多数事情都可以由没有项目特殊权限或地位的贡献者完成。如果您需要访问项目资源来完成工作，可以提供帮助。

对项目做出持续贡献的贡献者可能会被邀请成为提交者。

2.3. 提交者

提交者是指致力于项目的人。作为对他们承诺的回报，他们在某些项目决策中拥有约束性投票权。因此，提交者对项目的持续健康和社区负责。

我们认可许多不同领域的承诺。这些包括但不限于

• 社区（社区管理、票证分类、帮助新用户、活动等）
• 项目（博客、营销、设计、用户体验、品牌等）
• 文档（文档、本地化/国际化等）
• 代码（新功能、错误修复、质量保证、发布管理等）

更多详细信息可在 贡献者指南 中找到。如果您对这些事情中的任何一项感兴趣，我们欢迎您的帮助。

提交者的角色是在基金会级别强制执行的。不幸的是，该词的通常定义——即提交代码的人——可能意味着非编码人员永远不会在项目中获得约束性投票权。我们认为这是一个问题。贡献的形式多种多样。事实上，许多非代码贡献正是项目最需要的。

为了明确这一点，我们选择将提交者定义为致力于项目的人。我们指的是忠诚于项目及其利益。这是一个信任职位，而不是对活动水平的期望。任何支持社区和项目的人都会被视为提交者候选人。

为了方便起见，提交者还被授予对所有公共项目基础设施的写入权限，包括源代码控制存储库、网站、问题跟踪器、维基和博客。社交媒体帐户和其他第三方服务的访问权限将在请求后授予。

所有提交者都必须提交签署的个人贡献者许可协议 (ICLA) 文件。有关基金会级别要求的更多详细信息，请参阅 ASF 常见问题解答。

提交者应协作工作并具备良好的社交技能。这比任何其他类型的技能都重要。我们的提交者构成了我们活跃社区的主体，因此，我们依靠他们来帮助我们构建和维护该社区。

对项目做出持续贡献的提交者可能会被邀请成为项目管理委员会 (PMC) 成员。

2.4. 项目管理委员会

项目管理委员会 (PMC) 负责项目的管理。

在最基本的层面上，PMC 的作用是监督。PMC 必须确保遵守所有相关的章程、政策和程序。这些存在于基金会级别和项目级别。有关更多信息，请参阅 项目事务 页面。

除了此要求之外，PMC 的主要目标是投资于社区的长期福祉。出于这个原因，PMC 最基本的任务之一是招募和管理项目贡献者。我们相信社区的规模、多样性和健康状况对于项目及其社会结构的质量、稳定性和稳健性至关重要。

PMC 的活动包括但不限于

• 项目治理
• 社区管理
• 发布管理
• 遵守法律指南
• 管理机密报告的安全问题
• 品牌和活动协调
• 新闻和分析师关系

PMC 成员比普通社区成员受到更高的标准约束。这包括严格的帽子佩戴、公平的决策和模范行为。人们会向 PMC 成员寻求有关如何行为的线索。重要的是，所有 PMC 成员都应了解他们所承担的责任，并个人致力于改进自己和项目。

虽然安全问题和发布管理是 PMC 的责任，但 PMC 通常将此委托给提交者。

2.5. 主席

项目主席是 PMC 成员，负责基金会级别的行政任务。这不是一个技术领导职位，这意味着主席在普通项目决策中没有特殊发言权。但我们确实认为这是一个文化领导职位。因此，在选举主席时，要考虑文化问题上的立场。

主席由 PMC 选举产生，但由 ASF 董事会通过董事会决议任命。主席是 Apache 软件基金会的一名官员（官方头衔为Apache CouchDB 副总裁），对董事会负责项目的管理。主席是董事会的眼睛和耳朵，并定期向董事会报告项目中的进展情况。

主席对董事会负有主要责任，并有权为 PMC 负责的社区的日常管理制定规则和程序，包括 PMC 本身的组成。

请记住，就像在任何会议中一样，主席是一个协调者，他们在 PMC 中的作用是确保每个人都有机会被听到，并使会议顺利进行。

如果现任主席辞职或主席任期届满，PMC 将举行主席选举。

主席任期为 12 个月。此任期的目的是允许 PMC 成员轮流担任此职位。这并不禁止 PMC 选择同一主席连任。

2.6. 董事会

主席对 ASF 董事会（董事会）负责项目。董事会是 ASF 的九人制法律管理机构，由基金会的 成员 选举产生。董事会负责监督基金会的活动和运作，并负责应用和执行 ASF 章程。

3. 决策

本节解释了我们对决策的处理方式以及我们为使决策尽可能容易而建立的正式结构。

按照优先级递减的顺序，我们更希望通过以下方式做出决定

• 惰性共识 或 RTC
• 讨论引导的共识收集
• 正式投票

我们的目标是建立一个信任的社区，减少邮件列表的流量，并在发生分歧时迅速解决。

所有决策必须在邮件列表上进行。任何在列表之外进行的讨论（例如在 IRC 或当面）都必须在做出任何决定之前提交到列表中。我们有一句谚语：如果不在列表中，它就没有发生。我们采取这种方法是为了让尽可能多的人有机会参与。

决策应在与决策相关的邮件列表中做出。例如，营销决策发生在营销列表上。默认情况下，任何没有特定列表的内容都应在主开发列表中公开进行。任何需要保密的内容将在私有列表中进行。

我们的决策过程旨在减少阻碍。人们会根据时间允许来来去去，这是可以理解的。听取每个人对每个决定的意见是不现实的。有时，这意味着在你离开项目时会做出决定。重新讨论此类决定是合理的，但应尽量减少。

3.1. 惰性共识

当你确信你知道社区希望看到什么发生时，你可以假设你已经获得了许可，并开始工作。我们称之为惰性共识。你不必坚持让大家讨论或批准你的计划，当然也不需要进行投票。只要假设你的计划没问题，除非有人说不行。这适用于第 3.6 节中允许惰性共识的决策类型列表中的任何内容。

“寻求原谅比获得许可更容易。”——格蕾丝·霍珀

大多数操作都是可逆的。只要你在公开场合进行工作，社区就有很多机会提出反对意见。如果有人提出反对意见，你必须准备好撤回你的工作。

惰性共识有两种影响

1. 人们不太可能为了反对而反对
2. 它减少了不必要的讨论量

为了使这正常工作，预计积极的贡献者会关注项目。在更改完成很久之后才提出反对意见，可能需要丢弃或重做大量额外工作。

有时，你可能不确定社区想要什么。如果是这种情况，你可以向相应的邮件列表发布一条包含你打算做的事情的概述的说明。如果 72 小时后没有人反对，你可以安全地假设达成共识，并继续你的计划。

这项政策的一个重要副作用是沉默即同意。不需要讨论，也不需要表达同意。如果你向列表提出建议，没有人回复，这应该被解释为对你想法的默示支持，而不是缺乏兴趣。这可能很难适应，但是我们做事方式的重要组成部分。

3.2. 讨论

如果惰性共识失败（即有人反对），你可以开始讨论，也可以放弃提案。

请尽量尊重人们的时间和注意力。它是一种不可再生资源，也是我们唯一总是需要更多的东西。

提案应解释清楚，并附有充分的理由。分歧应具有建设性，理想情况下应附有替代提案。目标是为项目取得积极成果，而不是说服他人接受你的观点。

如果提案特别有争议，请尝试使其可逆。将提案重新定义为实验（在项目级别或功能级别），并确定评估时间表以及明确的成功和失败标准。这类提案通常更容易达成一致。

如果达成明确的共识，你可以继续进行，无需投票。否则，你应该放弃提案或进行投票。

投票是讨论的失败模式。但这并不意味着你应该避免它。它是一个非常强大的工具，应该用来结束看似无休止的讨论。知道何时结束讨论并进行投票是贡献者可以掌握的最有用的技能之一。

3.3. 投票

投票用于表示对某事物的赞成或反对。

我们通过回复带签名的数字来做到这一点，通常是 +1 或 -1。有时人们选择用更大的数字（例如 +1000）投票来表示强烈的情绪，或者用分数（例如 -0.5）投票来表达支持或反对，而不会有 +1 或 -1 投票的全部权重。为了统计的目的，所有值将被计为 +1、-1 或无。

以下是一些示例投票，以及它们的含义，以及它们在最终投票统计中如何计算

有三种类型的投票：非正式投票、正式投票和否决权。非正式投票是快速了解人们对某事的感觉的一种方式。另一方面，正式投票需要一个批准模型和一个决策类型。有关批准模型、RTC 和技术否决权、RFC、API 更改和弃用以及决策类型的更多详细信息，请参阅以下部分。

所有正式投票必须在具有适当主题标签的电子邮件线程中进行。正式投票可能包含多个待批准的项目，这些项目应明确分开。正式投票通过回复投票邮件进行。正式投票开放至少 72 小时，以便所有积极投票者有时间考虑投票。投票可以根据发起投票者的决定延长开放时间。

对PMC 决策的投票，如果由 PMC 成员投票，则具有约束力。对于所有其他目的，如果由提交者投票，则投票具有约束力。但是，重要的是要记住，列表中的所有参与者都有投票权。鼓励你投票，即使你的投票没有约束力。这是参与项目并帮助告知决策过程的好方法。

无论你是否已经是提交者，都鼓励你使用非正式投票模型进行快速投票或结束讨论。这些投票是非正式的，可以由任何人发起。只有在项目级别的决策中才需要有约束力的投票。

3.4. 批准模型

我们使用三种不同的批准模型进行正式投票:

• RTC（见第 3.5 节）
  • 需要一个有约束力的 +1 票，并且没有否决权
• 惰性多数
  • 需要三个有约束力的 +1 票，并且有约束力的 +1 票多于有约束力的 -1 票
• 惰性 2/3 多数
  • 需要三个有约束力的 +1 票，并且有约束力的 +1 票是约束力的 -1 票的两倍

RTC 仅在代码审查或拉取请求的上下文中使用，并且不需要单独的投票线程。其他每个批准模型都需要一个投票线程。

除了使用 RTC 批准模型外，-1 票永远不会被称为否决权。这是因为单个 -1 票在 RTC 之外永远没有权力阻止投票。

使用哪个批准模型由第 3.6 节中的表格决定。这是项目策略，可以通过修改本文档来更改。

为了选举新的主席，PMC 可以选择使用单一可转让投票 (STV)，它有自己的规则。Apache STeVe 是专门为实现此过程而设计的。

3.5. 审查然后提交和技术否决权

通常，CouchDB 使用审查然后提交 (RTC) 代码协作模型。RTC 允许在单独的功能或错误修复分支上进行工作，并且需要至少一名其他开发人员在将更改提交到发布分支之前审查和批准更改。发布分支是可能从其准备发布的任何分支，例如master、1.6.x 等。这些更改的通知将发送到提交邮件列表，GitHub 讨论将出现在通知邮件列表上。预计社区的其他成员会定期审查这些更改。

对发布分支或master 分支进行的任何更改都是项目的技术决策。如果提交者想反对技术决策，他们可以选择投 -1 票。我们称之为否决权。否决权只能出于技术原因使用。在任何其他情况下，-1 票都不被视为否决权。否决权应谨慎使用，并且仅在仔细考虑后使用。

所有否决权都必须有理由，没有理由的否决权无效。理由的有效性可以受到质疑，结果由投票决定。如果理由有效，则否决权不能被推翻，并且在被投票者撤回之前一直有效。如果你不同意否决权，你必须游说投票者撤回他们的否决权。如果否决权没有被撤回，则必须及时撤回提交。

以下是如何否决权导致代码撤回的示例

• 爱丽丝提交了一个更改
• 鲍勃发现了更改，并意识到这将导致重大问题
• 鲍勃回复提交电子邮件，投 -1 票并附上理由
• 随之而来的是一场讨论，最终达成共识
• 爱丽丝撤回了更改

如果讨论没有达成共识，爱丽丝可以质疑鲍勃理由的有效性。此时，PMC 将对该问题进行投票。如果 PMC 发现理由有效，爱丽丝必须撤回更改或请求鲍勃撤回否决权。如果 PMC 发现理由无效，则否决权无效。

3.6 征求意见 (RFC) 流程

对于 CouchDB 功能的重大更改，已建立了请求意见 (RFC) 流程。RFC 的目的是确保在设计新功能时进行了充分的公开讨论，提案在摘要文档中得到充分体现，并且社区接受该提案。然后，完成的 RFC 模板将成为新功能文档的基础。

该流程是

• 在 开发者邮件列表 上启动一个 [DISCUSS] 线程。详细讨论您的提案，包括哪些模块/应用程序受到影响，任何 HTTP API 添加和弃用，以及安全问题。
• 当社区对方法达成共识时，完成 RFC 模板 并与开发者邮件列表的支持一起完成文档的任何最终修订。
• 在开发者邮件列表上启动 RFC **投票**。根据懒惰多数流程进行投票：至少 3 个 +1 票，并且绑定 +1 票多于绑定 -1 票。

3.7 API 更改和弃用

每当对发布分支或 master 提出的更改以破坏与 CouchDB 发布版本向后兼容的方式删除或更改现有 HTTP API 端点时，建议的更改**必须**在 开发者邮件列表 上公布，并且需要至少 懒惰共识 决定。

此策略并非旨在永久保留 CouchDB 发布版本中 HTTP API 端点的错误，也不应用于断言跨主要版本未记录的、特定于实现的行为的一致性。添加不需要 RFC 的新端点，或不影响向后兼容性的更改，不需要此通知和流程，但仍然强烈建议向开发者邮件列表发布公告。

3.8. 决策类型

本节介绍各种决策类型及其适用的规则。

4. 其他主题

4.1. 主题标签

主题标签是出现在电子邮件主题开头的字符串，例如“[TAG]”。我们使用它们来传达发送的消息类型。

以下是一个使用多个标签的示例主题：

[VOTE] [REVISED] 官方 CouchDB 章程

如果在没有必要标签的情况下启动 VOTE 或 PROPOSAL 线程，其有效性可能会受到质疑。所有其他标签都是可选的。

我们已就以下标签达成一致，但您可以随意创建自己的标签。