为 Express 做贡献

Express 是一个 OpenJS Foundation 项目，分布在三个 GitHub 组织中：expressjs、pillarjs 和 jshttp。欢迎所有贡献，无论是报告漏洞、改进文档还是提交代码。以下指南描述了项目的运作方式以及你如何参与其中。

🌐 Express is an OpenJS Foundation project spread across three GitHub organizations: expressjs, pillarjs, and jshttp. All contributions are welcome, whether it’s reporting bugs, improving documentation, or submitting code. The guidelines below describe how the project operates and how you can get involved.

技术委员会

🌐 Technical committee

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

🌐 The Express technical committee consists of active project members, and guides development and maintenance of the Express project. For more information, see Express Community - Technical committee.

社区贡献指南

🌐 Community contributing guide

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

🌐 The goal of this document is to create a contribution process that:

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

词汇

🌐 Vocabulary

• 贡献者是指任何创建或评论问题或拉取请求的个人。
• 提交者是被授予对代码库写入权限的贡献者子集。
• 项目主管是代码库的主要维护者。
• TC（技术委员会） 是由提交者组成的一组团队，代表所需的技术专长来解决罕见的争议。
• 分诊员是指一部分被授予仓库分诊权限的贡献者。

记录问题

🌐 Logging Issues

对于你可能遇到的任何问题或疑问，请记录一个问题。当有疑问时，记录一个问题，并且在回复中会提供关于应包含内容的额外政策。唯一的例外是安全披露，应私下发送。

🌐 Log an issue for any question or problem you might have. When in doubt, log an issue, and any additional policies about what to include will be provided in the responses. The only exception is security disclosures which should be sent privately.

提交者可能会将你引导到另一个存储库，要求提供额外的说明，并在问题得到处理之前添加适当的元数据。

🌐 Committers may direct you to another repository, ask for additional clarifications, and add appropriate metadata before the issue is addressed.

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

🌐 Please be courteous and respectful. Every participant is expected to follow the project’s Code of Conduct.

贡献

🌐 Contributions

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

🌐 Any change to resources in this repository must be through pull requests. This applies to all changes to documentation, code, binary files, etc. Even long term committers and TC members must use pull requests.

未经审查，任何拉取请求都无法合并。

🌐 No pull request can be merged without being reviewed.

对于非微不足道的贡献，拉取请求应至少保持36小时，以确保其他时区的贡献者有时间进行审查。还应考虑周末和其他假期，以确保活跃的提交者如果愿意参与讨论和审查过程，都有合理的时间。

🌐 For non-trivial contributions, pull requests should sit for at least 36 hours to ensure that contributors in other timezones have time to review. Consideration should also be given to weekends and other holiday periods to ensure active committers all have reasonable time to become involved in the discussion and review process if they wish.

每个贡献的默认情况是，只要没有提交者提出异议，就会被接受。在审查过程中，提交者也可能要求在合并 PR 之前，某个在特定字段最有经验的贡献者给出“LGTM”。贡献的落地没有额外的“签署”流程。一旦提交者提出的所有问题都得到解决，任何提交者都可以将其落地。

🌐 The default for each contribution is that it is accepted once no committer has an objection. During a review, committers may also request that a specific contributor who is most versed in a particular area gives a “LGTM” before the PR can be merged. There is no additional “sign off” process for contributions to land. Once all issues brought by committers are addressed it can be landed by any committer.

如果在拉取请求中被另一位提交者提出异议，所有相关的提交者都应通过讨论所表达的关切、对提议变更进行妥协或撤回提议变更的方式，努力达成共识。

🌐 In the case of an objection being raised in a pull request by another committer, all involved committers should seek to arrive at a consensus by way of addressing concerns being expressed by discussion, compromise on the proposed change, or withdrawal of the proposed change.

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

🌐 If a contribution is controversial and committers cannot agree about how to get it to land or if it should land then it should be escalated to the TC. TC members should regularly discuss pending contributions in order to find a resolution. It is expected that only a small minority of issues be brought to the TC for resolution and that discussion and compromise among committers be the default resolution mechanism.

成为分类员

🌐 Becoming a Triager

任何人都可以成为审查员！在审查流程文档中阅读更多关于成为审查员的过程。

🌐 Anyone can become a triager! Read more about the process of being a triager in the triage process document.

目前，任何现有的组织成员都可以提名新的问题分类员。如果你有兴趣成为问题分类员，我们的最佳建议是通过帮助分类问题和拉取请求来积极参与社区活动。同时，我们也建议参与其他社区活动，例如参加 TC 会议和参与 Slack 讨论。如果你觉得自己准备好了，并且一直在帮助分类一些问题，可以联系组织中的活跃成员，询问他们是否愿意支持你。如果他们同意，他们可以创建一个拉取请求来正式提名你。如果对提名有异议，问题分类团队负责与相关人员一起协商并找到解决方案。

🌐 Currently, any existing organization member can nominate a new triager. If you are interested in becoming a triager, our best advice is to actively participate in the community by helping triaging issues and pull requests. As well we recommend to engage in other community activities like attending the TC meetings, and participating in the Slack discussions. If you feel ready and have been helping triage some issues, reach out to an active member of the organization to ask if they’d be willing to support you. If they agree, they can create a pull request to formalize your nomination. In the case of an objection to the nomination, the triage team is responsible for working with the individuals involved and finding a resolution.

如果你有问题或需要指导，也可以联系任何一位组织成员。

🌐 You can also reach out to any of the organization members if you have questions or need guidance.

成为提交者

🌐 Becoming a Committer

所有做出重大且有价值贡献的贡献者应及时入职，被添加为提交者，并获得对仓库的写入权限。

🌐 All contributors who have landed significant and valuable contributions should be onboarded in a timely manner, and added as a committer, and be given write access to the repository.

期望提交者遵循此政策，并继续提交拉取请求，经过适当的审查，然后由其他提交者合并他们的拉取请求。

🌐 Committers are expected to follow this policy and continue to send pull requests, go through proper review, and have other committers merge their pull requests.

TC 流程

🌐 TC Process

TC 对上报给 TC 的问题使用“寻求共识”的流程。该小组尝试找到一个 TC 成员中没有异议的解决方案。如果无法达成没有异议的共识，则会进行多数票表决。还希望 TC 所做的大多数决定是通过寻求共识的流程做出的，而投票仅在作为最后手段时使用。

🌐 The TC uses a “consensus seeking” process for issues that are escalated to the TC. The group tries to find a resolution that has no open objections among TC members. If a consensus cannot be reached that has no objections then a majority wins vote is called. It is also expected that the majority of decisions made by the TC are via a consensus seeking process and that voting is only used as a last-resort.

解决方案可能涉及将问题返回给项目负责人，并提出如何朝着共识前进的建议。通常不期望技术委员会的会议在该会议期间解决其议程上的所有问题，可能更倾向于继续在项目负责人之间进行讨论。

🌐 Resolution may involve returning the issue to project captains with suggestions on how to move forward towards a consensus. It is not expected that a meeting of the TC will resolve all issues on its agenda during that meeting and may prefer to continue the discussion happening among the project captains.

成员可以随时被加入技术委员会（TC）。任何TC成员都可以提名另一位提交者加入TC，TC将使用其标准的共识寻求流程来评估是否添加此新成员。TC将由至少3名活跃成员组成，最多10名。如果TC成员人数少于5名，现有活跃成员应提名新成员。如果TC成员辞职，他们被鼓励（但不要求）提名他人来接替他们的位置。

🌐 Members can be added to the TC at any time. Any TC member can nominate another committer to the TC and the TC uses its standard consensus seeking process to evaluate whether or not to add this new member. The TC will consist of a minimum of 3 active members and a maximum of 10. If the TC should drop below 5 members the active TC members should nominate someone new. If a TC member is stepping down, they are encouraged (but not required) to nominate someone to take their place.

TC 成员将被添加为 Github 组织、npm 组织以及其他资源的管理员，以便有效地履行其角色所需。

🌐 TC members will be added as admin’s on the Github orgs, npm orgs, and other resources as necessary to be effective in the role.

为了保持“活跃”状态，TC成员应在过去12个月内参与活动，并且连续缺席的TC会议不得超过六次。我们的目标是增加参与度，而不是因缺乏参与而惩罚任何人，这一指南应仅用于此目的（例如，用一名活跃的新成员替换不活跃的成员）。未达到此要求的成员应主动辞职。如果TC成员未主动辞职，可以在讨论仓库中提出问题，将其改为不活跃状态。由于不活跃而辞职或被移除的TC成员将被转入不活跃状态。

🌐 To remain “active” a TC member should have participation within the last 12 months and miss no more than six consecutive TC meetings. Our goal is to increase participation, not punish people for any lack of participation, this guideline should be only be used as such (replace an inactive member with a new active one, for example). Members who do not meet this are expected to step down. If A TC member does not step down, an issue can be opened in the discussions repo to move them to inactive status. TC members who step down or are removed due to inactivity will be moved into inactive status.

非活跃状态的成员可以通过自我提名成为活跃成员，前提是技术委员会（TC）的成员数量尚未超过最大限制10人。如果在成员已达最大数量时有活跃成员辞职，他们也将被优先考虑。

🌐 Inactive status members can become active members by self nomination if the TC is not already larger than the maximum of 10. They will also be given preference if, while at max size, an active member steps down.

项目负责人

🌐 Project Captains

Express TC 可以为组织中的各个项目/仓库指定负责人。这些负责人负责成为仓库在技术和社区方面的主要日常维护者。仓库负责人拥有仓库所有权和软件包发布权限。当出现冲突时，尤其是涉及整个 Express 项目的问题，负责人有责任将其上报给 TC 并推动这些冲突的解决。负责人还需确保社区成员遵守社区指南，维护仓库和已发布的软件包，并提供用户支持。

🌐 The Express TC can designate captains for individual projects/repos in the organizations. These captains are responsible for being the primary day-to-day maintainers of the repo on a technical and community front. Repo captains are empowered with repo ownership and package publication rights. When there are conflicts, especially on topics that effect the Express project at large, captains are responsible to raise it up to the TC and drive those conflicts to resolution. Captains are also responsible for making sure community members follow the community guidelines, maintaining the repo and the published package, as well as in providing user support.

像 TC 成员一样，Repo 队长是提交者的一个子集。

🌐 Like TC members, Repo captains are a subset of committers.

要成为一个项目的负责人，候选人需要在提出申请前至少以贡献者身份参与该项目6个月。他们应该参与代码贡献以及问题分类。此外，他们还需要在他们的 GitHub 和 npm 账户上启用双因素认证（2FA）。

🌐 To become a captain for a project the candidate is expected to participate in that project for at least 6 months as a committer prior to the request. They should have helped with code contributions as well as triaging issues. They are also required to have 2FA enabled on both their GitHub and npm accounts.

任何 TC 成员或同一个仓库的现任负责人都可以提名另一位提交者担任负责人的角色。要做到这一点，他们应当向此文档提交一个 PR，在保持排序顺序的同时，更新活跃项目负责人部分，并包含项目名称、被提名人的 GitHub 账号以及他们的 npm 用户名（如果不同）。

🌐 Any TC member or an existing captain on the same repo can nominate another committer to the captain role. To do so, they should submit a PR to this document, updating the Active Project Captains section (while maintaining the sort order) with the project name, the nominee’s GitHub handle, and their npm username (if different).

• 仓库可以根据工作范围拥有尽可能多的负责人。
• 同一个项目的 TC 成员或现有仓库负责人可以提名新的负责人。来自其他项目的仓库负责人不应为不同的项目提名负责人。

该 PR 需要至少获得 2 位 TC 成员的批准，并且需要 2 周的等待时间以允许评论和/或提出异议。当 PR 合并后，TC 成员将把他们添加到合适的 GitHub/npm 组中。

🌐 The PR will require at least 2 approvals from TC members and 2 weeks hold time to allow for comment and/or dissent. When the PR is merged, a TC member will add them to the proper GitHub/npm groups.

活跃项目和负责人

🌐 Active Projects and Captains

该列表可以在 https://github.com/expressjs/discussions/blob/HEAD/docs/contributing/captains_and_committers.md#active-projects-and-members 找到

🌐 The list can be found at https://github.com/expressjs/discussions/blob/HEAD/docs/contributing/captains_and_committers.md#active-projects-and-members

当前倡议负责人

🌐 Current Initiative Captains

该列表可以在 https://github.com/expressjs/discussions/blob/HEAD/docs/contributing/captains_and_committers.md#current-initiative-captains 找到

🌐 The list can be found at https://github.com/expressjs/discussions/blob/HEAD/docs/contributing/captains_and_committers.md#current-initiative-captains

任何职位的非活跃及荣誉退休政策

🌐 Inactivity and Emeritus Policy for Any Role

为了支持项目的健康发展和持续性，鼓励所有在社区中担任角色的个人（如问题分类员、提交者、工作组成员、项目主管或技术委员会成员）保持积极参与。

🌐 To support the health and continuity of the project, all individuals holding a role within the community (such as Triager, Committer, WG member, Project Captain, or TC member) are encouraged to maintain active participation.

不活跃被定义为在项目中缺乏有意义的参与——例如贡献、代码审查、问题分流、会议出席或讨论参与——持续6个月的时间。

🌐 Inactivity is defined as the absence of meaningful involvement in the project—such as contributions, code reviews, triage, meeting attendance, or discussion participation—for a continuous period of 6 months.

例外

🌐 Exceptions

任何人都可以因个人或职业原因请求暂时停止积极参与。在这种情况下，个人应通知相关团队或技术委员会（TC）。在此期间，不活跃政策将暂停，该个人不会被标记为不活跃。

🌐 Anyone may request a temporary leave from active participation due to personal or professional reasons. In such cases, the individual should inform the relevant team or the Technical Committee (TC). During this time, the inactivity policy is paused, and the individual will not be flagged as inactive.

不活动过程

🌐 Inactivity Process

• 如果某人被认为不活跃，该个人可能会被转为反映其过去贡献的荣誉职位。会尽最大努力通知他们此情况。他们可以在准备重新活跃时请求恢复原职。
• 名誉退休身份有助于保留一份清晰的记录，记录那些随着时间推移对项目产生重要影响的贡献者。

问责制

🌐 Accountability

• 技术委员会（TC）以及各包/团队的各自负责人负责评估活动水平，并在与其他相关团队协调的情况下，公平透明地执行此政策。
• 在出现分歧时，可以在技术委员会或适当的团队内通过协商达成共识来讨论和解决该情况。

开发者源代码证书 1.1

🌐 Developer’s Certificate of Origin 1.1

By making a contribution to this project, I certify that:

 (a) The contribution was created in whole or in part by me and I
     have the right to submit it under the open source license
     indicated in the file; or

 (b) The contribution is based upon previous work that, to the best
     of my knowledge, is covered under an appropriate open source
     license and I have the right under that license to submit that
     work with modifications, whether created in whole or in part
     by me, under the same open source license (unless I am
     permitted to submit under a different license), as indicated
     in the file; or

 (c) The contribution was provided directly to me by some other
     person who certified (a), (b) or (c) and I have not modified
     it.

 (d) I understand and agree that this project and the contribution
     are public and that a record of the contribution (including all
     personal information I submit with it, including my sign-off) is
     maintained indefinitely and may be redistributed consistent with
     this project or the open source license(s) involved.

合作者指南

🌐 Collaborator’s guide

网站问题

🌐 Website Issues

https://github.com/expressjs/expressjs.com 上 expressjs.com 网站的未解决问题。

🌐 Open issues for the expressjs.com website in https://github.com/expressjs/expressjs.com.

对于其他由 Express 管理的仓库中的问题（除 expressjs/express 外，所有在 expressjs、pillarjs 或 jshttp 中的内容），务必查看它们的贡献指南以及相应仓库中的已打开问题和 PR。

🌐 For issues in other Express managed repos (everything in expressjs, pillarjs or jshttp other than expressjs/express), be sure to check their contributing guide and open issues and PRs in the appropriate repository.

拉取请求和代码贡献

🌐 PRs and Code contributions

• 测试必须通过。
• 遵循 JavaScript 标准风格 和 npm run lint。
• 如果你修复了一个错误，添加一个测试。

分支

🌐 Branches

使用 master 分支进行错误修复或针对当前发布流的微小工作。

🌐 Use the master branch for bug fixes or minor work that is intended for the current release stream.

使用相应命名的分支，例如 6.x，用于任何计划在 Express 未来版本中发布的内容。

🌐 Use the correspondingly named branch, e.g. 6.x, for anything intended for a future release of Express.

贡献步骤

🌐 Steps for contributing

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

作为问题的问题

🌐 Issues which are questions

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

🌐 We will typically close any vague issues or questions that are specific to some app you are writing. Please double check the docs and other references before being trigger happy with posting a question issue.

有助于让你的问题得到关注的事项：

🌐 Things that will help get your question issue looked at:

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

如果你发布一个问题却没有列出上述项目，或者没有让我们容易理解和复现你的问题，它将被关闭。

🌐 If you post a question and do not outline the above items or make it easy for us to understand and reproduce your issue, it will be closed.

如果你的问题符合上述所有要求，但你认为不需要维护者查看（例如，如果你只是希望社区提供意见），请将其作为讨论话题而不是问题提出。如果你不确定并提出了问题，我们在进行分类时，如果认为这些问题不需要高关注度或维护者的输入，可能会将其移至讨论区。

🌐 If your question meets all of the above requirements but you do not believe it needs to be looked at by the maintainers (for example, if you are just looking for community input) please open it as a discussion topic instead of an issue. If you are unsure and open an issue, we may move it to discussions if we triage them and decide they do not need high visibility or maintainer input.

安全政策与程序

🌐 Security Policies and Procedures

本文件概述了 Express 项目的安全程序和一般政策。

🌐 This document outlines security procedures and general policies for the Express project.

• 报告错误或安全漏洞
• 披露政策
• 关于本政策的评论
• 快速威胁模型

报告错误或安全漏洞

🌐 Reporting a Bug or Security Vulnerability

Express 团队和社区对所有安全漏洞都非常重视。感谢你为提升 Express 及相关项目的安全性所做的努力。我们感谢你在负责任披露中的付出，并将尽一切努力认可你的贡献。

🌐 The Express team and community take all security vulnerabilities seriously. Thank you for improving the security of Express and related projects. We appreciate your efforts in responsible disclosure and will make every effort to acknowledge your contributions.

一名安全分流团队成员或仓库负责人会尽快确认你的报告。当我们的分流志愿者休假时，尤其是在年底，这些时间可能会延长。

🌐 A Security triage team member or the repo captain will acknowledge your report as soon as possible. These timelines may extend when our triage volunteers are away on holiday, particularly at the end of the year.

在对你的报告做出初步回复后，安全团队将努力让你了解修复进展和完整公告的情况，可能会要求提供额外的信息或指导。

🌐 After the initial reply to your report, the security team will endeavor to keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance.

通过 GitHub 安全咨询报告安全漏洞（首选）

🌐 Reporting Security Bugs via GitHub Security Advisory (Preferred)

报告安全漏洞的首选方式是通过GitHub 安全通告。这使我们能够在保持报告机密性的同时协作修复问题。

🌐 The preferred way to report security vulnerabilities is through GitHub Security Advisories. This allows us to collaborate on a fix while maintaining the confidentiality of the report.

报告漏洞 (文档)：

🌐 To report a vulnerability (docs):

1. 访问受影响仓库在 GitHub 上的 安全 标签页。
2. 点击 报告漏洞 并按照提供的步骤操作。

此过程适用于 Express 生态系统内的任何存储库。如果你不确定某个存储库是否属于此政策范围，请随时通过电子邮件联系。

🌐 This process applies to any repositories within the Express ecosystem. If you are unsure whether a repository falls under this policy, feel free to reach out via email.

通过电子邮件报告

🌐 Reporting via Email

如果你愿意，你也可以通过发送电子邮件至 express-security@lists.openjsf.org 来报告安全问题。

🌐 If you prefer, you can also report security issues by emailing express-security@lists.openjsf.org.

为了确保及时回复，请直接在电子邮件正文中包含所有相关细节，而不是链接到外部资源或附加文件。

🌐 To ensure a timely response, please include all relevant details directly in the email body rather than linking to external sources or attaching files.

主要维护者将在48小时内确认收到你的电子邮件，并提供一份初步回复，概述下一步的措施。安全团队将持续向你更新进展情况，并可能会请求额外的详细信息。

🌐 The lead maintainer will acknowledge your email within 48 hours and provide an initial response outlining the next steps. The security team will keep you updated on the progress and may request additional details.

第三方模块

🌐 Third-Party Modules

如果安全问题涉及的是一个不在 Express 生态系统内直接维护的第三方模块，请向该模块的维护者报告。

🌐 If the security issue pertains to a third-party module that is not directly maintained within the Express ecosystem, please report it to the maintainers of that module.

披露政策

🌐 Disclosure Policy

当安全团队收到安全漏洞报告时，他们会将其分配给一名主要负责人。此人将协调修复和发布过程，涉及以下步骤：

🌐 When the security team receives a security bug report, they will assign it to a primary handler. This person will coordinate the fix and release process, involving the following steps:

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

对本政策的评论

🌐 Comments on this Policy

如果你有关于如何改进此过程的建议，请提交一个拉取请求。

🌐 If you have suggestions on how this process could be improved please submit a pull request.

快捷威胁模型

🌐 The Express Threat Model

Express 威胁模型定义了框架认为其安全责任的边界。它确定了哪些元素是受信任的（例如开发者、运行环境和应用代码），哪些是非受信任的（例如来自网络连接的数据）。来自受信任元素的问题被认为不在范围内，而 Express 负责安全处理非受信任的数据。

🌐 The Express threat model defines the boundaries of what the framework considers its security responsibility. It establishes which elements are trusted (such as the developer, the runtime environment, and application code) versus untrusted (such as data from network connections). Issues arising from trusted elements are considered out of scope, while Express is responsible for safely handling untrusted data.

许多常见的报告问题超出了 Express 的安全范围，是应用开发者的责任。例如，来自未经清理的用户输入的原型污染、配置不当的静态文件服务，或第三方依赖中的问题。

🌐 Many commonly reported concerns fall outside Express’s security scope and are the responsibility of the application developer. Such as prototype pollution from unsanitized user input, misconfigured static file serving, or issues in third-party dependencies.

有关完整详情，请参见 Express 威胁模型。

🌐 For complete details, see the Express Threat Model.