はじめに
Rust へのコントリビューションに関心をお寄せいただき、ありがとうございます！ コントリビュートする方法は数多くあり、私たちはそのすべてに感謝しています。
初めてコントリビュートする場合は、walkthrough の章が、典型的なコントリビューションの流れについての良い例になります。
このドキュメントは、網羅的であることを意図したものではありません。 最も有用な事項のクイックガイドとして作られています。 詳細については、 コンパイラをビルドして実行する方法を参照してください。
質問する
質問がある場合は、Rust Zulip サーバーまたは internals.rust-lang.org に投稿してください。 より多くのリソースについては、公式ウェブサイトのチームとワーキンググループの一覧とコミュニティページを参照してください。
念のためお伝えすると、すべてのコントリビューターは私たちの行動規範に従うことが期待されています。
コンパイラチーム（または t-compiler）は通常、Zulip の
#t-compiler チャンネルにいます。
コンパイラがどのように動作するかについての質問は、#t-compiler/help で行えます。
ぜひ質問してください！ 多くの人が「専門家の時間を無駄にしている」と感じると報告していますが、
t-compiler の誰もそのようには感じていません。
コントリビューターは私たちにとって重要です。
また、抵抗がなければ、公開トピックを優先してください。そうすることで他の人も 質問と回答を見ることができ、場合によってはこのガイドへ取り込めるかもしれません :)
ヒント: 英語のネイティブスピーカーではなく、文章を書くことに不安がある場合は、翻訳ツールを使って補助してみてください。 ただし、長く複雑な単語を生成する LLM ツールの使用は避けてください。 日々のチームワークでは、理解しやすくするために シンプルで明確な言葉 が最適です。 小さなタイプミスや文法ミスでさえ、あなたをより人間らしく見せることがあり、人々は人間とのほうがうまくつながれます。
専門家
すべての t-compiler メンバーが rustc のすべての部分の専門家であるわけではありません。
これはかなり大きなプロジェクトです。
コンパイラのさまざまな部分について誰が専門知識を持っていそうかを調べるには、
triagebot の割り当てグループを参照してください。
triagebot.toml ファイル内で [assign* から始まるセクションです。
ただし、誰に ping すればよいか分からない場合でも、遠慮なく質問してください。
コンパイラの特定の部分について専門家を見つけるもう 1 つの方法は、最近コミットした人を確認することです。
たとえば、1.68.2 リリース以降に名前解決に最近取り組んだ人を見つけるには、
git shortlog -n 1.68.2.. compiler/rustc_resolve/ を実行できます。
“Rollup merge” で始まるコミットや @bors によるコミットは無視してください
（これらのコミットの詳細については、CI コントリビューション手順を参照してください）。
エチケット
質問には、できるだけ多くの有用な情報を含めるよう配慮していただきたいですが、 Rust へのコントリビュートに慣れていない場合、これが難しいことも理解しています。
何の文脈も提供せずに誰かに ping するだけだと少し迷惑になることがあり、
ノイズを生むだけにもなり得ます。そのため、t-compiler の人たちは
1 日に多くの ping を受け取っているという事実に配慮していただくようお願いします。
何に取り組むべきですか？
Rust プロジェクトはかなり大きく、プロジェクトのどの部分が支援を必要としているのか、 また初心者にとって良い出発点なのかを知るのは難しい場合があります。 以下に、推奨される出発点をいくつか示します。
簡単な issue またはメンター付きの issue
どこから始めればよいかを探している場合は、次の issue 検索を確認してください。 これらのラベルの説明については、Triage を参照してください。 関心のある分野に検索を絞り込むこともできます。 例:
repo:rust-lang/rust-clippyは clippy の issue のみを表示しますlabel:T-compilerはコンパイラに関連する issue のみを表示しますlabel:A-diagnosticsは診断関連の issue のみを表示します
重要な作業や初心者向けの作業のすべてに issue ラベルが付いているわけではありません。 ラベル付けされていない作業を見つける方法については、以下を参照してください。
繰り返し発生する作業
作業の中には、1 人で行うには大きすぎるものがあります。 この場合、コントリビューター間で作業を調整するために「Tracking issue」を用意するのが一般的です。 大きな時間的コミットメントなしに取り組み始めやすい追跡 issue の例をいくつか示します。
- 繰り返し発生する作業項目をここに追加してください。
繰り返し発生する作業をさらに見つけた場合は、遠慮なくここに追加してください！
Clippy の issue
Clippy プロジェクトは、コントリビューションのプロセスを可能な限り新規参加者にとって親しみやすいものにするため、 長い時間をかけてきました。 プロセスとコンパイラ内部に慣れるために、まずこれに取り組むことを検討してください。
開始方法の手順については、Clippy コントリビューションガイドを参照してください。
診断関連の issue
多くの診断関連の issue は自己完結しており、コンパイラに関する詳細な背景知識を必要としません。 診断関連の issue の一覧はこちらで確認できます。
放棄されたプルリクエストを引き継ぐ
コントリビューターがプルリクエストを送信したものの、後でそれに取り組む十分な時間がないことに気付いたり、
単純にもう関心がなくなったりすることがあります。
そのような PR は最終的にクローズされることが多く、S-inactive ラベルが付けられます。
これらの PR のいくつかを調べて、作業を引き継いでみることができます。
そのような PR の一覧はこちらで確認できます。
その間に PR が別の方法で実装されている場合は、S-inactive ラベルを
削除する必要があります。
そうでなく、変更にまだ関心があるように見える場合は、
最新の main ブランチの上にプルリクエストをリベースし、新しい
プルリクエストを送信して、その機能の作業を続けることができます。
テストを書く
解決済みだが回帰テストがない issue には、E-needs-test ラベルが付けられます。
単体テストを書くことは、リスクが低く、
優先度も低めのタスクであり、新しいコントリビューターがテスト基盤と
コントリビューションワークフローに慣れるための素晴らしい機会を提供します。
needs test issue の一覧はこちらで確認できます。
std（標準ライブラリ）へコントリビュートする
std-dev-guideを参照してください。
他の Rust プロジェクトにコードで貢献する
rust-lang/rust リポジトリ以外にも、cargo、miri、rustup など、貢献できるプロジェクトは数多くあります。
これらのリポジトリには、それぞれ独自のコントリビューションガイドラインや手順がある場合があります。 その多くはワーキンググループによって管理されています。 詳細については、それらのリポジトリの README にあるドキュメントを参照してください。
その他の貢献方法
他にも貢献できる方法は数多くあります。特に、巨大な rust-lang/rust コードベースにいきなり飛び込むことに不安がある場合に有用です。
以下のタスクは、多くの背景知識がなくても実行でき、しかも非常に役立ちます。
- ドキュメントを書く: 少し勇気を出してみたい場合は、 コードの一部を読んで、その doc コメントを書いてみることができます。 これは、有用な成果物を生み出しながら、コンパイラの一部を学ぶ助けになります！
- issue をトリアージする: issue を分類し、再現し、最小化することは、Rust メンテナーにとって非常に役立ちます。
- 作業領域: Rust 関連の多種多様なものについて、多くの作業領域があります。
- users.rust-lang.org や Stack Overflow で質問に回答する。
- RFC プロセスに参加する。
- 要望されているコミュニティライブラリを見つけ、それを構築し、 Crates.io に公開する。 口で言うほど簡単ではありませんが、非常に、非常に価値があります！
クローンとビルド
“コンパイラをビルドして実行する方法”を参照してください。
コントリビューターの手順
このセクションは “コントリビューションの手順” の章に移動しました。
その他のリソース
このセクションは “このガイドについて” の章に移動しました。