参加する

役に立つ貢献は、たいてい誰かが自分の作業で何かに突き当たったところから始まります。ページが想定と違う動きをした。設定がマニュアルに書かれたとおりに働かなかった。ドキュメントの一文が二通りに読めた。手順が、自分にはない権限を前提にしていた。こうしたものは、より良いプロジェクトの材料であり、それを明確に書き残すこと自体が貢献です。

直す必要はありません。期待したこと、実際に起きたこと、どの文書を追っていたかを正確に書いた報告は、修正の内容そのものを伝えるので、変更そのものより役に立つことが少なくありません。

多くの不具合は、ソフトウェアを使っている人が見つけます。そして早く直る報告には、共通する性質があります。それは書式を求めるものではなく、明確な報告のほうが修正までの道が短いからです。

期待したことと、起きたことを書く。 その二つの差が不具合です。「ロケールを変えたのに言語切り替えが英語のままだった」は何かを伝えますが、「サイトが壊れている」は何も伝えません。

どこで起きたかを書く。 サイトが動かしている Foundation の版、関わったページやルート、言語に固有の問題であればその言語。一つの言語だけで起きる不具合は、すべての言語で起きる不具合とは別のものです。

何を変えたかを書く。 新しい Foundation のプロジェクトなのか、手を加えたサイトなのかは重要です。プラットフォーム側の不具合と、その上に作ったサイトの不具合は別の作業で、どちらも報告する価値があります。

メッセージはそのまま引用する。 エラーの文言そのものが原因への最短経路になることが多く、言い換えると特定に必要な部分が失われます。

すでに試したことを書く。 同じ作業を繰り返さずに済み、ドキュメントが本来と違う場所へ導いたことが分かる場合もあります。それはドキュメント側の不具合です。

報告ではなく技術的な作業を提供したい場合、リポジトリにプロジェクトの期待が書かれています。時間を使う前に読む価値があります。コーディングエージェント向けの作業規則、アーキテクチャ文書、検証マニュアルが合わせて、コードの作り方、変更に何を含めるか、検証のゲートが何を証明するかを説明しています。そこには、実装とテストが実際に確認している以上の能力を主張してはならない、というプロジェクトの規則も含まれます。

これらの文書は、コミュニティの憲章ではなく、プロジェクトの保守の規律です。このコードをどう整合的に保つかを述べており、同時に余力についても正直です。レビューするメンテナーの数は多くありません。テストを伴い、解く問題が明確で、無関係な変更を含まない提案のほうが、理解の負担を相手に渡す提案より、はるかに受け入れられやすくなります。