メインコンテンツへスキップ

Issue

このドキュメントは、GitHub Issues (issue トリアージとも呼ばれる) をどのように管理するかについてのガイドとして役立ちます。

issue のトリアージを行う際は、最善の判断を下し、何よりもまず、ユーザーに応答する際には **励まし、友好的で、親切** であることを忘れないでください。多くのユーザーは、オープンソースや型付き lint に不慣れです。私たちは彼らにポジティブで、気持ちが高揚するような体験を提供することが不可欠です。

ヒント

issue 管理のどの部分でも不明な点がある場合は、より多くのコンテキストを知っているメンテナーを遠慮なく巻き込んで、助けを求めてください！

ガバナンス​

貢献者ティア > 指摘のスケールに従う

  • 単純なもの: レビュアーの判断で、コミッターまたはメンテナーが承認済みとしてマークできます。これには、ドキュメントの改善、バグ修正、機能追加が含まれます。
  • 単純でないもの: 2 人のコミッターの承認、または 1 人のメンテナーの承認のいずれかで、承認済みとしてマークできます。これには、重要な内部リファクタリングと、非破壊的なパブリック API の変更が含まれます。
  • 「異常」に分類されるもの: パブリックディスカッションを行い、その後 2 人のメンテナーの承認が必要です。これには、プロジェクトを跨ぎ、パブリック API に影響を与える重要なリファクタリングが含まれます。

Issue の流れ​

注

.github/replies.yml には issue に対する一般的な応答セットが含まれており、Refined Saved Replies 拡張機能で使用することを目的としています。これらを必ず使用しなければならない正確な応答として扱わないでください。これらはあくまでコピー＆ペーストを始めるためのヘルパーです。非単純な issue については、特定の応答をあなたの個人的なトーンに合わせ、スレッドに合わせて採用してください。

トリアージ待ちの issue は、triage ラベルで検索できます。新しい issue が作成されると、そのラベルが自動的に追加されます。ほとんどの issue は、作成または更新時に次のレビューフローを経ます。

  1. メンテナーが issue が有効であることを確認します
    • 投稿者が十分な情報を含む適切なテンプレートに記入しなかった場合
      • please fill out the template および awaiting response ラベルを追加し、triage ラベルを削除します
      • 「詳細情報が必要です」という応答を使用して、投稿者に詳細情報を要求します
    • すでに存在する issue の重複である場合
      • duplicate ラベルを追加し、triage ラベルを削除します
      • 明らかに重複している場合は、既存の issue へのリンクを貼った「明らかに重複している Issue」という応答を投稿します
      • 明らかに重複していない場合は、既存の issue へのリンクを貼り、その理由を説明します
      • issue を *計画なし* として閉じます
    • コードが意図したとおりに動作している場合
    • issue に、typescript-eslint 側で実装される可能性が低い、機能強化のようなリクエストが含まれている場合
      • wontfix ラベルを追加し、triage ラベルを削除します
      • クローズコメントの例を含む issue 検索
      • リクエストを満たすための代替案やアプローチがある場合は、それらを提案するとよいでしょう
      • issue を *計画なし* として閉じます
    • issue に、さらなる議論やコミュニティのエンゲージメント評価が必要な場合
      • evaluating community engagement ラベルを追加し、triage ラベルを削除します
  2. レポートが有効な場合は、accepting prs ラベルを追加し、triage ラベルを削除します
  3. 修正の概略手順がわかっている場合は、誰かが修正を作成するのに役立つように、コードベースへのリンクを含むコメントを作成することを検討してください
  4. 修正が比較的簡単だと思う場合は、good first issue ラベルを追加することも検討してください

issue が、報告者がより多くの情報を提供するのを待っている場合は、awaiting response ラベルを付ける必要があります。詳細情報が提供された場合

  • トリアージフローをもう一度やり直す時間がある場合は、そうしてください
  • 時間がない場合は、triage ラベルを追加し、awaiting response ラベルを削除します
ヒント

リンクが「パーマリンク」（ブランチ名の代わりにコミットハッシュを含む）であり、行番号/行範囲がある場合、GitHub はコメントにコードを埋め込みます。GitHub でファイルを表示しているときに y を押すと、URL が現在のコミットハッシュを持つ「パーマリンク」に更新されます。その後、関連する行を選択し、その URL をコメントに貼り付けることができます。

重複の検索​

時折、ユーザーは元の issue が閉じるべきではなかったと感じて、意図的に重複する issue を提起することに注意してください。この場合は、元の issue を読んでコンテキストを収集し、閉じられた理由を理解し、新しい issue が対処する必要のある新しいまたは関連性の高い点を提起しているかどうかを判断する必要があります。

コードが意図したとおりに動作しているかどうかの判断​

コードベースとすべてがどのように機能するかをより深く理解するにつれて、これは直感的に簡単になりますが、最初は、ドキュメント、コード、およびテストを調査して、バグであるか、意図したとおりに動作しているかを判断する必要があります。一般に、再現コードと同じまたは類似の合格テストまたは文書化された例がある場合、それは意図したとおりに動作していることを示します。一致するものが見つからない場合は、コードの精神に基づいて最善の判断を使用してください。

コミュニティのエンゲージメント評価​

ほとんどの場合、メンテナーは人々がどのようにコードを書き、typescript-eslint ツールのほとんどのユーザーが何を望んでいるかについて、かなり良いアイデアを持っています。ただし、メンテナーが特定の問題を解決するための最も合理的なアプローチを自信を持って選択できない場合があります

  • issue の件名が、メンテナーが慣れていないライブラリ/フレームワークに関連しています。したがって、それに関連付けられたイディオム的なパターンを知りません。
  • 新しい構文または新しい機能があります。場合によっては、人々がその機能をどのように使用するかを推測するのが難しいことがあります。
  • issue は閉じられようとしていましたが、誰かが説得力のある主張をしました。これには、ほとんどの人が同意する視点を見つけるためのさらなる議論が必要です。

issue に evaluating community engagement のラベルが付けられてから 3 ～ 6 か月後に、コミュニティのエンゲージメントが評価されます

  • コミュニティが活発で、共通の基盤が見つかった場合、issue に accepting prs のラベルが付けられます
  • そうでない場合、issue は wontfix ラベルを付けて *計画なし* として閉じられます

typescript-eslint の外部で実装できるリクエストについては、カスタムルールなど、使用できる関連する API を必ず言及してください。

ステップのスキップ​

コードベースとその動作について詳しくなると、必要に応じてステップをスキップしたり、順番を無視したりできるようになります。たとえば、バグレポートが「意図したとおりに動作している」かどうかを特定したり、完全に記入された issue がなくても、issue を重複として認識したりできる場合があります。このような場合は、やり取りを省略して、クロージングステップにスキップできます。

特定の issue タイプ​

🐛 バグレポート​

🐞 「単純な」バグ​

シンプルなバグとは、単一のTSファイルとESLint設定（および場合によってはTSConfig）で再現できるバグのことです。つまり、私たちのプレイグラウンドで再現可能な問題です。ほとんどのバグレポートがこのカテゴリに該当します。

問題で提供されたプレイグラウンドでの再現を使用して説明どおりに問題を再現できない場合、十分な情報が提供されていません。プレイグラウンドでの再現が必要などの特定な応答を使用することを検討してください。

🦟 「複雑な」バグ​

複雑なバグとは、再現に複数のファイルが必要なバグのことです。これはまれなケースですが、ライブラリの型を使用している場合や、型がインポートされるときに問題が発生する場合に発生します。

これらのバグは、問題を再現するためにチェックアウトできるGitHubリポジトリへのリンクとともに報告する必要があります。リポジトリのREADME.mdと問題の説明を使用して説明どおりに問題を再現できない場合、十分な情報が提供されていません。完全な再現が必要などの特定な応答を使用することを検討してください。

🏗 機能リクエスト​

機能リクエストを行う場合は、リクエストされたサポートが次のいずれかであることを確認してください。

  • 少なくとも1つの一般的なTypeScriptの実行方法（例：tscでビルドされたCLIパッケージ、バンドラーで管理されるWebアプリ）にとって非常に役立つ
  • typescript-eslintを使用するほとんどのプロジェクトに関連する

次の機能を避けます

  • ごく一部のユーザーにのみ関連し、メンテナンスの負担に見合わない可能性が高いもの
  • TypeScript固有ではないもの（例：代わりにESLintコアにあるべきもの）
  • JestやReactなど、特定のユーザーランドフレームワークまたはライブラリでのみ関連するもの
  • 「フォーマット」機能用（専用のフォーマッタを別途使用することを強くお勧めします）

✨ ルール拡張​

上記の機能リクエストの基準を満たすルール拡張は一般的に受け入れています。ルール拡張がルールの対象領域を大幅に変更する場合は、代わりに新しいルールにすべきかどうかを検討してください。これを示す一般的な兆候としては、ルールの元の名前が不正確になったり、一部のオプションが古い機能にのみ関連しているなどが挙げられます。

新しいレポートが報告される可能性のある拡張機能は、破壊的な変更と見なされます。これらには2つの一般的な戦略があります。

  • 拡張機能を破壊的な変更として扱い、次のメジャーバージョンまでマージをブロックする
  • 新しいロジックを無効にするオプションを追加する：オプトインの場合は破壊的な変更、オプトアウトの場合は非破壊的な変更
  • 新しいロジックを有効にするオプションを追加する：オプトアウトの場合は破壊的な変更、オプトインの場合は非破壊的な変更

オプションの命名に関する背景については、ルールのオプションの論理的な方向性を標準化できますか？を参照してください。

ルールがターゲットとするノードの種類を制限するための拡張機能については、RFC：ルールオプションとして型または値を指定するための共通形式でブロックされた問題としてマークしてください。

🚀 新しいルール​

上記の機能リクエストの基準を満たす新しいルールは一般的に受け入れています。最大の例外は、@typescript-eslint/ban-typesまたはno-restricted-syntaxでおおよそ実装できるルールです。

古い問題の整理​

時々、awaiting responseのオープンな問題を検索して、忘れられている可能性のある問題を見つけます。1か月以上待機している問題に対する私たちのフローは次のとおりです。

  1. 確認中テンプレートのようなメッセージで作成者にPingを送信する
  2. staleラベルを問題に追加する
  3. 2週間待つ
  4. それでも返信がない場合は、古い問題の整理テンプレートのようなメッセージで問題を閉じる