Data-driven insights

• Issue Metrics GitHub Action をリリースするぜ
• これは、開発者やチームが主要なメトリクスを測定し、プロジェクトに関する貴重な洞察を得るための強力なツールだぜ
• Issue、PR、ディスカッションに関連する重要なメトリクスを任意の期間で簡単に追跡・監視できるようになるぜ
  • メトリクス例：初回レスポンスまでの時間やクローズまでの時間など
• 個人でも小規模チームでも大規模組織でも、プロジェクト全体の健全性・進捗・エンゲージメント測るのに役立つよ

Common use cases

• メンテナー: 適切に注意を払える
  • メンテナは issue や PR に注意を払うことは不可欠
  • メトリクスを使うと、プロジェクトの作業量を明確に把握できる
  • チームがどのように時間と注意を効果的に優先させるかを検討できる
  • 注意が必要な見過ごされているリクエストを強調できる
• ファーストレスポンダー: タイムリーなユーザとコンタクトできる
  • ファーストレスポンダーはユーザが適切な時間内に連絡を受けられるようにすることが仕事の一部
  • アクションを使えば、返信待ちのディスカッションや未解決 issue、レビュー待ちプルリクの数などを追跡できる
  • メトリクス活用で、ハイレベルなレスポンスを維持し、ポジティブなユーザ体験とタイムリーな問題解決を促進できる
• OSPO (Open Source Program Office): オープンソースリクエストの合理化
  • OSPO は会社のポリシーを遵守しながらオープンソースのリリースプロセスを簡単かつ効率的にするのが仕事
  • アクションを使えば、リクエストの数やオープンリクエストとクローズドリクエストの比率、オープンソースのプロセスを完了させるまでにかかる時間に関するメトリクスを得られる
  • メトリクスにより、ワークフローの合理化、応答時間の最適化などを実現でき、オープンソースリリースプロセスを最適化できる
• 製品開発チーム: プルリクエストレビューの最適化
  • 製品開発チームはコードレビュープロセスに大きく依存している
  • アクション活用で、プルリクエストのレビューにかかる時間などのメトリクスを得られる
  • メトリクスにより、レトロスペクティブでデータを振り返り、改善点を特定し、レビュープロセスを最適化できる
  • それにより開発サイクルを加速できる

Setup and workflow integration

• Issue Metrics GitHub Action のセットアップは簡単
• 定期実行が前提
• 既存のワークフローに統合してもいいし、メトリクス追跡専用のワークフローを作成してもいい
• カスタマイズ可能なオプションが豊富
  • GitHub の強力な検索フィルタリングが活用できる
  • すぐに使える設定もあるし、GitHub 内部で活用されてるよ

name: Monthly issue metrics
on:
  workflow_dispatch:
  schedule:
    - cron: '3 2 1 * *'

jobs:
  build:
    name: issue metrics
    runs-on: ubuntu-latest

    steps:

    - name: Get dates for last month
      shell: bash
      run: |
        # Get the current date
        current_date=$(date +'%Y-%m-%d')

        # Calculate the previous month
        previous_date=$(date -d "$current_date -1 month" +'%Y-%m-%d')

        # Extract the year and month from the previous date
        previous_year=$(date -d "$previous_date" +'%Y')
        previous_month=$(date -d "$previous_date" +'%m')

        # Calculate the first day of the previous month
        first_day=$(date -d "$previous_year-$previous_month-01" +'%Y-%m-%d')

        # Calculate the last day of the previous month
        last_day=$(date -d "$first_day +1 month -1 day" +'%Y-%m-%d')

        echo "$first_day..$last_day"
        echo "last_month=$first_day..$last_day" >> "$GITHUB_ENV"

    - name: Run issue-metrics tool
      uses: github/issue-metrics@v2
      env:
        GH_TOKEN: ${{ secrets.GH_TOKEN }}
        SEARCH_QUERY: 'repo:owner/repo is:issue created:${{ env.last_month }} -reason:"not planned"'

    - name: Create issue
      uses: peter-evans/create-issue-from-file@v4
      with:
        title: Monthly issue metrics report
        content-filepath: ./issue_metrics.md
        assignees: <YOUR_GITHUB_HANDLE_HERE>

Ready to start leveling up your GitHub project management?

• さっそく Issue Metrics GitHub Action リポジトリにアクセスして試してみよう
• とりあえず README を見ればいい

得られるメトリクス

よく動かしてるのは korosuke613/zenn-articles なのでまずはここでやってみる

サンプルワークフローがいくつかある

• Calculated Time Example
  • 先月作成された issue を検索し、メトリクスを含む issue を生成
• Fixed Time Example
  • 2023-05-01 から 2023-05-31 の間に作成された issue を検索し、メトリクスを含む issue を生成

2 個しかなかった。
どちらも issue に関するものとなっているが、PR はどうやるのか。

    - name: Run issue-metrics tool
      uses: github/issue-metrics@v2
      env:
        GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        SEARCH_QUERY: 'repo:owner/repo is:issue created:${{ env.last_month }} -reason:"not planned"'

SEARCH_QUERY に is:issue とある。ここら辺を調整すれば良さそう。

実際 README に書いてある。

Edit the values (SEARCH_QUERY, assignees) from the sample workflow with your information.

SEARCH_QUERY は次のようにした。

https://github.com/korosuke613/zenn-articles/blob/9344d610cac98f50e314ad892df1f797a3437806/.github/workflows/monthly-pr-metrics.yaml#L37-L39

プルリク作ったよ。マージした。

ci: add monthly pr metrics report by korosuke613 · Pull Request #398 · korosuke613/zenn-articles

workflow_dispatch で実行。
できあがったのがこれ。

https://github.com/korosuke613/zenn-articles/issues/399

テキストだとこれ。なんか色々出てるぞ！

Issue Metrics

PR のメトリクスなのに Issue Metrics って見出しなの気になるなー
固定されてそう

https://github.com/github/issue-metrics/blob/522cb52272d2f9e3da6327781c2d00ac47bb38bd/markdown_writer.py#L104-L106

Issue タイトルはワークフロー上で調整可能

https://github.com/korosuke613/zenn-articles/blob/9344d610cac98f50e314ad892df1f797a3437806/.github/workflows/monthly-pr-metrics.yaml#L44

あと、個人利用なので assignee は外そう

PR
ci: add monthly pr metrics report by korosuke613 · Pull Request #248 · korosuke613/homepage-2nd

https://github.com/korosuke613/homepage-2nd/issues/249

Renovate の PR が多い。
Renovate がコメントするせいか、Time to first response の値がめちゃ短い。
除外したほうがいいかも？？でも Time to close は計算したい気もする。

再実行したら新しい Issue が生まれた。
利用方法によって違うやろうけど、俺的には Issue たくさん作ってほしくない。

peter-evans/create-issue-from-file アクションは issue-number を設定することで issue の作成ではなく更新となるらしい。

ci: avoid creating new issues by korosuke613 · Pull Request #255 · korosuke613/homepage-2nd

• いろんなデータが出ておもしろい
• どう活用するかはむずそう
  • 個人だと特に
• あくまで生成するのは Markdown なので、Issue を作らずに step summary に出すのもアリ
• でか OSS やプロダクトの場合は結構良さそう

一旦クローズ