Overview
The contributions sheet records every community pull request, but not what the contributor said
about their use of AI. Reviewers are reading that out of each pull request by hand.
Add a column that records the disclosure, and a second one a maintainer can use to mark a
disclosure they do not believe.
Complexity: Low
Target branch: main
Context
scripts/update-pr-spreadsheet.js runs daily in this repo since #101, and upserts every public
contributor pull request in the org updated in the last two days.
COLUMNS covers A to H, and toRow produces those eight values: state or merge date, url, author,
title, repo, created date, requested reviewers, assignees.
Two details decide how much work this is:
- updates are written cell by cell, and the loop only covers the eight values from
toRow
- appends use the range
A:H
So the automation never writes past column H, and it matches existing rows by the pull request url
in column B. A column to the right of H survives every run untouched.
The pull request template already requires an ## AI usage section, and #102 fails a run when that
section is absent, empty, or still the … placeholder. So the disclosure is enforced at the source,
and this sheet only has to record it.
The Change
Column I, written by the automation. Read the ## AI usage section from the pull request body
and record whether it holds a real disclosure. #102 parses the same section, so the two must share
one implementation rather than each growing their own.
Extend COLUMNS to I, add the value to toRow, and change the append range to A:I.
Column J, written by hand. A maintainer marks a disclosure they do not believe, for example
work that reads as generated under a statement that no AI was used. The automation leaves this
column alone, because it writes nothing past the values toRow produces.
Update docs/automation.md with both columns and who fills each.
Why not have rtibblesbot judge it
Detection of generated text is unreliable, and its errors fall hardest on people writing English as
a second language, who are a large share of our contributors. A wrong mark in a sheet the
contributor cannot see is one they can never correct.
If this is revisited, the judgment belongs on the pull request as a label, where it is visible,
contestable and reversible, and where the cron can read it from pulls.get with no new call. That
is a separate decision, and it waits on evidence that false declarations actually happen.
Out of Scope
Acceptance Criteria
Testing
- Put a value in column J on an existing row in the test sheet.
- Run
Update community pull requests spreadsheet against the test sheet. Expect column I to
update, column J to survive, and the other columns to behave as before.
- Make sure that a newly appended row fills A to I and leaves J empty.
References
AI usage
I used Claude Code to check how the spreadsheet writer handles columns, which showed that a hand
filled column needs no code change, and to find the overlap with #102. I decided the split between
the recorded disclosure and the maintainer's own mark.
Overview
The contributions sheet records every community pull request, but not what the contributor said
about their use of AI. Reviewers are reading that out of each pull request by hand.
Add a column that records the disclosure, and a second one a maintainer can use to mark a
disclosure they do not believe.
Complexity: Low
Target branch: main
Context
scripts/update-pr-spreadsheet.jsruns daily in this repo since #101, and upserts every publiccontributor pull request in the org updated in the last two days.
COLUMNScovers A to H, andtoRowproduces those eight values: state or merge date, url, author,title, repo, created date, requested reviewers, assignees.
Two details decide how much work this is:
toRowA:HSo the automation never writes past column H, and it matches existing rows by the pull request url
in column B. A column to the right of H survives every run untouched.
The pull request template already requires an
## AI usagesection, and #102 fails a run when thatsection is absent, empty, or still the
…placeholder. So the disclosure is enforced at the source,and this sheet only has to record it.
The Change
Column I, written by the automation. Read the
## AI usagesection from the pull request bodyand record whether it holds a real disclosure. #102 parses the same section, so the two must share
one implementation rather than each growing their own.
Extend
COLUMNStoI, add the value totoRow, and change the append range toA:I.Column J, written by hand. A maintainer marks a disclosure they do not believe, for example
work that reads as generated under a statement that no AI was used. The automation leaves this
column alone, because it writes nothing past the values
toRowproduces.Update
docs/automation.mdwith both columns and who fills each.Why not have rtibblesbot judge it
Detection of generated text is unreliable, and its errors fall hardest on people writing English as
a second language, who are a large share of our contributors. A wrong mark in a sheet the
contributor cannot see is one they can never correct.
If this is revisited, the judgment belongs on the pull request as a label, where it is visible,
contestable and reversible, and where the cron can read it from
pulls.getwith no new call. Thatis a separate decision, and it waits on evidence that false declarations actually happen.
Out of Scope
genuinely mandatory. That is a repo setting.
Acceptance Criteria
docs/automation.mddescribes both columns and who fills each.Testing
Update community pull requests spreadsheetagainst the test sheet. Expect column I toupdate, column J to survive, and the other columns to behave as before.
References
## AI usagesection. The parsing belongsthere, and this issue consumes it.
AI usage
I used Claude Code to check how the spreadsheet writer handles columns, which showed that a hand
filled column needs no code change, and to find the overlap with #102. I decided the split between
the recorded disclosure and the maintainer's own mark.