仓库管理任务¶

这些是由团队成员执行的用于管理 SQLModel 仓库的任务。

提示

本节仅对少数人有用，即具有管理仓库权限的团队成员。您可能可以跳过它。😉

...所以，您是 SQLModel 的团队成员？哇，你太酷了！😎

您可以像外部贡献者一样，在帮助 SQLModel - 获取帮助上帮助解决所有问题。但此外，还有一些只有您（作为团队的一员）才能执行的任务。

以下是您可以执行的任务的通用说明。

非常感谢您的帮助。🙇

友善¶

首先，要友善。😊

如果您被添加到团队，您可能非常友善，但值得一提。🤓

当事情困难时¶

当一切顺利时，一切都会更容易，因此不需要太多说明。但是当事情困难时，这里有一些指导方针。

尝试找到好的一面。一般来说，如果人们没有不友好，请尝试感谢他们的努力和兴趣，即使您不同意主要主题（讨论、PR），也请感谢他们对该项目感兴趣，或者感谢他们花时间尝试做某事。

在文本中传达情感很困难，请使用表情符号来帮助。😅

在讨论和 PR 中，在许多情况下，人们会毫无保留地表达他们的挫败感，在许多情况下会夸大、抱怨、认为自己理所当然等。这真的不好，当这种情况发生时，我们会降低解决他们问题的优先级。但仍然，尝试深呼吸，并温柔地回答他们。

尽量避免使用尖刻的讽刺或潜在的被动攻击性评论。如果有什么不对劲，最好直接（尽量温柔）而不是讽刺。

尽量具体和客观，避免概括。

对于更困难的对话，例如拒绝 PR，您可以要求我 (@tiangolo) 直接处理。

编辑 PR 标题¶

编辑 PR 标题，使其以来自 gitmoji 的表情符号开头。
- 使用表情符号字符，而不是 GitHub 代码。因此，使用 🐛 而不是 :bug:。这样它才能在 GitHub 之外正确显示，例如在发行说明中。
以动词开头标题。例如 Add、Refactor、Fix 等。这样标题就会说明 PR 所做的操作。例如 Add support for teleporting，而不是 Teleporting wasn't working, so this PR fixes it。
编辑 PR 标题的文本，使其以“祈使”语气开头，就像发出命令一样。因此，不要使用 Adding support for teleporting，而使用 Add support for teleporting。
尽量使标题描述它所实现的目标。如果它是一项功能，请尝试描述它，例如 Add support for teleporting 而不是 Create TeleportAdapter class。
不要以句点 (.) 结束标题。

一旦 PR 被合并，GitHub Action (latest-changes) 将使用 PR 标题自动更新最新更改。

因此，拥有一个漂亮的 PR 标题不仅在 GitHub 中看起来不错，而且在发行说明中也看起来不错。📝

向 PR 添加标签¶

同一个 GitHub Action latest-changes 使用 PR 中的一个标签来决定将此 PR 放入发行说明的哪个部分。

请确保您使用 latest-changes 标签列表中的支持标签

breaking：重大更改
- 如果他们更新版本而不更改代码，现有代码将会中断。这种情况很少发生，因此很少使用此标签。
security：安全修复
- 这是用于安全修复，例如漏洞。几乎不会使用它。
feature：功能
- 新功能，添加对以前不存在的事物的支持。
bug：修复
- 以前支持的东西不起作用，而这可以修复它。许多 PR 声称是错误修复，因为用户正在以不支持的意外方式执行某些操作，但他们认为这是默认情况下应该支持的操作。其中许多实际上是功能或重构。但在某些情况下，确实存在错误。
refactor：重构
- 这通常用于不改变行为的内部代码更改。通常它可以提高可维护性，或启用未来的功能等。
upgrade：升级
- 这是指对项目中直接依赖项或额外的可选依赖项的升级，通常在 pyproject.toml 中。因此，这些东西会影响最终用户，一旦他们更新，他们的代码库最终会收到升级。但这不适用于开发、测试、文档等使用的内部依赖项的升级。那些内部依赖项，通常在 requirements.txt 文件或 GitHub Action 版本中，应标记为 internal，而不是 upgrade。
docs：文档
- 文档中的更改。这包括更新文档、修复错别字。但这不包括对翻译的更改。
- 您通常可以通过转到 PR 中的“文件已更改”选项卡并检查更新的文件是否以 docs/en/docs 开头来快速检测它。文档的原始版本始终为英文，因此在 docs/en/docs 中。
internal：内部
- 将此用于仅影响如何管理仓库的更改。例如，内部依赖项的升级、GitHub Action 或脚本的更改等。

提示

某些工具（如 Dependabot）会添加一些标签，例如 dependencies，但请记住，此标签不会被 latest-changes GitHub Action 使用，因此不会在发行说明中使用。请确保添加了上述标签之一。

审查 PR¶

如果 PR 没有解释它做了什么或为什么，请要求提供更多信息。

PR 应该有一个它正在解决的特定用例。

如果 PR 是用于一个功能，它应该有文档。
- 除非这是一个我们想要阻止的功能，例如对我们不希望用户使用的边缘案例的支持。
文档应包括源示例文件，而不是直接在 Markdown 中编写 Python 代码。
如果源示例文件对于 Python 3.8、3.9、3.10 可以有不同的语法，则应该有不同版本的文件，并且它们应该在文档的选项卡中显示。
应该有测试来测试源示例。
在应用 PR 之前，新的测试应该失败。
应用 PR 后，新的测试应该通过。
覆盖率应保持在 100%。
如果您看到 PR 有意义，或者我们讨论过并认为应该接受它，您可以在 PR 之上添加提交以进行调整、添加文档、测试、格式化、重构、删除多余的文件等。
请随时在 PR 中评论以要求提供更多信息、建议更改等。
一旦您认为 PR 准备就绪，请将其移至内部 GitHub 项目中供我审查。

Dependabot PR¶

Dependabot 会创建 PR 来更新多个依赖项，这些 PR 看起来都很相似，但有些比其他的更需要谨慎处理。

如果 PR 是针对直接依赖项的，也就是说，Dependabot 正在修改 pyproject.toml，不要合并它。 😱 请让我先检查一下。很可能需要一些额外的调整或更新。
如果 PR 更新的是内部依赖项，例如修改 requirements.txt 文件或 GitHub Action 版本，如果测试通过，并且发布说明（在 PR 的摘要中显示）没有显示任何明显的潜在破坏性更改，则可以合并它。 😎

标记 GitHub Discussions 回答¶

当 GitHub Discussions 中的问题得到解答时，请单击“标记为答案”来标记答案。

当前许多讨论问题是从旧的问题迁移过来的。许多问题都有 answered 标签，这意味着它们在作为问题时得到了解答，但现在在 GitHub Discussions 中，无法知道消息中的实际回应是什么。

您可以按 Questions 中 Unanswered 的问题筛选讨论。