仓库管理任务¶

以下是团队成员管理 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 声称是 bug 修复，因为用户以一种非预期的方式（不受支持）做某事，但他们认为这应该是默认支持的。其中许多实际上是功能或重构。但在某些情况下确实存在实际的 bug。
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 PRs¶

Dependabot 将创建 PR 以更新多个方面的依赖项，这些 PR 看起来都很相似，但有些比其他更微妙。

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

标记 GitHub 讨论答案¶

当 GitHub Discussions 中的问题已回答时，点击“标记为答案”来标记答案。

当前许多讨论问题都是从旧问题迁移过来的。许多问题都有 answered 标签，这意味着它们在作为问题时已得到回答，但现在在 GitHub Discussions 中，尚不清楚消息中的实际回复是什么。

你可以按未回答的问题类别筛选讨论。