Oddbean new post about | logout
▲ ▼
LeoWandersleb | 9 months ago (raw) | root | parent | reply | flag +1 
 People going for the lowest hanging fruit and as they don't know shit, they miss the mark and thus only waste the time of the maintainers.

In this case, they propose to change the documentation and probably they suggest to add a linebreak here or a comma there.
▲ ▼
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.