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.
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.
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.
> 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.
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.
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.
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.
About time; locking down pull request surface area at the repository level without hacky automation is a clean win.
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.