Oddbean new post about | logout
▲ ▼
Kristian | 9 months ago (raw) | root | parent | reply | flag +3 
 Yeah, which is utterly stupid, but then again, from what I remember from other systems, I'd prevent this early on by making sure people who have the permission to create a PR already earned some "merits" in the project or otherwise have proven to add meaningful contributions. Not sure whether github supports that, though.
▲ ▼
LeoWandersleb | 9 months ago (raw) | root | parent | reply | flag 
 GitHub doesn't allow a project owner to block PRs. You can spam any public project with PRs. And people use it to file issues where the issue tracker is not public.

Lets improve on that in NIP34 💪
▲ ▼
Kristian | 9 months ago (raw) | root | parent | reply | flag 
 Uh. I see. This is quite an ugly setup then and just begging for abuse. 😬
▲ ▼
DanConwayDev | 9 months ago (raw) | root | parent | reply | flag 
 Dumping some nip34 thoughts:

 1) maintainer opt-in feature
 2) allow list or WoT based
 3) must be clearly communicated to potential contributors in clients
 4) could specify rules that could be implemented in a ci environment via a DVM. Eg. Must add or update tests, or must pass standard ci pipelines. A DVM could run the checker against the PR/patch set and respond with a specific comment before the PR gets shown publicly and to the maintainers.