为 Express 贡献代码

Express 和 GitHub 上的 expressjs 组织中的其他项目 是 Node.js 基金会 的项目。这些项目受 Node.js 基金会的一般政策和指南以及以下附加指南的约束。

• 技术委员会
• 社区贡献指南
• 合作者指南
• 安全策略和流程

技术委员会

Express 技术委员会由活跃的项目成员组成，负责指导 Express 项目的开发和维护。有关更多信息，请参阅 Express 社区 - 技术委员会。

社区贡献指南

本文档的目标是创建一个贡献流程，该流程

• 鼓励新的贡献。
• 鼓励贡献者保持参与。
• 尽可能避免不必要的流程和官僚主义。
• 创建一个透明的决策过程，使贡献者清楚地了解如何参与决策过程。

词汇表

• 贡献者是指任何创建或评论问题或拉取请求的个人。
• 提交者是贡献者的一部分，他们被授予对存储库的写入权限。
• TC（技术委员会）是一组提交者，代表解决罕见争议所需的专业技术知识。
• 分类者是贡献者的一部分，他们被授予对存储库的分类权限。

记录问题

记录您可能遇到的任何问题或问题。如有疑问，请记录问题，任何关于要包含的内容的附加策略将在回复中提供。唯一的例外是安全披露，应私下发送。

提交者可能会将您引导至另一个仓库，要求您提供更多说明，并在解决问题之前添加适当的元数据。

请保持礼貌和尊重。每个参与者都应遵守项目的行为准则。

贡献

对本仓库中资源的任何更改都必须通过拉取请求进行。这适用于对文档、代码、二进制文件等的任何更改。即使是长期提交者和 TC 成员也必须使用拉取请求。

任何拉取请求都必须经过审查才能合并。

对于非琐碎的贡献，拉取请求应至少保留 36 小时，以确保不同时区内的贡献者有时间进行审查。还应考虑周末和其他节假日，以确保活跃的提交者都有合理的时间参与讨论和审查过程（如果他们愿意）。

每个贡献的默认情况是，只要没有提交者反对，它就会被接受。在审查期间，提交者也可以要求特定贡献者（最精通某个特定领域）在 PR 可以合并之前给出“LGTM”。对贡献没有额外的“签署”流程。一旦解决提交者提出的所有问题，任何提交者都可以将其合并。

如果另一个提交者在拉取请求中提出异议，所有相关的提交者应通过讨论、对拟议更改进行妥协或撤回拟议更改来寻求达成共识，以解决所表达的担忧。

如果贡献存在争议，并且提交者无法就如何合并或是否应合并达成一致，则应将问题升级到 TC。TC 成员应定期讨论待处理的贡献，以便找到解决方案。预计只有极少数问题会被提交到 TC 以寻求解决，而提交者之间的讨论和妥协应该是默认的解决机制。

成为分类员

任何人都可以成为分类员！在 分类过程文档 中了解更多关于成为分类员的过程。

在 expressjs/express 仓库中打开一个问题 以请求分类员角色。声明您已阅读并同意 行为准则 和该角色的详细信息。

这是一个您可以复制粘贴的示例问题内容

Title: Request triager role for <your GitHub username>

I have read and understood the project's Code of Conduct.
I also have read and understood the process and best practices around Express triaging.

I request for a triager role for the following GitHub organizations:

jshttp
pillarjs
express

打开问题后，TC 成员会将您添加到组织请求的 triage 团队中。然后他们会关闭问题。

祝您分类愉快！

成为贡献者

所有贡献非平凡贡献的贡献者都应及时加入，并被添加为贡献者，并被授予对存储库的写入权限。

贡献者应遵循此策略，并继续发送拉取请求，经过适当的审查，并让其他贡献者合并他们的拉取请求。

TC 流程

TC 对升级到 TC 的问题使用“寻求共识”流程。该小组试图找到一个在 TC 成员中没有公开反对意见的解决方案。如果无法达成没有反对意见的共识，则会进行多数票决。还预计 TC 做出的多数决定是通过寻求共识的流程进行的，投票仅作为最后的手段使用。

解决方案可能包括将问题退回给贡献者，并提供有关如何朝着共识方向前进的建议。不期望 TC 会议在该会议期间解决其议程上的所有问题，并且可能更愿意继续在贡献者之间进行讨论。

可以随时添加成员到 TC。任何贡献者都可以提名另一位贡献者加入 TC，TC 使用其标准的寻求共识流程来评估是否添加此新成员。那些没有以大多数其他成员的水平持续参与的成员应辞职。

合作者指南

网站问题

在 https://github.com/expressjs/expressjs.com 中打开 expressjs.com 网站的公开问题。

PR 和代码贡献

• 测试必须通过。
• 遵循 JavaScript 标准样式 和 npm run lint。
• 如果您修复了错误，请添加测试。

分支

将 master 分支用于针对当前发布流的错误修复或次要工作。

对于任何旨在用于 Express 未来版本的代码，请使用相应命名的分支，例如 5.0。

贡献步骤

1. 为要修复的错误或要添加的功能 创建问题。
2. 在 GitHub 上创建你自己的 fork，然后检出你的 fork。
3. 在本地副本中编写代码。最好为每个新问题创建一个分支，虽然不是强制性的。
4. 要运行测试套件，首先通过运行 npm install 安装依赖项，然后运行 npm test。
5. 通过运行 npm run lint 确保代码已进行代码风格检查 - 修复列出的任何问题。
6. 如果测试通过，你可以将更改提交到你的 fork，然后从那里创建一个拉取请求。确保在拉取请求评论中引用你的问题，包括问题编号，例如 #123。

问题是疑问

我们通常会关闭任何含糊不清的问题或与你正在编写的某个应用程序相关的特定问题。在急于发布问题之前，请仔细检查文档和其他参考资料。

有助于查看你的问题的一些事项

• 完整且可运行的 JS 代码。
• 对问题或意外行为的清晰描述。
• 对预期结果的清晰描述。
• 你为自行调试问题所采取的步骤。

如果你发布了一个问题，但没有概述上述内容，或者没有让我们能够轻松理解和重现你的问题，那么它将被关闭。

安全策略和流程

本文档概述了 Express 项目的安全流程和一般策略。

• 报告错误
• 披露政策
• 关于此政策的评论

报告错误

Express 团队和社区认真对待 Express 中的所有安全漏洞。感谢你帮助提高 Express 的安全性。我们感谢你的努力和负责任的披露，并将尽一切努力认可你的贡献。

通过电子邮件联系 Readme.md 文件中的主要维护者来报告安全漏洞。

为了确保及时回复你的报告，请确保整个报告都包含在电子邮件正文中，而不仅仅是在网页链接或附件后面。

主要维护者将在 48 小时内确认你的电子邮件，并在 48 小时内发送更详细的回复，说明处理你的报告的后续步骤。在最初回复你的报告后，安全团队将努力让你了解修复和完整公告的进展情况，并可能要求提供更多信息或指导。

将第三方模块中的安全漏洞报告给维护该模块的人员或团队。

披露政策

当安全团队收到安全漏洞报告时，他们会将其分配给主要处理人员。此人将协调修复和发布流程，包括以下步骤

• 确认问题并确定受影响的版本。
• 审核代码以查找任何潜在的类似问题。
• 为仍在维护的所有版本准备修复程序。这些修复程序将尽快发布到 npm。

关于此政策的评论

如果您对如何改进此流程有任何建议，请提交拉取请求。