Implemented OSS contribution gating with GitHub Actions
Public
Implemented OSS contribution gating with GitHub Actions
Agent
Pi
Model
Claude Opus 4.5 (latest)
Started
Jan 18, 10:49 AM
Messages546
Downloads0
Outlined experiment for OSS contribution gating.
PlanProvided GitHub Actions implementation for PR gating.
BuildVerified contributor roles via GitHub event payload.
UnderstandBootstrapped approved contributors list from merged PRs.
BuildFixed WASM loading and updated packaging scripts.
Edit
here's an idea:
Strongly recommended reading by @tldraw on how to deal with OSS contributions in the age of agents.
I think I'm going to setup a little experiment in pi-mono along these lines, using a simple GH hook.
At no point is an approved contributor given access to the repo directly. The fine blog post alludes to the fact, that we may no longer need external contributions in code form. This possibly makes sense for established projects. But for new projects, code contributions are a signal.
I'm currently the only person with write access to the repo. Eventually I'd like to onboard high quality contributors, who I can trust not to slop up the code base, spreading out the load. Having them send actual code changes allows me to pick worthy individuals.
This aligns with the ideas expressed in @marlene_zw 's thread from yesterday by @giuseppegurgone
GitHub could actually introduce this concept of "approved PR submitter", but I suppose that'd take a while. A low tech solution like above seems simple enough to build and has good ergonomics.
tell me how we can implement this
This is a solid approach. Here's how to implement it with GitHub Actions (no external server needed):
.github/APPROVED_CONTRIBUTORS - plain text file, one GitHub handle per line.github/workflows/pr-gate.yml - closes PRs from unapproved contributors.github/workflows/approve-contributor.yml - adds contributors when you comment a magic phrase on their issuePR Gate Logic:
pull_request: [opened]Approve Contributor Logic:
issue_comment: [created]/approve in commentEdge cases to handle:
GitHub Actions approach:
Alternative: GitHub App with webhook:
Want me to write the actual workflow files? The Actions approach is simpler to start with and can always be replaced later if needed.
do we have access to handles from people that are actually part of the repo contributor list? then anyone from the "team" can "lgtm"
Yes. GitHub provides author_association in the event payload for comments. Values include:
OWNER - repo ownerMEMBER - org member (if org repo)COLLABORATOR - invited collaboratorSo the workflow can check:
if: > contains(fromJSON('["OWNER", "MEMBER", "COLLABORATOR"]'), github.event.comment.author_association) && contains(github.event.comment.body, '/approve')Anyone you've added as a collaborator to the repo can then /approve on issues.
There's also a CONTRIBUTOR association (has previous commits merged), but that's weaker since it doesn't imply trust, just past contributions. Probably want to stick with the three above.
Want me to write the workflow files now?
we also need to bootstrap the approved list with gh accounts that previously got their PRs merged
Good point. Let me check who's already contributed:
Got 19 contributors with merged PRs. Here's the full implementation:
/var/folders/49/l4171l3n219_xwq30fmyzr8w0000gn/T/TemporaryItems/NSIRD_screencaptureui_jP3SLl/Screenshot\ 2026-01-18\ at\ 11.53.17.png gh shows +80 contributors, so this list seems wrong
You're right, I only got PR authors. Let me check commit authors instead:
That's 82 contributors from the GitHub API. Let me write the complete implementation:
Done. Three files created:
.github/APPROVED_CONTRIBUTORS - 81 existing contributors (excluding badlogic since you'll bypass as collaborator anyway)
.github/workflows/pr-gate.yml
pull_request_target (needed to have write access to close PRs from forks).github/workflows/approve-contributor.yml
OWNER, MEMBER, or COLLABORATOR comments /approve on an issueTo remove someone who abuses the privilege: just delete their line from APPROVED_CONTRIBUTORS manually.
You might also want a CONTRIBUTING.md that explains this process. Want me to add that?
i want lgtm to be the trigger word not /approved
Also need to update the PR close message:
Done. Now any collaborator commenting lgtm (case-insensitive) on an issue will add that issue's author to the approved list.
do a deep review of the files we just wrote, identify any bugs or issues and report them here
Deep review findings:
Wrong trigger text in header
.github/APPROVED_CONTRIBUTORS still says “commenting /approve” but the trigger is now lgtm.
pr-gate.yml permissions are too narrow
You set only pull-requests: write. The workflow also calls:
repos.getContent which needs contents: readissues.createComment which needs issues: writeapprove-contributor.yml uses author_association as a permission check
MEMBER can include org members with no repo access. That lets any org member approve contributors.
Better: call repos.getCollaboratorPermissionLevel and check for admin or write.
Default branch hardcoded to main
Both workflows read or checkout main. If the repo default branch changes, they break. Use context.payload.repository.default_branch or github.event.repository.default_branch.
lgtm matching is too loose
contains(..., 'lgtm') matches phrases like “not lgtm” or “lgtm? no”. If you want strict approval, use a regex for ^lgtm$ or a command like /lgtm.
PR close comment link is relative
../blob/main/CONTRIBUTING.md might not render correctly in issue comments. Use an absolute link.
If you want, I can fix these.
please fix
Summary:
.github/APPROVED_CONTRIBUTORS header to say lgtm.pr-gate.yml permissions, default branch handling, and absolute CONTRIBUTING.md link.approve-contributor.yml with exact lgtm match, real collaborator permission check, default branch checkout, and guarded commit/comment steps.No tests run.
ok, now we also need a CONTRIBUTING.md or whatever is the defaulft file for that. ask me questions how it should look and what hsould be in it.
What should CONTRIBUTING.md include? Please specify:
ask again opus you are better at writting
Questions for CONTRIBUTING.md:
The approval gate - Should this be front and center as the first thing people see, or buried in a "Before your first PR" section?
What makes a good issue? - You mentioned "concise, minimal description." Any specific structure you want (problem/solution format)? Examples of good vs bad issues?
AI/agent policy - Do you want to explicitly state expectations around AI-generated contributions? The PR gate message mentions "AI slop will be closed" but should the guide expand on what that means?
Technical requirements - Should contributors run npm run check before submitting? Any test expectations? Do you want them to update CHANGELOG.md or do maintainers handle that?
PR scope - Preferences on PR size? One issue per PR? Rebasing vs merge commits?
What's off-limits? - Any areas of the codebase where you don't want external contributions? Features you'll reject outright?
Communication style - Where should contributors ask questions if they're unsure (issues, discussions, Discord)?
Length/tone - Short and punchy, or thorough? Friendly, neutral, or "read this carefully or get rejected"?
biggest concern is: contributors must understand what the code changes do and how they interact with the rest of the system. just sending any old agent generated slop does not do.
Done. 1.2KB, fits on one screen, covers:
Want me to adjust anything?
yes, contributors should NOT add entries to CHANGELOG.md. that part is automated.
The CONTRIBUTING.md I wrote doesn't mention CHANGELOG.md at all. Contributors are only told to run npm run check and ./test.sh.
Did you want me to explicitly state "Do NOT edit CHANGELOG.md" to preempt people who might try?
re: undersatnd your code, it is fine to get that understanding by interrogating an agent with access to the code base until all edge cases and effects of the code change are understood by you
Updated. Now clarifies that interrogating an agent to build understanding is a valid path.
changelog shit too please
Done.
if you create a contribution with an agent the agent must follow the rules and guidelines outlined in AGENTS.md. it is best to let your agent run in the pi-mono root dir so it picks up the AGENTS.md file automatically.
Done.
anything else missing?
Looking at it:
License - No mention that contributions are licensed under the project's license. Some projects want this explicit.
Dev setup - No pointer to README for getting the project running locally. Assumed obvious?
Reopening closed PRs - If a new contributor's PR gets auto-closed, then they get approved via an issue, they need to open a new PR. The closed one won't pass the gate retroactively. Worth mentioning?
Commit message format - No conventions specified. Intentional?
Any of these worth adding, or keep it minimal?
keep it minimal commit and push both the CONTRIBUTING and README changes
Done. Pushed 5 files:
.github/APPROVED_CONTRIBUTORS (81 contributors).github/workflows/pr-gate.yml.github/workflows/approve-contributor.ymlCONTRIBUTING.mdREADME.mdok, how can i test the gh workflows? i suppose i can create a new gh account?
Options:
New GitHub account - Simplest real test. Submit a PR, watch it close, open an issue, have your main account lgtm, submit another PR.
Ask someone on Discord - Have a non-contributor test it for you.
Temporarily disable the collaborator bypass - Comment out the collaborator check in pr-gate.yml, push, test as yourself, then revert. Quick but requires two extra commits.
Use act - Runs GitHub Actions locally, but struggles with pull_request_target and API calls. Not worth the hassle here.
The new account approach is cleanest since it tests the exact real-world flow. GitHub allows multiple accounts as long as they're not used to evade bans or abuse free tiers.
workflows fail, use gh cli to investigarte an fix them all
Found it. The issue is in approve-contributor.yml line 8:
if: !github.event.issue.pull_requestIn YAML, ! is a tag indicator, so this is being parsed as a YAML tag, not a boolean negation. Needs to be wrapped in ${{ }} or quoted.
The multiline template literal in pr-gate.yml is confusing the YAML parser. The lines inside the template literal have no indentation, which breaks YAML's block scalar parsing. Let me fix it by constructing the message differently:
Both valid now. Committing:
The workflows don't run on push (they're triggered by PRs and issue comments), so no new runs for them. But importantly, no new "workflow file issue" failures appeared.
Fixed issues:
approve-contributor.yml: Wrapped !github.event.issue.pull_request in ${{ }} to prevent YAML tag interpretationpr-gate.yml: Replaced multiline template literal with array.join('\n') to avoid YAML block scalar parsing issuesTo fully test, you'll need a PR from a non-approved account or an issue with an lgtm comment.
the gate works (at least closing and commenting, not sure yet if approval works)
the lgtm does not https://github.com/badlogic/pi-mono/actions/runs/21111411625/job/60710500105
Found it. actions/github-script@v7 already provides core as a global variable. The line const core = require('@actions/core'); redeclares it.
Fixed. actions/github-script already provides core as a global, so the explicit import caused a redeclaration error.
Try commenting lgtm on the test issue again.
lgtm need more boo fails to do the thing Run actions/github-script@v7 Comment does not match lgtm
The regex ^\s*lgtm\s*$ requires the comment to be only "lgtm". You want to allow additional text after it.
Done. Now lgtm, lgtm need more boo, LGTM, go ahead etc. will all work. The \b word boundary prevents false matches like lgtmfoo.
i think we also need an issue template that reflects CONTRIBUTING.md?
Created:
.github/ISSUE_TEMPLATE/contribution.yml - For new contributors proposing changes (what/why/how).github/ISSUE_TEMPLATE/bug.yml - Bug reports (what happened/repro steps/version).github/ISSUE_TEMPLATE/config.yml - Allows blank issues, adds Discord link for questionsWant me to disable blank issues (force people through templates) or commit as-is?
i don't understand what you did.
GitHub Issue Templates change what users see when they click "New Issue" on the repo.
Without templates: User gets a blank text box.
With templates: User sees a menu like:
The templates I created are forms that guide users to provide the info you need, matching the CONTRIBUTING.md requirements.
Want me to show you what the template files look like, or just commit and you can see it live on GitHub?
if i create a new issue no template is selected, i can just write whatever
I created the files but didn't commit/push them yet. Also blank_issues_enabled: true lets people bypass templates.
Let me push them and disable blank issues:
Done. Now when someone clicks "New Issue", they'll see:
No blank issue option. Try it.
/var/folders/49/l4171l3n219_xwq30fmyzr8w0000gn/T/TemporaryItems/NSIRD_screencaptureui_hfNv4r/Screenshot\ 2026-01-18\ at\ 13.21.09.png
This is issue #824 opened 14 minutes ago, before the templates were pushed. New issues created now should show the template picker.
Is there something specific you want me to address here, or were you just showing context?
if: > contains(fromJSON('["OWNER", "MEMBER", "COLLABORATOR"]'), github.event.comment.author_association) && contains(github.event.comment.body, '/approve')if: !github.event.issue.pull_request