The new contribution policy I'm considering for my open-source projects:
"PRs are only accepted for trivial fixes (documentation typos, fixing broken links, that sort of thing), but not for code. Please file an issue instead, if you've found a problem with the software. And if you wish to become a contributor, please reach out to me."
The reason for this approach: "one-off" PRs often cost more time to review and coordinate changes on, than it would take to just do it myself. Which would be fine, *if* there was a reasonable chance of the contributor sticking around, and putting the newly learned things into practice on future contributions.
But they almost never do, and it's not sustainable to put this kind of effort into an endless stream of one-off contributors who I will never see again. The whole point is to distribute the workload, not increase it. Having long-term contributor relationships also makes things like funding (of contributor work) much easier to deal with.
Thoughts?
That said, given the assumption that you're going to do everything through Github, an Issue is probably better than a Pull Request, just because it goes onto their list of issues webpage. (Which here, is analagous to using a tag like #issue)
@cy I do wonder if the (appearance of) lock-in is specifically why Github has stuck with its PR-based contribution workflow, even though there seem to be extremely few projects on it for which it is actually working well
@joepie91 so, three thoughts to this.
The first is I tend to agree, on the basis of people are a pain in the ass, and, even when you ask for help, sometimes programmers have entirely different philosophies that just won't mesh.
Second - isn't that basically the policy of SQLite? They appear to be a very successful project that implements that policy.
Third really gets back to the whole people are a pain in the ass, in that you don't owe anyone a single iota of your time. If they really want to make a commit and you have a policy where you don't accept pull requests, there's nothing that obligates you to put your name on the quality assurance sticker for their work, which is effectively what merging a pull request is. They can fork the project (if it's open source) and stamp it for quality themselves.
semi-related experiences but not many opinions
@joepie91 i can think about things and projects which kind of do the opposite, but i don't have much of an opinion on your new contribution policy idea
i've contributed obvious and non-code changes before (peertube), but also some code changes (my first PR, synadm, and some third thing i forgot)
with synadm, i implemented a single command and was soon invited to be co-maintainer (in-between those events is issue management but only as a suggestion, and some emails from the maintainer). i kind of vaguely know the code and kinda how it works, but that's kinda it i think
now, an example related to the contribution policy but in the opposite direction (i think): osu!lazer has a PR process of "send it in, and don't merge in new changes yourself, we'll handle that. we'll also make any small[(?)] fixes if necessary"
as mentioned by peppy in an osu!lazer update video (specifically the one with editor slider hitsounding), it took the devs over a year to just review a PR, since there was a lot of code and "there was no time" (which is probably true when prioritizing player's needs over mapper's needs)
so i guess your contribution policy makes sense?