コンテンツにスキップ

リポジトリ管理タスク

これらは、チームメンバーがFastAPIリポジトリを管理するために実行できるタスクです。

ヒント

このセクションは、リポジトリを管理する権限を持つチームメンバーというごく一部の人々にとってのみ役立ちます。おそらくスキップしても構いません。😉

...つまり、あなたはFastAPIのチームメンバーなのですね？ すごい、あなたはとてもクールです！😎

FastAPIをサポートする - ヘルプを得るですべてのことに、外部のコントリビューターと同じように貢献できます。さらに、チームの一員であるあなただけが実行できるタスクがいくつかあります。

実行できるタスクの一般的な手順を以下に示します。

ご協力いただきありがとうございます。🙇

優しく

まず第一に、優しくしてください。😊

チームに追加されたのであれば、おそらくあなたはとても優しい人でしょう。しかし、念のため言及しておきます。🤓

困難な場合

物事がうまくいくときはすべてが簡単なので、それほど多くの指示は必要ありません。しかし、物事が困難な場合は、いくつかのガイドラインを以下に示します。

良い面を見つけようと努力してください。一般的に、人々が友好的でない場合を除いて、主要な主題（ディスカッション、PR）に同意しない場合でも、彼らの努力と関心に感謝しようと努めてください。プロジェクトに関心を持ってくれたこと、または何かをしようと時間を費やしてくれたことに感謝するだけでよいのです。

テキストで感情を伝えるのは難しいので、絵文字を使って助けましょう。😅

ディスカッションやPRでは、多くの場合、人々は不満を抱き、フィルターなしにそれを表現し、多くの場合、誇張したり、不満を述べたり、権利を主張したりします。それは本当に良くないことですし、そうなると、問題解決の優先順位が下がります。それでも、呼吸を整え、回答には優しく接するように努めてください。

辛辣な皮肉や受動的な攻撃と受け取れる可能性のあるコメントは避けるように努めてください。何か間違っている場合は、皮肉を言うよりも（優しく）直接的に伝える方が良いでしょう。

できるだけ具体的かつ客観的になるように努め、一般化は避けてください。

例えば、PRを却下するなど、より難しい会話については、私（@tiangolo）に直接処理を依頼することができます。

PRタイトルの編集

  • gitmojiの絵文字でPRタイトルを始めるように編集します。
    • GitHubコードではなく、絵文字を使用してください。したがって、:bug:ではなく🐛を使用してください。これは、リリースノートなど、GitHubの外部で正しく表示されるようにするためです。
    • 翻訳には、🌐絵文字（「子午線付き地球儀」）を使用してください。
  • タイトルを動詞で始めてください。たとえば、Add、Refactor、Fixなど。このようにすると、タイトルはPRが行うアクションを伝えるようになります。例えば、「Add テレポートのサポート」のようにし、「テレポートが機能していなかったので、このPRで修正します」のようにはしないようにします。
  • PRタイトルのテキストを、命令形のように「動詞で始める」ように編集してください。たとえば、Adding support for teleporting の代わりに Add support for teleporting を使用します。
  • タイトルは、何を実現するのかを説明するようにしてください。機能であれば、それを説明するようにしてください。たとえば、Create TeleportAdapter class の代わりに Add support for teleporting のようにします。
  • タイトルをピリオド (.) で終わらせないでください。
  • PRが翻訳に関するものである場合は、🌐 で始め、次に Add {言語} translation for とし、翻訳されたファイルのパスを続けます。例：
🌐 Add Spanish translation for `docs/es/docs/teleporting.md`

PRがマージされると、GitHub Actions (latest-changes) がPRタイトルを使用して、最新の変更を自動的に更新します。

そのため、PRタイトルを適切に記述することは、GitHubで見栄えが良いだけでなく、リリースノートでも見栄えが良くなります。📝

PRにラベルを追加する

同じGitHub Actions latest-changes は、リリースノートのどのセクションにこのPRを配置するかを決定するために、PRの1つのラベルを使用します。

latest-changesのラベルリストからサポートされているラベルを使用してください。

  • breaking: 破壊的変更
    • コードを変更せずにバージョンを更新すると、既存のコードが壊れます。これはめったに起こらないため、このラベルは頻繁に使用されません。
  • security: セキュリティ修正
    • これは、脆弱性などのセキュリティ修正用です。ほとんど使用されることはありません。
  • feature: 機能
    • 新しい機能、以前は存在しなかったものに対するサポートの追加。
  • bug: 修正
    • サポートされていたものが機能せず、これを修正します。ユーザーがサポートされていない予期しない方法で何かを行っているため、バグ修正であると主張する多くのPRがありますが、デフォルトでサポートされるべきだと考えています。これらの多くは実際には機能またはリファクタリングです。しかし、実際にはバグがある場合もあります。
  • refactor: リファクタリング
    • これは通常、動作を変更しない内部コードの変更用です。通常、保守性が向上したり、将来の機能が有効になったりします。
  • upgrade: アップグレード
    • これは、プロジェクトからの直接の依存関係、または追加のオプションの依存関係（通常は pyproject.toml 内）のアップグレード用です。つまり、最終ユーザーに影響を与えるため、更新するとコードベースでアップグレードを受け取ることになります。ただし、これは開発、テスト、ドキュメントなどに使用される内部依存関係のアップグレード用ではありません。これらの内部依存関係（通常は requirements.txt ファイルまたは GitHub Actions のバージョン内）は、upgrade ではなく internal としてマークする必要があります。
  • docs: ドキュメント
    • ドキュメントの変更。これには、ドキュメントの更新、タイプミスの修正が含まれます。ただし、翻訳の変更は含まれません。
    • PRの「Files changed」タブに移動し、更新されたファイルが docs/en/docs で始まるかどうかを確認すると、通常はすぐに検出できます。ドキュメントのオリジナルバージョンは常に英語であるため、docs/en/docs にあります。
  • lang-all: 翻訳
    • 翻訳にはこれを使用します。PRの「Files changed」タブに移動し、更新されたファイルが docs/{言語}/docs で始まるが、docs/en/docs ではないことを確認すると、通常はすぐに検出できます。たとえば、docs/es/docs のように。
  • internal: 内部
    • これは、リポジトリの管理方法にのみ影響する変更に使用します。たとえば、内部依存関係のアップグレード、GitHub Actions またはスクリプトの変更などです。

ヒント

Dependabotなどの一部のツールは、dependencies などのラベルを追加しますが、このラベルは latest-changes GitHub Action では使用されないため、リリースノートでは使用されないことに注意してください。上記のラベルのいずれかが追加されていることを確認してください。

翻訳PRにラベルを追加する

翻訳のPRがある場合は、lang-all ラベルを追加することに加えて、言語のラベルも追加してください。

lang-{言語コード} のように、言語コードを使用した各言語のラベルがあります。たとえば、スペイン語の場合は 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-{言語コード} のラベルが付いていること。
  • PRが1つのMarkdownファイルのみを変更して翻訳を追加していること。
    • または、同じ言語で小さく、人々がレビューした場合は、最大で2つのファイルです。
    • その言語の最初の翻訳である場合は、追加の mkdocs.yml ファイルがあります。これらの場合は、以下の指示に従ってください。
  • PRが追加のまたは不要なファイルを追加していないこと。
  • 翻訳が元の英語ファイルと同様の構造を持っていること。
  • 翻訳が元のコンテンツを変更していないこと。たとえば、明らかな追加のドキュメントセクションなど。
  • 翻訳が異なるMarkdown構造を使用していないこと。たとえば、元のファイルにHTMLタグがない場合に、HTMLタグを追加するなど。
  • 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/{言語コード}/docs/index.md 翻訳ファイルと docs/{言語コード}/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 Discussion を作成してください。

  • 翻訳GitHub Discussions に移動します。
  • タイトル ボスニア語翻訳 (または英語での言語名) を使用して新しいディスカッションを作成します。
  • 説明は以下のようになります
## 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). 🤓

「ボスニア語」を新しい言語で更新します。

また、検索リンクを、作成される新しい言語ラベル（lang-bs など）を指すように更新します。

作成したばかりの新しいディスカッションに、lang-bs のようなラベルを作成して追加します。

次に、PRに戻り、lang-bs、lang-all、および awaiting-review のようなラベルを追加します。

これで、GitHubアクションが自動的に lang-bs ラベルを検出し、このPRがレビュー待ちであることをそのディスカッションに投稿します。

PRをレビューする

PRが何をするのか、またはその理由を説明していない場合は、詳細情報を求めてください。

PRには、解決している特定のユースケースが必要です。

  • PRが機能に関するものである場合、ドキュメントが必要です。
    • ユーザーに使用させたくないコーナーケースのサポートのように、推奨したくない機能でない限り。
  • ドキュメントには、Markdownに直接Pythonを記述するのではなく、ソースのサンプルファイルを含める必要があります。
  • ソースのサンプルファイルにPython 3.8、3.9、3.10で異なる構文を使用できる場合は、ファイルの異なるバージョンを作成し、ドキュメントのタブに表示する必要があります。
  • ソースのサンプルをテストするテストが必要です。
  • PRが適用される前に、新しいテストは失敗する必要があります。
  • PRを適用した後、新しいテストは合格する必要があります。
  • カバレッジは100％を維持する必要があります。
  • PRが理にかなっていると思われる場合、またはそれについて話し合い、受け入れるべきだと考えた場合は、PRの上にコミットを追加して、ドキュメント、テスト、フォーマット、リファクタリング、不要なファイルの削除などを調整できます。
  • PRで自由にコメントして、詳細情報を求めたり、変更を提案したりできます。
  • PRの準備ができたと思ったら、内部GitHubプロジェクトに移動して、私がレビューできるようにしてください。

FastAPI People PR

毎月、GitHub ActionがFastAPI Peopleデータを更新します。これらのPRは、👥 Update FastAPI People のようになります。

テストに合格している場合は、すぐにマージできます。

ユーザーが外部リンクを追加するとき、彼らはこのファイル external_links.yml を編集します。

  • 新しいリンクが正しいカテゴリ（例： "ポッドキャスト"）と言語（例： "日本語"）にあることを確認してください。
  • 新しいリンクは、そのリストの先頭にある必要があります。
  • リンクURLが機能すること（404を返さないこと）を確認してください。
  • リンクの内容はFastAPIに関するものである必要があります。
  • 新しい追加には、次のフィールドが必要です。
    • author: 作成者の名前。
    • link: コンテンツへのURL。
    • title: リンクのタイトル（記事、ポッドキャストなどのタイトル）。

これらすべてを確認し、PRに適切なラベルが付いていることを確認したら、マージできます。

Dependabot PR

Dependabotは、いくつかのものの依存関係を更新するPRを作成します。これらのPRはすべて似ていますが、一部は他のものよりもはるかにデリケートです。

  • PRが直接の依存関係に関するものであり、Dependabotが pyproject.toml を変更している場合は、**マージしないでください**。😱 最初に確認させてください。追加の調整または更新が必要な可能性が高くなります。
  • もしPRが内部依存関係の1つを更新する場合、例えばrequirements.txtファイルを変更したり、GitHub Actionsのバージョンを変更したりする場合、テストがパスしていて、リリースノート（PRの概要に表示される）に明らかな破壊的変更の可能性が示されていなければ、マージして構いません。😎

GitHub Discussionsの回答をマークする

GitHub Discussionsの質問に回答があった場合、「回答としてマーク」をクリックして回答をマークしてください。

未回答の質問でディスカッションをフィルタリングできます。