In a program like this you can’t optimize for the assumption that every participant is acting in good faith and contributing good work even if it’s not accepted.

If a program incentivizes opening PRs even if they’re not accepted, the result will be a lot of maintainer spam from people opening useless PRs. This isn’t a personal hypothetical, it’s what we observe any time programs try to incentivize open source work. See the Hacktoberfest drama of years past where the promise of a T-shirt led to spam PRs across GitHub https://joel.net/how-one-guy-ruined-hacktoberfest2020-drama

▲

withinboredom 32 minutes ago | parent [-]

At that point, you tackle abuse, which is a separate topic altogether.

	▲	Aurornis 22 minutes ago \| parent [-]
		It’s not a separate topic. You have to structure the program so that abuse is disincentivized from the start. In the T-shirt example if you left the program as-is but then decided that tackling abuse is a separate topic, think about what that would look like: Every maintainer would now not only have to read and close the spam PRs, they’d have to go file an abuse report for every single one of them. Now you’ve put even more work on the maintainers and created an additional burden of reviewing reports, all without clarifying the program to discourage abuse from the start. This is why it’s necessary to structure a program clearly such that abuse-level or low effort inputs can’t easily claim the rewards.