Automate priority sync between Project board field and P0/P1/P2 labels

[leofang]

Summary

Priority is currently tracked in two independent places:

• Repo labels: P0 / P1 / P2
• Project 41 custom "Priority" single-select field (values P0 / P1 / P2)

These are set independently and drift out of sync over time. Proposal: add a scheduled workflow that treats the Project field as source of truth and mirrors it to the repo label, so that the label search (is:issue label:P0) stays accurate for CLI / API / RSS consumers.

Context — current drift

An audit turned up 25 open issues currently out of sync:

Hard mismatches (label ≠ project priority):

• CUDA graph phase N - graph updates #1330 — label P1, project P0
• Support batched memory movement #1333 — label P0, project P1
• Re-work on Linker dispatching logic #712 — label P0, project P1
• Ensure all commits to cuda_python/ and cuda_bindings/ are signed with an @nvidia.com email #1886 — label P0, project P1
• [FEA]: Avoid importing pytest in all cuda_bindings/examples #1530 — label P1, project P2

Label but no project entry:

• CI: Test CUDA_PYTHON_CUDA_PER_THREAD_DEFAULT_STREAM=1 #971 (label P0)

Project priority set but no label (dominant failure mode):

• P1: Deprecate Device.set_current()? #548, [ENH]: Clean up SUPPORTED_... variables between load libs and find header dirs #1197, RFC: Expose versioned symbols/APIs to cuda-bindings #1228, Feature Request: Device context manager for temporary device switching #1586, [PERF]: Handle generic sequences more efficiently #1640, [FEA]: Add context managers to objects where resource cleanup is required #1719, RFC: make release workflows build and publish artifacts in the release run #1759, EPIC: Tests that never run in CI #2077, cuda.core: expose mem-range attributes on ManagedBuffer (last_prefetch_location and read-side getters) #2109, Enable CodeRabbit auto-review on cuda-python (port CCCL's .coderabbit.yaml) #2137, Pixi rebuilds all 36 Cython extensions on every pixi run (editable install temp dirs) #2138, ABI checking tool should ignore the renaming of anonymous structs #2203
• P2: Add tests for _decide_nvjitlink_or_driver() #1095, Revisit cuda-bindings branching strategy #1199, [PERF]: Remove redundant type checks #1639, [PERF]: Converting arguments of generic int or fixed-size int (e.g. cuuint32_t) are suboptimal #1642, [PERF] Construction of known cdef classes can go through __new__ #1643, [PERF]: Epic for binding overhead improvements #1645, [PERF]: Measure the performance potential of caching pre-converted arguments at the call site #1655

The 19 label-missing cases mean the current label search silently under-counts open P0/P1 work.

Proposed automation

Add a new scheduled workflow under .github/workflows/ (e.g. priority-sync.yml), cron every 15–30 min plus workflow_dispatch:

1. GraphQL query enumerates Project 41 items scoped to NVIDIA/cuda-python.
2. For each item, read the Priority custom field.
3. On the linked issue/PR, remove any stale P* label and add the correct one. No-op when already in sync.

Auth: fine-grained PAT with project:read + issues:write (default GITHUB_TOKEN cannot access org-level Projects v2). Stored as a repo secret; ownership documented in the workflow header.

Optional companion (label → project): trigger on issues.labeled / unlabeled where the label matches ^P[0-2]$; GraphQL mutation writes the project field. Closes the reverse-drift case where a triager sets the label but forgets the board.

Gotchas / notes

• Projects v2 webhook events (projects_v2_item.edited) are not triggerable from a workflow on: block; event-driven sync from the project side would need a GitHub App or external listener. Cron polling side-steps this.
• If Project 41 contains items from other repos, the sync must scope to NVIDIA/cuda-python explicitly to avoid cross-repo label bleed.
• Brief inconsistency window on newly-triaged issues, bounded by the cron interval.

Alternative on the table

Drop the P* labels entirely and standardize on the Project field. Simpler operationally (no workflow, no PAT to rotate) but loses is:issue label:P0, gh issue list --label P0, and RSS filters — searchers would go through the project board or a gh api graphql snippet. Leaving on the table for discussion.

Backfill

Once direction is settled, the 25 mismatches above can be corrected by hand or via a one-shot script.

-- Leo's bot

[leofang]

Another option worth naming: drop the project Priority field entirely and treat labels as the source of truth.

Since Projects v2 treats labels as a first-class field, most of the board UX survives:

• Labels already show as their own column in the table view (auto-populated from the repo).
• Filter with label:P0 in the project's filter bar matches P0 across every repo on the board.
• Group by label puts P0 / P1 / P2 as group headings; same-name labels from different repos collapse into one group.
• Sort by label is alphabetical, which happens to give P0 → P1 → P2 for our convention.

Trade-offs vs a single-select custom field:

• No enum mutex. An issue can accidentally carry both P0 and P1; a single-select forbids that. Mitigation: a small linter workflow that fails on >1 P* label (a page of YAML, no external auth).
• Multi-label grouping duplicates rows. An issue with P0 + feature appears once under each — fine if the view filters to P* first.
• The inline "Priority" dropdown on each project item goes away; priority is edited from the issue side.
• Multi-repo caveats: labels are strictly per-repo, so
  • every participating repo needs its own P0 / P1 / P2 labels (same names, ideally same colors) — a small bootstrap step, with drift risk if someone renames;
  • project draft items (no backing issue) cannot carry labels at all, so they would have no priority signal;
  • a repo newly added to the project must set up the label taxonomy before its items get priority.

Wins if we go this way:

• Kills the sync problem at the root — no scheduled workflow, no PAT / GitHub App, no rotation story.
• is:issue label:P0, gh issue list --label P0, and RSS filters keep working unchanged.
• Backfill flips direction and shrinks: for the 19 "project has priority, no label" issues, copy the project value to a label, then delete the custom field.

Worth settling this direction question before investing in the sync automation described above.

-- Leo's bot

[mdboom]

+1 to using labels as the source of truth.

[leofang]

My bot is, like everyone's agents, very wordy. tl;dr: The 3 proposed solutions are:

1. Build an automation to sync up the priority field in the project board and the priority label.
2. Only use the project priority field
3. Only use the priority label

3 appears to be the easiest & is something we already check with our workflow anyway.