参与Express项目贡献

Express 是隶属于 OpenJS 基金会的项目，相关代码分散在三个 GitHub 组织：expressjs、pillarjs 与 jshttp。 无论是反馈漏洞、完善文档还是提交代码，我们都欢迎各类贡献。 下述规范说明了项目运作方式以及你的参与途径。

技术委员会

Express 技术委员会由项目在职成员组成，负责统筹 Express 项目的开发与维护工作。 For more information, see Express Community - Technical committee.

社区贡献指南

本文档旨在制定一份贡献

• 鼓励新增贡献。
• 鼓励贡献者持续参与项目。
• 尽可能规避冗余流程与繁琐手续。
• 建立透明的决策流程，明确贡献者参与决策的方式。

术语释义

• 贡献者指创建议题或拉取请求、或是在其下留言评论的任何人。
• 提交者是贡献者中的一部分，拥有仓库的写入权限。
• 项目负责人为对应代码仓库的首席维护者。
• **TC（技术委员会）**由多名提交者组成，具备专业技术能力，负责处理罕见争议问题。
• 问题分类处理者是贡献者的一部分，拥有仓库的问题分类处理权限。

提交问题反馈

如有疑问或遇到问题，均可提交议题。 拿不准时直接提交议题即可，回复中会补充所需填写内容的相关规范。 唯一例外是安全漏洞披露，此类内容需私下提交。

提交者可引导你跳转至其他代码仓库、要求补充说明，并在处理议题前添加相应元数据。

请保持礼貌、友善交流。 所有参与者均须遵守项目行为准则。

代码贡献

本仓库内所有资源修改均须通过拉取请求提交。 该规则适用于文档、代码、二进制文件等全部内容的修改。 即便是资深提交者与技术委员会成员，修改代码也必须提交拉取请求。

所有拉取请求未经评审不得合并。

对于重要改动类贡献，拉取请求至少留置36小时，保障其他时区的贡献者有充足时间完成评审。 同时需兼顾周末与法定节假日，确保在岗提交者若有意参与，都能拥有充裕时间投入讨论与评审工作。

若无提交者提出异议，该贡献默认予以接纳。 评审期间，提交者可指定对应领域的资深贡献者给出 LGTM（核准通过） 评语后，方可合并该拉取请求。 代码合入无需额外签署确认流程。 提交者提出的所有问题整改完毕后，任意一名提交者均可合入该变更。

若有其他提交者对拉取请求提出异议，所有相关提交者应通过沟通商榷、对方案折中调整或撤回变更提案等方式处理分歧，力求达成共识。

若某项贡献存在较大争议，提交者无法就变更能否合入、如何合入达成统一意见，则需将问题上报至技术委员会（TC）裁决。 技术委员会成员需定期研讨待处理的贡献内容，敲定解决方案。 仅极少数争议议题才需交由技术委员会裁定，提交者间沟通协商、折中处理是常规解决方式。

成为问题分拣者

任何人都可以成为问题分拣员！ Read more about the process of being a triager in the triage process document.

目前，项目组织内任一现有成员均可提名新任问题分拣员。 如果你有意成为问题分拣员，我们的建议是积极参与社区，协助梳理问题与拉取请求。 同时也建议参与其他社区活动，例如列席技术委员会会议、在 Slack 群组参与交流讨论。 若你已积累一定的工单分拣实操经验、自认条件成熟，可联系项目在职组织成员，征询对方是否愿意提名举荐你。 若对方同意，可提交拉取请求正式确定提名。 如对提名存有异议，筛选小组负责与相关人员协作并寻求解决方案。

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

成为提交者

所有提交过大量优质贡献的贡献者均应及时纳入团队、聘任为提交者，并授予代码仓库写入权限。

提交者需遵守本规范，持续提交拉取请求、完成规范评审流程，并由其他提交者合并其拉取请求。

技术委员会流程

对于提交至技术委员会的议题，委员会采用「寻求共识」流程处理。 小组力求拿出一项无技术委员会成员提出异议的解决方案。 若无法达成全无异议的共识，则启动多数票决制。 技术委员会的多数决议应当通过寻求共识流程敲定，投票仅作为最终备选方案。

决议可附带推进共识的相关建议，将议题退回项目负责人处理。 技术委员会会议无需在当次会议解决议程内全部议题，可选择交由项目负责人继续研讨。

可随时增补技术委员会成员。 任意一名技术委员会成员均可提名其他提交者加入委员会，委员会将按照常规的寻求共识流程审议是否吸纳该新成员。 技术委员会常设成员最少3人、最多10人。 若技术委员会在册成员不足5人，在职委员需提名新成员。 技术委员会成员离任时，鼓励（非强制）其提名继任人选。

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.

若要保持在职状态，技术委员会成员需在近12个月内参与相关工作，且连续缺席委员会会议不得超过六次。 本准则旨在提升成员参与度，而非对参与不足的人员进行惩处，仅用于如以新任活跃成员替换长期怠职成员等场景。 未达到上述任职要求的委员应当主动卸任。 若相关委员拒不主动卸任，可在讨论仓库新建议题，提请将其转为非在职状态。 因主动离任或履职不足被免去职务的技术委员会成员，将转为非活跃委员身份。

在委员会总人数未超出10人上限的前提下，非活跃委员可通过自荐重新转为在职委员。 若委员会已满员，现有在职成员离任时，非活跃成员拥有优先补位资格。

项目负责人

Express技术委员会可为本组织下各个项目/代码仓库指定项目负责人。 这些负责人作为对应代码仓库的日常核心维护者，全权负责仓库的技术运维与社区相关事务。 仓库负责人拥有对应仓库所有者权限以及软件包发布权限。 出现分歧（尤其是波及整个Express项目的重大事项）时，项目负责人须上报技术委员会，并牵头推动分歧落地解决。 负责人同时负责督促社区成员遵守社区规范、维护代码仓库与已发布软件包，并为用户提供技术支持。

和技术委员会成员一样，仓库负责人从提交者中遴选产生。

拟任项目负责人者，在提出任职申请前，需已以提交者身份参与该项目维护满6个月。 候选人需参与代码提交，并协助问题分类处理工作。 候选人须在其 GitHub 与 npm 账号上均开启双重认证（2FA）。

同一仓库的现任技术委员会成员或仓库负责人，均可提名其他提交者出任仓库负责人。 提名时需针对本文档提交拉取请求（PR），在在职项目负责人板块（保持原有排序不变）补充项目名称、被提名人的GitHub账号，以及其npm用户名（二者不一致时需填写）。

• 各仓库可根据实际工作量灵活设置多名项目负责人。
• 同一项目的技术委员会成员或现任仓库负责人可提名新任项目负责人。 其他项目的仓库负责人无权跨项目提名负责人。

PR 需获得至少两名技术委员会成员批准，且设置两周公示期，用于收集意见与异议。 PR合并后，由一名技术委员会成员将新任负责人添加至对应的GitHub与npm权限分组。

在用项目及负责人

相关清单可查阅链接：https://github.com/expressjs/discussions/blob/HEAD/docs/contributing/captains_and_committers.md#active-projects-and-members

现任专项项目负责人

该人员清单详见链接：https://github.com/expressjs/discussions/blob/HEAD/docs/contributing/captains_and_committers.md#current-initiative-captains

# 任一岗位的闲置及荣誉退休制度

为保障项目良性运转与可持续发展，鼓励社区内所有任职人员（包括问题处理员、提交者、工作组组员、项目负责人或技术委员会成员）保持活跃参与。

连续6个月未开展实质性项目工作（如代码提交、代码评审、问题分类、出席会议或参与研讨）即认定为闲置。

例外情形

任何人因个人或工作原因均可申请暂停履职。 该人员需告知对应工作组或技术委员会（TC）。 在此期间，闲置认定规则暂停生效，该人员不会被标记为闲置。

闲置处理流程

• 若人员被认定为闲置，可转为荣誉任职身份，以此认可其过往贡献。 我方会尽可能通知当事人该变动事宜。 待其准备重新履职时，可申请恢复原有职务。
• 荣誉任职身份可留存曾为项目作出重要贡献的贡献者履历记录。

权责说明

• 技术委员会（TC）与各模块/工作组负责人负责结合相关协作团队，公正、透明地评估人员活跃度并执行本制度。
• 若出现异议，可交由技术委员会或对应工作组研讨并通过协商达成共识予以解决。

开发者来源证明书 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.

协作人员指南

网站相关问题

在 https://github.com/expressjs/expressjs.com 仓库提交 expressjs.com 官网的遗留问题工单。

针对由Express维护的其他代码仓库（expressjs、pillarjs、jshttp组织下除expressjs/express之外的所有项目）相关问题，请先查阅各项目贡献指南，并在对应仓库提交问题单与合并请求。

拉取请求（PR）与代码贡献规范

• 必须通过所有测试。
• 遵循 JavaScript 标准风格 并执行 npm run lint 命令检查代码规范。
• 修复漏洞时，必须补充对应的测试用例。

分支

使用 master 分支处理面向当前发行版本分支的漏洞修复或小型改动工作。

使用同名分支（例如 6.x）处理所有面向 Express 后续版本的开发工作。

贡献步骤

1. 针对你想要修复的漏洞或新增的功能创建一个议题。
2. 在 GitHub 上创建个人复刻仓库，随后检出该复刻仓库。
3. 在本地副本中编写代码。 虽然不是强制性要求，但为你处理的每个新议题创建一个分支是一种良好的实践。
4. 要运行测试套件，首先通过执行 npm install 安装依赖项，然后执行 npm test。
5. 通过执行 npm run lint 确保你的代码通过代码检查 —fix所有列出的问题。
6. 如果测试通过，你可以将你的更改提交到你的复刻仓库中，然后创建一个拉取请求。 务必在拉取请求的评论中带上议题编号（例如 #123）以关联对应的议题。

咨询类议题

我们通常会关闭内容含糊不清或仅针对你个人开发项目的咨询类议题。 在随意提交咨询类议题前，请先仔细查阅文档及其他参考资料。

有助于你的咨询类议题获得审阅的相关事项：

• 完整且可运行的 JavaScript 代码。
• 对问题或非预期行为的清晰描述。
• 对预期结果的清晰描述。
• 你自行执行的调试步骤。

若提交咨询类问题，但未列明上述内容、难以让工作人员理解和复现问题，该议题将会被关闭。

若你的问题满足上述全部条件，但你认为无需项目维护人员介入审阅（例如仅寻求社区意见），请创建讨论帖而非议题。 若拿不准而新建了议题，维护人员在分类处理后，若判定该问题无需高曝光度或官方介入，会将议题迁移至讨论区。

安全策略与处理流程

本文档列明了 Express 项目的安全处理流程与通用规范。

• Reporting a Bug or Security Vulnerability
• Disclosure Policy
• Comments on this Policy
• The Express Threat Model

缺陷或安全漏洞上报

Express 团队与社区高度重视所有安全漏洞问题。 感谢您助力提升 Express 及其相关项目的安全性。 感谢您遵循负责任披露原则提交漏洞，我们会尽全力标注致谢您的贡献。

安全初审组成员（链接：Security triage team member）或仓库负责人（链接：the repo captain）会尽快确认收到你的漏洞报告。 若漏洞初审志愿者休假（尤其年末时段），上述处理时限可能相应顺延。

在初次回复漏洞上报后，安全团队会持续向你同步漏洞修复与正式公告的进展，同时可能会向你索要补充信息或相关说明。

通过 GitHub 安全通告上报安全漏洞（推荐方式）

上报安全漏洞的首选方式是通过 GitHub 安全通告。 该方式便于我们在保密漏洞报告的前提下协作完成漏洞修复。

漏洞上报方式（参考文档：docs）

1. 在 GitHub 上进入受影响仓库的安全标签页。
2. 点击上报漏洞并按照指引步骤操作。

本流程适用于Express生态下的所有代码仓库。 若无法确定对应仓库是否适用本规范，可通过邮件咨询。

通过邮件上报

如需，你也可通过发送邮件至[email protected]来上报安全问题。

如需及时得到回复，请将全部相关信息直接写在邮件正文中，不要使用外链或附件。

项目主维护人员会在48小时内确认收到邮件，并给出初步回复说明后续处理步骤。 安全团队会同步处理进度，并可能需要你补充相关细节。

第三方模块

若该安全问题属于非Express生态直接维护的第三方模块，请向对应模块维护者提交漏洞报告。

披露规范

安全团队收到安全漏洞报告后，会指派一名主要负责人处理。 该负责人统筹修复与发布流程，包含以下步骤：

• 确认问题并确定受影响的版本。
• 审核代码以查找所有潜在的同类问题。
• 为所有仍在维护的版本准备修复方案。 这些修复会尽快发布至npm。

对此规范的意见

如果你对改进该流程有相关建议，请提交拉取请求。

Express 威胁模型划

Express 威胁模型划定了该框架所需承担安全责任的边界范围。 该文档划定了可信主体（如开发者、运行环境、应用代码）与不可信数据源（如网络传输数据）的界定范围。 由可信资源引发的问题不在（框架）负责范围内，而 Express 负责安全处理不可信数据。

很多常见反馈的安全隐患不在 Express 的安全保障范畴内，需要由应用开发者自行负责处理。 例如未经过滤的用户输入导致的原型污染、静态文件服务配置错误，或第三方依赖项中存在的问题。

完整细则请参阅：Express 威胁模型。