Locking down pr is the wrong approach (for most). Just provide a subtab inside PR tab that shows PRs from new people.
One tab for pr from contributors and users who already have PRs accepted in the repo.
Another tab from first time/no pr approved yet users. Maintainers can treat it as spam box if they want.
Occasionally, users can flag them as useful and maintainers can then look at them.
Give a button to move from others to PR tab.
Don't consider count of PRs inside others in the main count.
> Locking down pr is the wrong approach (for most).
Depends on your goal no? If your goal is to not accept random contributions or PRs, then being able to disable PRs completely, seems like the perfect approach? Up until this change (which happened almost a year ago, FWIW), it was impossible to just have a read-only mirror on GitHub that didn't get hit with drive-by PRs that just waste time, for example: https://github.com/videolan/dav1d/pulls?q=is%3Apr+state%3Acl...
I'm glad we can finally completely disable it, as it seems to just confuse people when you're not actually accepting PRs.
I never thought I’d see the day where somebody who works at the DoD would spend their spare time trying to get random open source projects (even one that already has a CoC) to accept the Contributors Covenant via
GitHub pull requests. We truly are living in an enlightened age.
He has over 600 repositories. A few are forks but the majority appear to be TypeScript slop with less than 100 commits (with most of them being dependabot updates).
There needs to be public service announcements about responsible AI use. If we're going to boil the Earth and live in a world where a 64 GB DDR5 RAM kit that was $200 three years ago is now over $1000 then can we at least get the LLMs to generate code that's actually useful instead of circadian rhythm calculators.
They didn't. They made the senseless PR in 2022, but only worked at DoD for a whole month so far, seems to have joined in October.
I think it takes a certain type of person to join that department at this time, so make of that what you will. Certainly seems like they've "turned their life around", for better or worse.
If the Microsoft purchase of Github wasn't a good indicator of the start of the end, this is it, I know a lot of people like to have "control" over things, but I have found so many fixes for software I use in un-merged PRs. Github moving towards closer and a closer system is good opp for alternatives to take some of that space. Nice.
This "Microsoft ruined GitHub" doom talk is getting tiresome. That was 8 years ago.
One of the big changes right after that was offering free private repositories, most people complaining today would've probably not even used GitHub if there were only free public repositories.
While that was a nice change, don't kid yourself: Github was the dominant platform before that for a reason, and the alternatives were either behind in features or very new. I'm doubtful that if they still had the old pricing structure for private repos that it'd change anything about their success.
Also, the old structure reflected their focus/encouragement of open source, something this change does even more to move away from.
At the same time, I don't view this as a huge issue, though it does make me wish it was easier to get activity details on forks so even if a repo is locked down it would let you see where PRs "went".
> Also, the old structure reflected their focus/encouragement of open source, something this change does even more to move away from.
Open source projects are the main driver of this change, every popular open source projects gets a lot of drive by AI pull requests that waste maintainers’ time. Projects come up with their own way of blocking people (https://github.com/ghostty-org/ghostty/blob/main/.github/VOU...) but having this be a GitHub feature is a much easier option for most.
I love that two of the comments presume that this change is recent and both for different reasons. It's as if most people don't know the current state of affairs unless it hits them with a hammer on the face.
I personally didn't know this, but I also don't submit PRs on github since a while ago.
I imagine in order to really notice this in the course of your routine, you'd usually be either maintaining open source repos (exposed to the vast amounts of AI-driven PRs), or submitting PRs to open source regularly.
> Pull requests and merge requests will no longer count toward Hacktoberfest rewards. It’s easier than ever to submit low-effort spam PRs to projects, so we’re listening to maintainer feedback and no longer actively incentivizing PRs. That being said, we certainly still encourage you to work on open source and share your work with the world during Hacktoberfest. Our new format focuses on learning and building together while reducing the burden of low-effort contributions on maintainers.
Good to see them adapt to the times. Using maintainers as free labour via PR abuse was such a 2023 way of being a parasite to the free software community. The new, cool way of doing it is to endorse the technology that can wash free software of those pesky copyleft licenses and unevenly distribute the expertise it encodes to the corporations who can pay for the most tokens.
couldve simply put it behind a priority paywall, get money for work & showcasing or incorporating a piece of work, everyone is always free to fork but wanting to contribute to a popular project should be allowed for some money as well for good support
Locking down pr is the wrong approach (for most). Just provide a subtab inside PR tab that shows PRs from new people. One tab for pr from contributors and users who already have PRs accepted in the repo.
Another tab from first time/no pr approved yet users. Maintainers can treat it as spam box if they want.
Occasionally, users can flag them as useful and maintainers can then look at them.
Give a button to move from others to PR tab.
Don't consider count of PRs inside others in the main count.
> Locking down pr is the wrong approach (for most).
Depends on your goal no? If your goal is to not accept random contributions or PRs, then being able to disable PRs completely, seems like the perfect approach? Up until this change (which happened almost a year ago, FWIW), it was impossible to just have a read-only mirror on GitHub that didn't get hit with drive-by PRs that just waste time, for example: https://github.com/videolan/dav1d/pulls?q=is%3Apr+state%3Acl...
I'm glad we can finally completely disable it, as it seems to just confuse people when you're not actually accepting PRs.
I never thought I’d see the day where somebody who works at the DoD would spend their spare time trying to get random open source projects (even one that already has a CoC) to accept the Contributors Covenant via GitHub pull requests. We truly are living in an enlightened age.
> September 2026 - Created 670 commits in 80 repositories
> I never thought I’d see the day where somebody who works at the DoD would spend their spare time
He didn't.
He has over 600 repositories. A few are forks but the majority appear to be TypeScript slop with less than 100 commits (with most of them being dependabot updates).
There needs to be public service announcements about responsible AI use. If we're going to boil the Earth and live in a world where a 64 GB DDR5 RAM kit that was $200 three years ago is now over $1000 then can we at least get the LLMs to generate code that's actually useful instead of circadian rhythm calculators.
They didn't. They made the senseless PR in 2022, but only worked at DoD for a whole month so far, seems to have joined in October.
I think it takes a certain type of person to join that department at this time, so make of that what you will. Certainly seems like they've "turned their life around", for better or worse.
Agreed. So many things could be solved by smart UIs. This is pouring the baby out with the bathwater.
Heck, one could say "Chat" for GPTs was the summum of "smart" UIs (or "smarts" for an "optimal" UI: Chat ...)
... and there's an asymmetry there.-
If the Microsoft purchase of Github wasn't a good indicator of the start of the end, this is it, I know a lot of people like to have "control" over things, but I have found so many fixes for software I use in un-merged PRs. Github moving towards closer and a closer system is good opp for alternatives to take some of that space. Nice.
This "Microsoft ruined GitHub" doom talk is getting tiresome. That was 8 years ago.
One of the big changes right after that was offering free private repositories, most people complaining today would've probably not even used GitHub if there were only free public repositories.
While that was a nice change, don't kid yourself: Github was the dominant platform before that for a reason, and the alternatives were either behind in features or very new. I'm doubtful that if they still had the old pricing structure for private repos that it'd change anything about their success.
Also, the old structure reflected their focus/encouragement of open source, something this change does even more to move away from.
At the same time, I don't view this as a huge issue, though it does make me wish it was easier to get activity details on forks so even if a repo is locked down it would let you see where PRs "went".
> Also, the old structure reflected their focus/encouragement of open source, something this change does even more to move away from.
Open source projects are the main driver of this change, every popular open source projects gets a lot of drive by AI pull requests that waste maintainers’ time. Projects come up with their own way of blocking people (https://github.com/ghostty-org/ghostty/blob/main/.github/VOU...) but having this be a GitHub feature is a much easier option for most.
I think you missed the part where open-source developers are begging Github to implement this feature and threatening to leave otherwise.
For example who?
This is from February
I love that two of the comments presume that this change is recent and both for different reasons. It's as if most people don't know the current state of affairs unless it hits them with a hammer on the face.
I personally didn't know this, but I also don't submit PRs on github since a while ago.
I imagine in order to really notice this in the course of your routine, you'd usually be either maintaining open source repos (exposed to the vast amounts of AI-driven PRs), or submitting PRs to open source regularly.
I think OSS maintainers can protect themselves from hacktoberfest PR slop! A welcome change.
Hacktoberfest is now about learning open-source AI models, not about creating PRs on random repos
I hadn't heard, but you're right. And they've clearly taken account of the negative impact a particular group was having on the ecosystem.
From the FAQ on https://hacktoberfest.com/ :
> Do I still submit pull requests to earn swag?
> Pull requests and merge requests will no longer count toward Hacktoberfest rewards. It’s easier than ever to submit low-effort spam PRs to projects, so we’re listening to maintainer feedback and no longer actively incentivizing PRs. That being said, we certainly still encourage you to work on open source and share your work with the world during Hacktoberfest. Our new format focuses on learning and building together while reducing the burden of low-effort contributions on maintainers.
Good to see them adapt to the times. Using maintainers as free labour via PR abuse was such a 2023 way of being a parasite to the free software community. The new, cool way of doing it is to endorse the technology that can wash free software of those pesky copyleft licenses and unevenly distribute the expertise it encodes to the corporations who can pay for the most tokens.
eternal hacktober
couldve simply put it behind a priority paywall, get money for work & showcasing or incorporating a piece of work, everyone is always free to fork but wanting to contribute to a popular project should be allowed for some money as well for good support
[flagged]
[flagged]