公開 Issue ポリシー
GitHub Issues は、ThreadCells のキュレーションされた公開バックログであり、警告、監査、リリースデバッグの記録ではありません。
適格性
公開 Issue は通常、次のすべての条件を満たす必要があります。
- 問題または機会が未解決であること。
- 再現可能であるか、永続的な証拠によって裏付けられていること。
- ユーザー、プロジェクト、信頼性、ドキュメント、または保守性に意味のある影響があること。
- プロジェクトまたはコミュニティにとって、公開追跡が有用かつ実行可能であること。
- 公開しても安全であること。
- 期待される動作または成果が明確であること。
- 具体的な受け入れ基準を記述できること。
決定的な再現が実用的でない場合、永続的な技術的証拠は再現手順の代わりになります。
質問、トラブルシューティング、自由な会話は Discussions Q&A に属します。問題およびユースケースを起点とする初期提案は、Discussions Ideas で検討してください。所見または提案を Issue に移すのは、このポリシーの下で確認済み、具体的、公開して安全、かつ実行可能になった後に限ります。
公開 Issue に含めないもの
次の目的だけで公開 Issue を作成しないでください。
- リポジトリまたはアカウントのオーナーだけが行う管理。
- 認証情報の管理またはプライベートインフラ作業。
- 公開して安全でない認証情報、シークレット、またはセキュリティ詳細。
- 一時的な CI、環境、ネットワーク、または runner のノイズ。
- すでに解決済みの所見。
- 再現可能な根本的問題クラスを伴わない、孤立した runtime 識別子。
- 実証済みの欠陥がなく、安全に動作している警告。
- 定義された問題と成果のない推測的な磨き込み。
- 一時的なリリースまたはデバッグ観測。
- 監査または残存負債調査からの未分類のメモ。
オーナー専用の操作は、コントリビューターのバックログではなく、リポジトリの運用オーナーチャネルに属します。所見が公開 Issue になるのは、適格性ゲートを通過した後だけです。
レポート内容
対応する Issue フォームを使用し、次の構成のうち有用な部分を提供してください。
- 問題／コンテキスト
- 影響
- 現在の動作
- 期待する動作
- 再現または証拠
- 受け入れ基準
- 有用な場合の 非目標
環境またはバージョン情報はレポートに影響する場合にのみ含めてください。ログとスクリーンショットは編集してください。シークレット、認証情報、個人データ、プライベートメッセージ、不必要なプライベートパス、state database、またはターミナル記録は決して含めないでください。
脆弱性およびセキュリティに敏感な所見は、公開 Issue ではなく SECURITY.md の非公開経路を使用する必要があります。
トリアージと重複
提出前にオープンおよびクローズ済みの Issue を検索してください。保守担当者は重複を正規 Issue にリンクし、議論と証拠を分割するのではなく重複としてクローズします。
有用な最小限のラベルセットを使用してください。bug、enhancement、documentation、accessibility、technical-debt は作業を表し、duplicate はトリアージを表します。レポートが適格かを判断する前に、保守担当者が不足する証拠を求める場合があります。
Issue は、受け入れ基準を満たしたとき、正規 Issue と重複するとき、または範囲外、実行可能にできない、もしくはプロジェクト追跡を正当化できなくなった場合に、簡潔な理由とともに not planned としてクローズします。すでに解決済みのレポートは、解決した証拠を指す必要があります。
コントリビューター向けラベル
good first issue は、新規コントリビューターにとって十分なコンテキストと受け入れ基準がある、安全で範囲が限定され、あいまいさの少ない作業にのみ使用してください。help wanted は、外部からのコントリビューションを真に歓迎し、作業が十分に具体化されている場合にのみ使用してください。
重要なセキュリティまたは認証境界、ライフサイクルおよび exactly-once 動作、破壊的操作の安全性、リリース権限、プロバイダー信頼またはリモートコード実行境界、移行、データ整合性は、自動的に初心者向け作業にはなりません。