Symfony 核心团队

编辑此页

Symfony 核心团队是由一群开发者组成的，他们决定 Symfony 项目的方向和演进。当社区提出的功能和补丁需要被批准或拒绝时，他们的投票具有决定性作用。

所有 Symfony 核心成员都是长期贡献者，拥有扎实的技术专长，并且已经证明了他们推动项目前进的坚定承诺。

本文档阐述了管理 Symfony 核心团队的规则。这些规则自本文档发布之日起生效，所有 Symfony 核心成员都必须遵守所述规则和协议。

核心团队成员角色

除了作为常规贡献者之外，核心团队成员还应做到：

  • 审查、批准和合并拉取请求；
  • 帮助执行、改进和实施 Symfony 流程和策略；
  • 参与 Symfony 核心团队的讨论（在 Slack 和 GitHub 上）。

核心团队成员职责

核心团队成员是无偿志愿者，因此，不期望他们将任何特定的时间投入到 Symfony 中。他们应该以任何可能的方式帮助项目，从审查拉取请求、编写文档到参与讨论和帮助社区，但他们的参与完全是自愿的，可以根据自己的意愿投入多少时间。

核心组织

Symfony 核心成员分为几个小组。每个成员一次只能属于一个小组。授予某个小组的特权将自动授予所有更高优先级的小组。

Symfony 核心小组，按优先级降序排列如下：

  1. 项目负责人

    • 选举任何其他小组的成员；
    • 合并所有 Symfony 仓库中的拉取请求。

  2. 合并团队

    • 合并主 Symfony 仓库中的拉取请求。

此外，还有其他小组被创建来管理特定主题：

  • 安全团队：管理整个安全流程（分类报告的漏洞、修复报告的问题、协调安全补丁的发布等）；
  • Symfony UX 团队：管理 UX 仓库；
  • 文档团队：管理整个 symfony-docs 仓库。

活跃的核心成员

前核心成员

他们不再是核心团队的成员，但我们非常感谢他们对 Symfony 的所有贡献

核心成员资格申请

大约每年一次，核心团队会讨论邀请新成员的机会。

核心成员资格撤销

Symfony 核心成员资格可能因以下任何原因被撤销：

  • 拒绝遵守本文档中规定的规则和策略；
  • 过去六个月缺乏活动；
  • 故意疏忽或意图损害 Symfony 项目；
  • 根据项目负责人的决定。

代码开发规则

Symfony 项目的开发基于 Symfony 社区任何成员提出的拉取请求。拉取请求的接受或拒绝由 Symfony 核心成员的投票决定。

拉取请求投票策略

  • -1 票必须始终基于技术和客观理由；
  • +1 票不需要理由，除非至少有一张 -1 票；
  • 核心成员可以在拉取请求讨论过程中随意更改他们的投票；
  • 核心成员不允许对他们自己的拉取请求进行投票。

拉取请求合并策略

如果满足以下条件，拉取请求可以被合并：

  • 这是一个小改动；
  • 有足够的时间进行同行评审；
  • 这是一个错误修复，并且至少有两名 合并团队 成员投了 +1 票（如果提交者是合并团队的成员，则只需一名），并且没有核心成员投 -1 票（通过 GitHub 审查或评论）。
  • 这是一个新功能，并且至少有两名 合并团队 成员投了 +1 票（如果提交者是合并团队的成员，则需要另外两名成员），并且没有核心成员投 -1 票（通过 GitHub 审查或评论）。

拉取请求合并流程

所有代码都必须通过拉取请求提交到仓库，除了小改动可以直接提交到仓库。

合并者必须始终使用由项目负责人提供的命令行 gh 工具来合并拉取请求。

当合并拉取请求时，该工具会要求选择一个类别，应按照以下规则选择：

  • Feature：用于新功能和弃用；拉取请求必须合并到开发分支。
  • Bug：仅用于错误修复；在合并较旧但仍在维护的分支时，我们非常保守。阅读维护文档以获取更多信息。
  • Minor：对于所有不更改代码或不需要在 CHANGELOG 文件中列出的内容：错别字、Markdown 文件、测试文件、新的或缺少的翻译等。
  • Security：这是用于安全修复的类别，除了安全团队之外，永远不应使用。

获得正确的类别非常重要，因为它被自动化工具用于在发布新版本时生成 CHANGELOG 文件。

发布策略

项目负责人也是每个 Symfony 版本的发布经理。

Symfony 核心规则和协议修订

本文档中描述的规则可能随时由项目负责人酌情修改。

注意

小改动包括错别字、DocBlock 修复、代码标准违规以及小的 CSS、JavaScript 和 HTML 修改。

本作品，包括代码示例，根据 Creative Commons BY-SA 3.0 许可协议获得许可。
目录
    版本