跳转至

开发 - 存储库管理任务

警告

當前頁面任然沒有此語言的翻譯。 但是你可以幫忙翻譯一下: 貢獻.

这些是团队成员可以执行的管理 FastAPI-Channels 存储库的任务。

Tip

此部分仅对少数人有用，即具有管理存储库权限的团队成员。你可以跳过它。😉

您可以在帮助 FastAPI-Channels 与求助上以与外部贡献者相同的方式提供所有帮助。但此外，有些任务只有您（作为团队的一员）才能执行。

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

非常感谢你的帮助。🙇

友善

首先，要友善一点。😊

如果你被加入团队，你可能会非常友善，但值得一提。🤓

当事情变得困难时

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

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

用文字很难传达情感，可以使用表情符号来帮助。😅

在讨论和公关中，很多情况下，人们会毫无顾忌地表达自己的挫败感，很多情况下会夸大其词、抱怨、自以为是等等。这真的不好，而且当这种情况发生时，我们会降低我们解决他们问题的优先级。但还是要试着呼吸，并温柔地回答问题。

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

尽量做到尽可能具体和客观，避免泛泛而谈。

对于更困难的对话，例如拒绝 PR，您可以直接请我（@YGuang233）处理。

编辑 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 是针对翻译的，请以 🌐 开头，Add {language} translation for 然后是翻译的文件路径。例如：
🌐 Add Spanish translation for `docs/es/docs/teleporting.md`

PR 合并后，GitHub Action (latest-changes) 将根据 PR 标题自动更新 release-notes。

因此，一个好的 PR 标题不仅在 GitHub 上看起来不错，而且在release-notes中也很好看。📝

为 PR 添加标签

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

确保使用受支持的标签 latest-changes list of labels:

  • breaking: 重大变更
    • 如果现有代码在不更改代码的情况下更新版本，则会中断。这种情况很少发生，所以这个标签并不常用。
  • security: 安全修复
    • 这是为了修复安全漏洞。它几乎从来没被使用过。
  • feature: 特征
    • 新功能，增加了对以前不存在的事物的支持。
  • bug: 修复
    • 支持的东西不起作用，这可以修复它。有许多PR声称是错误修复，因为用户以一种不受支持的意外方式做了一些事情，但他们认为这是默认情况下应该支持的。其中许多实际上是功能或重构。但在某些情况下，确实存在一个错误。
  • refactor: 重构
    • 这通常用于更改内部代码，但不会改变行为。通常它可以提高可维护性，或启用未来功能等。
  • upgrade: 升级
    • 这用于升级来自项目的直接依赖项或额外的可选依赖项，通常在 pyproject.toml 中。 因此，对最终用户有影响的事情，一旦更新，他们最终会在代码库中收到升级。但这并不适用于升级用于开发、测试、文档等的内部依赖关系。这些内部依赖关系，通常在 requirements.txt 文件或 GitHub Action 版本中，应标记为 internal, 而不是 upgrade.
  • docs: 文档
    • 文档中的更改。这包括更新文档、修复拼写错误。但它不包括对翻译的更改。
    • 您通常可以通过访问 PR 中 "Files changed" 的 tab 来 检查更新的文件是否以开头 docs/zh/docs. 文档的原始版本始终是简体中文的，因此是docs/zh/docs。
  • lang-all: 翻译
    • 您通常可以通过访问 PR 中 "Files changed" 的 tab 来 检查更新的文件是否以开头 docs/{some lang}/docs 而不是 docs/zh/docs。比如， docs/en/docs。
  • internal: 内部
    • 将其用于仅影响仓库管理方式的更改。例如，内部依赖关系的升级、GitHub Actions或脚本的更改等。

Tip

一些工具，如Dependabot，会添加一些标签，如 dependencies, 但请记住，这个标签 latest-changes GitHub Action 不会使用, 因此，它不会更新 release notes. 请确保添加了latest-changes标签。

Warning

目前不支持提供 简体中文 、繁体中文、 英文 之外的翻译和文档修改PR，没有过多的精力处理这些

Dependabot PRs

Dependabot将创建PR来更新几件事的依赖关系，这些PR看起来都很相似，但有些比其他PR更微妙。

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

标记 GitHub Discussions 答案

当GitHub Discussions讨论中的问题得到回答后，单击"Mark as answer"标记答案。

你可以在 GitHub discussions 中筛选 哪些Questions 还没有被 Unanswered的。

评论