仓库管理任务¶

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

提示

这一部分只对少数人有用，即有权限管理仓库的团队成员。你很可能可以跳过它。😉

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

你可以以与外部贡献者相同的方式帮助完成帮助 FastAPI - 获取帮助中的所有事情。此外，还有一些只有你（作为团队的一部分）才能执行的任务。

以下是你可执行任务的一般说明。

非常感谢你的帮助。🙇

保持友好¶

首先，保持友好。😊

你可能因为被加入团队而一直很友好，但还是值得一提。🤓

遇到困难时¶

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

试着找到好的一面。总的来说，如果人们没有不友好，试着感谢他们的努力和兴趣，即使你不同意主要内容（讨论、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 修复了它）。
编辑 PR 标题的文本，使其以“命令式”开头，就像下达命令一样。所以，用 Add support for teleporting 替代 Adding support for teleporting。
尽量使标题描述其实现的功能。如果是一个特性，试着描述它，例如 Add support for teleporting（添加传送支持）而不是 Create TeleportAdapter class（创建 TeleportAdapter 类）。
不要在标题末尾加上句号（.）。
当 PR 是关于翻译时，以 🌐 开头，然后是 Add {language} translation for，然后是翻译的文件路径。例如

🌐 Add Spanish translation for `docs/docs/teleporting.md`

一旦 PR 合并，GitHub Action（latest-changes）将使用 PR 标题自动更新最新的更改。

因此，拥有一个好的 PR 标题不仅在 GitHub 上看起来不错，在发布说明中也一样。📝

给 PR 添加标签¶

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

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

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

提示

像 Dependabot 这样的某些工具会添加一些标签，例如 dependencies，但请注意，latest-changes GitHub Action 不使用此标签，因此它不会在发布说明中使用。请确保添加了上述标签之一。

给翻译 PR 添加标签¶

当有一个翻译 PR 时，除了添加 lang-all 标签外，还要为该语言添加一个标签。

每个语言都会有一个标签，使用语言代码，例如 lang-{lang code}，例如，lang-es 代表西班牙语，lang-fr 代表法语等。

添加特定的语言标签。
添加 awaiting-review 标签。

awaiting-review 标签是特殊的，仅用于翻译。GitHub Action 会检测到它，然后读取语言标签，并更新管理该语言翻译的 GitHub Discussions，以通知人们有新的翻译需要审阅。

一旦母语人士出现，审查 PR 并批准它，GitHub Action 就会出现并移除 awaiting-review 标签，并添加 approved-1 标签。

这样，我们就可以注意到何时有新的翻译准备就绪，因为它们带有 approved-1 标签。

合并翻译 PR¶

对于西班牙语，由于我是母语者，并且它是一种我熟悉的语言，我会亲自进行最终审查，并在大多数情况下微调 PR，然后再合并。

对于其他语言，请确认

标题符合上述说明。
它具有 lang-all 和 lang-{lang code} 标签。
PR 更改仅一个 Markdown 文件，添加了一个翻译。
- 或者在某些情况下，最多两个文件，如果它们很小，并且经过了人们的审查。
- 如果是该语言的首次翻译，它将有额外的 mkdocs.yml 文件，对于这些情况，请遵循以下说明。
PR 不会添加任何额外的或不必要的文件。
翻译似乎与原始英文文件具有相似的结构。
翻译似乎没有改变原始内容，例如添加了明显的额外文档部分。
翻译不使用不同的 Markdown 结构，例如在原始文件没有 HTML 标签的情况下添加 HTML 标签。
“警告”（admonition）部分，例如 tip、info 等，不被更改或翻译。例如

/// tip

This is a tip.

///

看起来像这样

提示

这是一个提示。

...它可以被翻译成

/// tip

Esto es un consejo.

///

...但需要保留精确的 tip 关键字。如果它被翻译成 consejo，就像

/// consejo

Esto es un consejo.

///

它会将样式更改为默认样式，看起来像

/// consejo

Esto es un consejo.

///

这些不需要翻译，但如果翻译了，它们需要写成

/// tip | consejo

Esto es un consejo.

///

看起来像

consejo

Esto es un consejo.

首次翻译 PR¶

当有一个语言的首次翻译时，它会有一个翻译好的 docs/{lang code}/docs/index.md 文件和一个 docs/{lang code}/mkdocs.yml 文件。

例如，对于波斯尼亚语，它会是

docs/bs/docs/index.md
docs/bs/mkdocs.yml

mkdocs.yml 文件将只包含以下内容

INHERIT: ../en/mkdocs.yml

语言代码通常在 ISO 639-1 语言代码列表中。

无论如何，语言代码应该在 docs/language_names.yml 文件中。

还不会有语言代码的标签，例如，如果是波斯尼亚语，就不会有 lang-bs。在创建标签并将其添加到 PR 之前，请创建 GitHub 讨论

转到 Translations GitHub Discussions
创建一个新的讨论，标题为 Bosnian Translations（或该语言的英文名称）
描述为

## Bosnian translations

This is the issue to track translations of the docs to Bosnian. 🚀

Here are the [PRs to review with the label `lang-bs`](https://github.com/fastapi/fastapi/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+label%3Alang-bs+label%3A%22awaiting-review%22). 🤓

更新“Bosnian”为新语言。

并更新搜索链接以指向将要创建的新语言标签，例如 lang-bs。

创建并为刚刚创建的讨论添加标签，例如 lang-bs。

然后回到 PR，并添加标签，例如 lang-bs，以及 lang-all 和 awaiting-review。

现在 GitHub Action 将自动检测 lang-bs 标签，并在此讨论中发布该 PR 正在等待审查。

审查 PR¶

如果 PR 没有解释其功能或原因，请要求提供更多信息。

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

如果 PR 是关于特性的，应该有文档。
- 除非这是一个我们希望阻止的特性，例如支持一个我们不希望用户使用的边缘情况。
文档应包含源示例文件，而不是直接在 Markdown 中编写 Python。
如果源示例文件可以为不同的 Python 版本具有不同的语法，则应有不同版本的该文件，并在文档中以选项卡形式显示。
应有测试来测试源示例。
在应用 PR 之前，新测试应失败。
应用 PR 后，新测试应通过。
覆盖率应保持在 100%。
如果你认为 PR 有意义，或者我们已经讨论过并认为应该接受它，你可以为 PR 添加提交来微调它，添加文档、测试、格式化、重构、删除额外文件等。
随意在 PR 中发表评论，要求更多信息，提出更改建议等。
一旦你认为 PR 准备就绪，请将其移至内部 GitHub 项目，以便我进行审查。

FastAPI 团队成员 PR¶

每个月，一个 GitHub Action 都会更新 FastAPI 团队成员的数据。这些 PR 看起来像这样：👥 Update FastAPI People。

如果测试通过，你可以立即合并。

外部链接 PR¶

当人们添加外部链接时，他们会编辑这个文件：external_links.yml。

确保新链接属于正确的类别（例如“播客”）和语言（例如“日语”）。
新链接应在其列表的顶部。
链接 URL 应有效（不应返回 404）。
链接内容应与 FastAPI 相关。
新的添加应包含以下字段
- author: 作者姓名。
- link: 内容的 URL。
- title: 链接的标题（文章、播客等的标题）。

在检查完所有这些事项并确保 PR 具有正确的标签后，你就可以合并它了。

Dependabot PR¶

Dependabot 将创建 PR 来更新各种依赖项，这些 PR 都看起来相似，但有些比其他更微妙。

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

标记 GitHub 讨论的回答¶

当 GitHub 讨论中的问题得到解答时，通过点击“标记为已解答”来标记答案。

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