为 Node-RED 做贡献

任何贡献的起点都应该是与社区的讨论。我们首选的机制是项目论坛，尽管在 Slack 团队中的讨论也同样有效。这有两个目的：

它能触及广泛的受众，包括那些不是 GitHub 用户的人。
它允许在进一步处理之前，将那些实际上是支持请求或重复项的功能请求过滤掉或进行合理化处理。

一旦社区讨论得出结论，该请求要么被放弃，要么被推进。

对于来自社区成员的功能请求，如果他们无法同时贡献设计或代码，提交者（Committer）会将一个项目添加到 Trello Whiteboard。这个 Whiteboard 作为一个功能积压列表，在确定工作优先级时可以从中提取。

如果一个项目有贡献者来完成工作，下一步将取决于变更的性质。

如果它是一个定义明确且影响有限的功能——比如为一个现有节点添加一个新选项——那么应该在相应的代码仓库中创建一个带有 feature 标签的 issue。该 issue 应提供功能的描述和任何需要的设计要点。然后，这个 issue 可以用来帮助完善提案。该 issue 应明确指出谁在负责这项工作——这是为了避免意外的重复工作，并确保工作有一个焦点。

如果它是一个范围更广的功能，可能需要多个拉取请求（pull-request）来实现，或者对最终用户有较大影响，那么应该在 node-red/designs 仓库中创建一个设计说明。

一旦设计被批准并移至 in-progress（进行中）状态，就应该在相应的代码仓库中创建一个带有 feature 标签的 issue。如果设计确定了该功能有多个交付阶段，则应根据需要为每个阶段创建一个 issue。这些 issue 应引用设计说明。每个 issue 都应该设置一个里程碑（milestone），如果它计划在特定的版本中发布的话。

在某个时候，会有一个拉取请求（pull request）提交上来。它将经过正常的审查流程。提交者社区有责任及时审查 PR。对于任何重大的变更，PR 应该在列表上保留至少 48 小时——考虑到周末和其他假期。这给了所有提交者一个公平的机会来审查 PR，或者至少表明他们希望进行适当的审查，无论他们身处哪个时区。

如果没有未解决的反对意见，提交者将接受该 PR。

如果存在反对意见，提交者之间应达成适当的共识。

一旦与一个 issue 相关的所有 PR 都已解决，该 issue 就可以关闭了。

合并后，相应的功能 issue 应该被关闭。如果有相应的设计说明，其历史记录部分应更新，以反映该项目在何时/何处交付。

拉取请求（Pull-Request）的要求

任何引入代码变更的拉取请求在被接受之前，都应满足以下特定标准：

PR 的所有提交者都必须签署 JS 基金会 CLA。该项目不能接受任何来自未知提交者的变更。
这不应该是项目第一次知道这个贡献。如上所述，任何代码贡献都应该已经与社区讨论过并创建了 Issue。

如果 PR 包含一个错误修复，只要没有争议性的改动，它仍然可以被接受。

如果是一个较大的变更，它可能会被拒绝，直到遵循了正确的贡献流程。虽然我们不想打击贡献的积极性，但我们确实希望避免绕过适当的审查/讨论过程。
构建测试应该能干净地通过；它们会在每个 PR 上自动运行并报告结果。这包括代码风格和 linting，以及单元和功能测试。
变更必须包含适当的测试覆盖率。核心项目的目标是保持超过 90% 的代码覆盖率。如果一个 PR 导致代码覆盖率下降，除非有充分的理由，否则它将被拒绝。

在提交 PR 之前，项目对用于进行代码变更的开发方法论没有任何要求。项目高度重视拥有良好的测试覆盖率和文档。

Git 工作流

在主要项目仓库中，使用以下 git 工作流。

如同传统的 git 工作流一样，不同的活动流使用多个分支。下面描述了我们今天如何使用它。

master - 这个分支包含了 Node-RED 最新发布的版本，以及自那以后所做的任何额外错误修复。在任何时候，这个分支都可能作为下一个维护版本发布。在撰写本文时，它包含了 0.16.2 版本和一些将在某个时候作为 0.16.3 发布的修复。
dev - 这个分支包含了下一个里程碑版本的开发工作。这是开发新功能的地方。
较大的功能在它们自己的分支中进行开发，并在功能足够稳定以便于广泛使用时，合并到开发分支中。

工具

项目使用多种工具来支持其活动。以下列表是当前所用工具及其用途的反映。

论坛

这是项目的主要讨论场所。任何人都可以加入论坛。
Slack

对于活跃的、实时的对话，Slack 可能比论坛更有效率。任何人都可以加入 Slack 团队。#dev 频道用于讨论项目开发。
Trello - 白板（Whiteboard）

用于对想法和功能进行高层级的跟踪。这里是捕捉那些被认为是现有功能增强或更大型“史诗级”项目的积压项的地方。

技术委员会（TC）使用它来为项目提供优先级感。任何人都可以查看该看板。提交者拥有写权限。
Trello - 文档

一个单独的看板用于处理与特定代码变更无关的文档任务。这有助于确保我们为不同类型的用户/开发者/贡献者提供正确的文档。任何人都可以查看该看板。提交者拥有写权限。
GitHub - 代码

项目源代码的版本控制。任何人都可以克隆或 fork 一个仓库；没有私有仓库。提交者可以向仓库应用提交（commit）。
GitHub - issues

报告错误/问题并跟踪功能开发。任何人都可以报告一个 issue。提交者可以“拥有”一个 issue。
GitHub - 拉取请求（pull requests）

这是向仓库贡献任何内容的方式。任何人都可以发起一个拉取请求。其流程有单独描述。
GitHub - wiki

每个仓库都有一个与之关联的 wiki。它们被用作以协作方式开发设计、想法和文档的工作空间。

特别是，核心仓库的 wiki 有一组设计说明页面。这些是开发设计和征求反馈的地方。

Wiki 没有访问控制；任何人都可以进行更改。但更改只应与那些正在积极处理该页面的人合作进行。