feat(tooling): auto-assign reviewers to PRs based on custom ranking

[Carsons-Eels]

🗒️ Description

Add automated reviewer assignment for PRs using a weighted scoring system that considers workload, file familiarity, review recency, PR complexity, and OOO status.

Components:

• .github/scripts/assign_reviewer.py — shared Python script that scores candidates and selects a reviewer
• .github/workflows/assign-reviewer.yaml — auto-assigns a reviewer when a non-draft PR is opened or marked ready
• .github/team.yml — team roster with GitHub usernames and emails
• .claude/commands/reassign-reviewer.md — Claude Code skill for manual re-assignment after fixes

Selection factors (weighted):

• Workload (0.25) — fewer open reviews = higher score
• File familiarity (0.20 most / 0.15 least) — balances expertise with knowledge distribution
• Review recency (0.20) — rotates in people who haven't reviewed recently
• PR complexity match (0.10) — matches experience level to PR difficulty
• OOO/vacation — hard exclude via Google Calendar integration
• Authorship conflict — hard exclude (initial: all branch authors; re-review: only authors who pushed since last review)

Requires repo secrets: STEEL_OOO_URL and STEEL_OOO_KEY for the OOO calendar endpoint.

🔗 Related Issues or PRs

• Related to Look into using CODEOWNERS post-weld #1387 (CODEOWNERS discussion) — this PR is an alternative approach for 1387 that avoids siloing that CODEOWNDERS could breed.
• Related to feat(ci): add auto-merge on approval and merge gate #2253 (auto-merge on approval).

✅ Checklist

• All: PR title adheres to the repo standard - it will be used as the squash commit message and should start type(scope):.
• All: Considered updating the online docs in the ./docs/ directory.
• All: Set appropriate labels for the changes (only maintainers can apply labels).
• All: Ran fast tox checks to avoid unnecessary CI fails, see also Code Standards and Enabling Pre-commit Checks:

  uvx tox -e static

• Deploy google code script to pull OOO status of team members
• Include open PRs in the workload calculation
• Review weights

Cute Animal Picture

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.24%. Comparing base (26c98b9) to head (35e8bda).

Additional details and impacted files

@@               Coverage Diff                @@
##           forks/amsterdam    #2467   +/-   ##
================================================
  Coverage            86.24%   86.24%           
================================================
  Files                  599      599           
  Lines                36984    36984           
  Branches              3795     3795           
================================================
  Hits                 31895    31895           
  Misses                4525     4525           
  Partials               564      564           

Flag	Coverage Δ
unittests	86.24% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[SamWilsn]

This is... a lot of tooling complexity. Could we maybe start with something simpler and see how that goes?

Maybe just "request the two members of STEEL¹ with the fewest assigned pull requests"? The chance of hitting two OoO people is probably low enough, and we can avoid hardcoding a list of reviewers that way.

Unless we've determined we need all of these criteria, I'd prefer to start minimal and grow as necessary.

Footnotes

1. gh api /orgs/ethereum/teams/steel/members --jq '.[].login'
   

   ↩

[SamWilsn]

I think using pull_request_target would be appropriate for this workflow. That way any pull request will get assigned, not just ones made by people with write permission.

Would have to double check for any security concerns, but I think it's okay to use here.

[Carsons-Eels]

I'll update this.

[Carsons-Eels]

This is... a lot of tooling complexity. Could we maybe start with something simpler and see how that goes?

Yeah... I went a little overboard haha. I can simplify it, sure.

Maybe just "request the two members of STEEL1 with the fewest assigned pull requests"? The chance of hitting two OoO people is probably low enough, and we can avoid hardcoding a list of reviewers that way.

That was my more ambitious idea, and would require me setting up some stuff in google to allow the script access anyway, which could turn into a headache to maintain. I'll cut it out for now and reconsider if the remaining factors really add value.