PolicyEngine / PolicyEngine/policyengine-scorecard

UK review queue: 17 open PRs, suggested merge order, and what is blocked on whom

Open
#104 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
0
Forks
0
Avg merge
6d 12h
Merged PRs (30d)
32

Description

@MaxGhenis @DTrim99 — 17 of my PRs are open, all green and mergeable. Rather than ping each one, here is the whole queue in one place with what each of you is actually needed for.

State

PRs
Approved by @DTrim99, awaiting @MaxGhenis #75, #81, #49, #64, #65, #66, #67, #68, #51, #91, #92, #93
Awaiting both #95, #100, #101, #102, #103

All 17 pass pytest · ruff format and typecheck · build, build deterministically, and leave a clean tree.

Suggested merge order, and why it matters

I merged all twelve of the original branches in sequence on a scratch branch to find out. Two things came out of it:

  1. build_db.py conflicts on nearly every merge — six branches insert a step at the same anchor, and the conflict region splits a step tuple, so a both-sides union produces invalid Python. That is the good case; the bad case drops a step and ships a database missing a lane while every test passes. #81 carries a guard that refuses a chain importing an ingest it never runs, so merging #81 early protects the rest.
  2. lanes.json conflicts are not real — it is a derived feed both sides append to. Regenerate from a build rather than hand-merging.
#75 → #81          (#81 carries #75; merge #81 early for the guard)
#49 → #64          (#64 stacks on #49)
#65, #68, #51, #66, #67    (independent)
#91 → #92          (#92 stacks on #91)
#93, #95, #100, #101, #102, #103   (independent)

One ordering constraint that is not obvious: uk_thinktanks must run before produce_uk — #91 changed produce_campaign_uk's blocked-family reasoning on the basis that Resolution Foundation claims now exist. The current insertion point satisfies it.

@MaxGhenis — three things only you can unblock

  1. #49's mode-3 table design. You offered to pair on it and I took you up rather than guessing: the case/result table, writer, exporter and the status/diagnosis split are deliberately not in #49 or #64. SCHEMA.md records the open shape. Whenever suits.
  2. #76–#80, the compute campaign. You're holding them on #51, which is now repaired and approved. This is the one that matters most — see below.
  3. #56 and #69, your own branches. Both still track data/scorecard.db and their ci.yml has neither the determinism check nor the no-drift gate, so they are running a pre-#74 workflow. #56 matters beyond itself because #67 consumes its COMPARISON.csv. Fix is git merge origin/main; I haven't pushed to your branches.

@DTrim99 — five you haven't seen

#95, #100, #101, #102, #103. #95 is the one I'd most like your eye on: it uses pull_request_target, which is the sharp trigger, so the "never checks out or executes PR code" property is the thing to check hardest.

The number behind all of this

The UK side has 15,858 external claims and 14 with a PE result — 0.09%. The US side is 19.3%. Nothing in this queue changes that except the compute campaign; the lanes make the denominator bigger. If only one thing moves this week, it should be #51 landing and #76–#80 being released.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with SCHEMA.md and the referenced PRs, especially #51, #81, and #95; inspect build_db.py, lanes.json, data/scorecard.db, and ci.yml. Run the stated pytest, ruff format, typecheck, and build checks. Done means resolving the review and merge dependencies while preserving the listed guards and ordering.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, github-actions, python
Domain
build-system, ci-cd, release
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
15/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.