Comment by withinboredom
2 hours ago
> if your contribution is not merged in, it should not count as "work done"
I highly disagree with this. Sometimes someone has to do the work to discover that isn't the work that should be done. As an example, last week, I got in a fight with the Go scheduler: https://github.com/php/frankenphp/pull/2016 -- in the end, we were able to find the one-liner that is a happy-medium. I didn't open that PR, but I did the work; if that makes sense.
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
At that point, you tackle abuse, which is a separate topic altogether.
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.