仓库管理任务¶

这些是团队成员可以执行的 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 中的“Files changed”选项卡并检查更新的文件是否以 docs/en/docs 开头来快速检测。文档的原始版本始终是英文的，所以位于 docs/en/docs 中。
internal: 内部
- 将其用于仅影响仓库管理方式的更改。例如内部依赖项的升级、GitHub Actions 或脚本的更改等。

提示

某些工具（如 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 中的问题已得到回答时，通过点击“Mark as answer”来标记答案。

许多当前的讨论问题都是从旧问题迁移过来的。许多都带有 answered 标签，这意味着它们在作为问题时已得到回答，但现在在 GitHub Discussions 中，无法得知具体回复是什么。

您可以按Questions 类别中未回答的问题进行过滤。