❤️ Blitz 维护者

除了核心团队，还有两个级别的维护者，如下所述。

成为一个维护者

我们总是需要更多的 1 级维护者！主要要求是你可以在在线交流时表现出同理心。 我们将根据需要对你进行其他具体方向的培训。如果你的时间有限，这是一个很好 的角色，因为你可以花尽可能多的时间而无需承担任何持续的责任（与级别 2 不同 ）

2 级维护者的责任要高很多，所以通常你会在进入 2 级之前花时间作为 1 级维护者 。

如果你有兴趣成为官方维护者，请在 Discord 上联系核心团队成员（Brandon Bayer）！

1 级维护者

1 级维护者对于健康的 Blitz 社区和项目至关重要。他们减轻了核心团队和 2 级维 护者的大量负担，因此后者可以专注于具有长期影响等更高级别的事情。

1 级维护人员的主要职责是：

• 成为 Blitz 社区友好、欢迎的代言人
• issue 分类
• PR 分类
• 监听和回答 Discord 帮助频道
• 跟进分配的问题以确保它们正在处理中
• 跟进正在进行的 PR 以确保它们不会被卡主
• 鼓励社区
• 管理社区

2 级维护者

2 级维护者是项目的骨干。他们是代码的守门员，确保代码质量、正确性和安全性。 他们还促进了快速发展。

2 级维护者的主要职责是：

• 项目特定部分的代码所有权
• 维护和改进他们所拥有的架构
• 最终 PR 审阅
• 合并 PR
• 跟踪和确保公有 PR 的进度

退休

维护者可以随时退出他们的角色，而无须感到羞耻或内疚。只需让核心团队成员知道 即可！

⚠️ 基础知识

维护者是项目的代言人，也是社区的一线接触员。因此，维护者肩负着让人们感到受 欢迎、重视、理解和赞赏的非常重要的责任。

请花时间阅读并理解本文中概述的所有内 容建立欢迎社区指南

一些特别重要的点：

• 感恩： 当有人打开 issue 或 PR 立即表示感谢。这需要努力/时间，我们很 感激。
• 响应性： 在 issue/PR 期间，即使我们不能立即进行全面审阅，也请发表评 论感谢他们并说我们会尽快审阅
• 理解： 在你做出回应之前，确保你准确理解某人在说什么是至关重要的。如 果需要，请尽可能的多提出问题。否则如果有人最后回复说“实际上我在问 X”，那 将非常糟糕。
  • 事实上，无论在 Github 还是在 Discord 中，几乎总是需要至少一个问题才能 做出适当的回应。

资源

• 如何在线提供帮助
• 如何开始代码审阅

Issue 分类

如果一个 bug 被报告：

• 它有足够的信息吗？版本号？日志？可复现的方法？
• 这在之前的版本中已经被修复了嘛？
• 是否有一个已经存在的 issue？

如果一个功能/改变被请求：

• 是否明确要求是什么以及将带来什么好处？
• 这会是 Blitz 的明显优势吗？那么就接受
• 如果不明显，则请核心团队成员或 2 级维护人员进行更多的审阅

行动

1. 新增标签：
   • 新增一个 kind/* 标签
   • 新增一个 scope/* 标签
   • 新增一个 status/* 标签
   • 如果合适的话新增一个 good first/second issue 标签

PR 分类

• 这些改动包含测试了吗？
• 这些改动看起来好吗？确保没有明显的问题

行动

1. 如果需要，可以邀请要求任何更改
2. 否则添加 Github 批准，以便 2 级维护人员知道它已经经过初步审查

最终 PR 审阅和合并（2 级维护者）

作为 2 级维护者，你有责任确保未通过测试的代码和回归永远不会达到 canary 分 支。

1. 确保 PR 代码完全按照预期工作，并且相关代码中没有回归
2. 如果没有被自动化测试完全覆盖，你需要在本地拉取代码并手动验证所有内容 （Github CLI 将会对此很有帮助！）
3. 在 squash & merge 期间：
   1. 将提交标题更改为对公众友好的名称 - 此确切的文案将包含在发行说明中
   2. 在描述中添加提交类型，并包含在括号中，如 (patch)。提交类型：
   • major - 重大的破坏性改变
   • minor - 次要功能添加
   • patch - 补丁、错误修复、性能改进等
   • newapp - 新的应用模板的改动
   • recipe - Blitz 配方的改动
   • example - 更改为示例应用
   • meta - 与 Blitz 仓库/项目相关的内部元更改