コンテンツへスキップ

リポジトリ管理タスク

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

ヒント

このセクションは、リポジトリを管理する権限を持つチームメンバーのような少数の人にのみ役立ちます。おそらくスキップしても大丈夫でしょう。 😉

...それで、あなたはFastAPIのチームメンバーですか？すごい、あなたはとてもクールです！ 😎

FastAPIを支援する - ヘルプを得るのすべてを、外部の貢献者と同じ方法で支援できます。しかし、それに加えて、あなた（チームの一員として）だけが実行できるタスクがいくつかあります。

ここでは、実行できるタスクの一般的な手順を示します。

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

親切に

まず第一に、親切にしましょう。 😊

チームに追加されたということは、おそらくあなたはとても親切な人でしょうが、それでも言及する価値はあります。 🤓

困難な場合

物事がうまくいっているときはすべてが簡単なので、あまり説明は必要ありません。しかし、物事が困難な場合は、いくつかのガイドラインがあります。

良い面を見つけるようにしてください。一般的に、人々が不親切でなければ、たとえ主要な議題（議論、PR）に同意できなくても、彼らの努力と関心に感謝するようにしてください。プロジェクトに興味を持ってくれたこと、あるいは何かをしようと時間を費やしてくれたことに感謝するだけでよいのです。

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

議論やPRでは、多くの場合、人々は不満を抱き、それをフィルターなしで表します。多くの場合、誇張したり、不平を言ったり、権利を主張したりします。これは決して良いことではありません。そのようなことが起こると、彼らの問題を解決するという私たちの優先順位が下がります。それでも、一呼吸おいて、優しく答えるようにしてください。

辛辣な皮肉や受動的攻撃的なコメントの使用は避けてください。何かが間違っている場合は、皮肉を言うよりも直接的（優しく）である方が良いです。

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

PRを拒否するなど、より困難な会話については、私（@tiangolo）に直接対応を依頼できます。

PRのタイトルを編集する

  • PRのタイトルをgitmojiから絵文字で始めるように編集してください。
    • GitHubコードではなく、絵文字文字を使用してください。したがって、:bug:ではなく🐛を使用してください。これは、リリースノートなど、GitHubの外で正しく表示されるようにするためです。
    • 翻訳には🌐絵文字（「子午線付き地球儀」）を使用してください。
  • タイトルを動詞で始めてください。例えば、Add、Refactor、Fixなど。これにより、タイトルはPRが行うアクションを説明します。例えば、Teleporting wasn't working, so this PR fixes itではなく、Add support for teleportingのようにします。
  • PRのタイトルのテキストを「命令形」で始めるように編集してください。したがって、Adding support for teleportingではなく、Add support for teleportingを使用してください。
  • タイトルが達成する内容を記述するように努めてください。機能である場合は、Create TeleportAdapter classではなく、Add support for teleportingのように記述するように努めてください。
  • タイトルをピリオド（.）で終わらせないでください。
  • PRが翻訳の場合、🌐で始め、次にAdd {language} translation forと、翻訳されたファイルパスを続けます。例：
🌐 Add Spanish translation for `docs/docs/teleporting.md`

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

そのため、適切なPRタイトルはGitHubで見栄えがするだけでなく、リリースノートでも見栄えがします。 📝

PRにラベルを追加する

同じGitHub Actionであるlatest-changesは、PR内の1つのラベルを使用して、このPRを配置するリリースノートのセクションを決定します。

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

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

ヒント

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

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

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

各言語には、言語コードを使用したラベル（例: スペイン語は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が翻訳を追加するMarkdownファイル1つのみを変更していること。
    • または、場合によっては、同じ言語で小さいファイルが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.

///

これは次のように表示されます

助言

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 Discussionを作成してください。

  • 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). 🤓

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

そして、検索リンクを、これから作成される新しい言語ラベル（例：lang-bs）を指すように更新します。

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

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

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

PRをレビューする

PRが何をするか、なぜするのかを説明していない場合は、詳細を尋ねてください。

PRは、解決している特定のユースケースを持つべきです。

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

FastAPI People PRs

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

テストが合格していれば、すぐにマージできます。

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

  • 新しいリンクが正しいカテゴリ（例：「ポッドキャスト」）と言語（例：「日本語」）にあることを確認してください。
  • 新しいリンクは、リストの先頭にあるべきです。
  • リンクURLは機能するはずです（404を返してはいけません）。
  • リンクの内容はFastAPIに関するものであるべきです。
  • 新しい追加にはこれらのフィールドがあるべきです。
    • author：著者の名前。
    • link：コンテンツを含むURL。
    • title：リンクのタイトル（記事、ポッドキャストなどのタイトル）。

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

Dependabot PRs

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

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

GitHub Discussionsの回答にマークを付ける

GitHub Discussionsでの質問に回答があった場合、「回答としてマーク」をクリックして回答をマークします。

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