What you want to tell us
.github/CODEOWNERS records that three handles hold write invitations that have not been accepted. The file states the consequence in its own header comment: GitHub fails a CODEOWNERS entry silently when the handle lacks write access, so those entries grant nothing.
Checked against the repository today. All three invitations were created on 2026-09-05 and are still pending, and none of the three appears in the collaborator list:
The file comment says "The other owners on their lines still apply, so review coverage holds meanwhile." That is true for path coverage. It is not the whole picture once the roster is read alongside it.
GOVERNANCE.md names two workstreams whose leads are entirely inside that set:
- Identity is led by Richard Bird (@RbBuiltWrong) alone.
GOVERNANCE.md already flags the second seat as open. With the invitation unaccepted, the workstream has no lead with write access.
- Outreach is led by Eva Benn (@evabenn) and Aruneesh Salhotra (@aruneeshsalhotra). Both invitations are pending, so that workstream has no lead with write access either.
So the answer to "does the Identity workstream have an effective code owner" is that it has effective owners only through the default * rule, which is every other owner. It has no lead-level owner of its own.
The second consequence is triage. GOVERNANCE.md reserves scope:, priority:, workstream:, and status:accepted for workstream leads and the project lead. Applying a label needs triage permission at minimum, and a pending invitation carries none. Three of the nine named leads cannot triage anything today, which is worth holding next to the untriaged backlog.
Two ways to close this, and they are not exclusive:
- Chase acceptance. Twelve days is long enough that a reminder is reasonable, and an invitation can expire.
- If any of the three is not going to accept soon, record the coverage gap somewhere a reader will find it rather than leaving it in a file comment.
GOVERNANCE.md already treats the CODEOWNERS update as mandatory when leadership changes, so the roster is the natural place.
What you want to tell us
.github/CODEOWNERSrecords that three handles hold write invitations that have not been accepted. The file states the consequence in its own header comment: GitHub fails a CODEOWNERS entry silently when the handle lacks write access, so those entries grant nothing.Checked against the repository today. All three invitations were created on 2026-09-05 and are still pending, and none of the three appears in the collaborator list:
The file comment says "The other owners on their lines still apply, so review coverage holds meanwhile." That is true for path coverage. It is not the whole picture once the roster is read alongside it.
GOVERNANCE.mdnames two workstreams whose leads are entirely inside that set:GOVERNANCE.mdalready flags the second seat as open. With the invitation unaccepted, the workstream has no lead with write access.So the answer to "does the Identity workstream have an effective code owner" is that it has effective owners only through the default
*rule, which is every other owner. It has no lead-level owner of its own.The second consequence is triage.
GOVERNANCE.mdreservesscope:,priority:,workstream:, andstatus:acceptedfor workstream leads and the project lead. Applying a label needs triage permission at minimum, and a pending invitation carries none. Three of the nine named leads cannot triage anything today, which is worth holding next to the untriaged backlog.Two ways to close this, and they are not exclusive:
GOVERNANCE.mdalready treats the CODEOWNERS update as mandatory when leadership changes, so the roster is the natural place.