I didn't misunderstand. I think the confusion may stem from the question of whom the taxation is bad for - the maintainer or the contributors.
I don't believe prospective co-committers should ever be taxed for their contributions. If their contributions aren't helpful/don't live up to their standards, you can reject the request with a polite explanation.
Open-source project maintainers should understand that by posting their code on GitHub, they're inviting contributions -- that's why GitHub is called "social coding." Its purpose is to make code better through a marketplace of contributions. If you put your code there, you voluntarily accept the burden of dealing with PRs. If that's the tax people are concerned with, there's an easy way to escape it: don't use GitHub, or disable the "issues" feature in the repository. I'm not sure if you can disable PRs; but you can certainly say that you won't accept patches via GitHub in your CONTRIBUTING and/or README document.
> If their contributions aren't helpful/don't live up to their standards, you can reject the request with a polite explanation.
that's really not how it works in reality. The vast majority of pull requests do contain something that is ultimately a positive addition, so a simple "rejection" is not appropriate. Instead, in order to get a pull request to be presented in the way that the maintainer needs it to be, the request have to be slowly nursed over days/weeks/months, in a series of often dozens of back and forth emails, code samples, coachings, tutorings, attempting to get the PR submitter to please write correct tests, please get it to look a certain way, etc. The contributors will frequently themselves not reply for weeks or months when these suggestions are made - pull requests that ultimately have something useful will languish just as much if the maintainer attempts to compel the contributor to finish the work of preparing the PR for a merge, as if the maintainer just took a long time to finish the PR themself. It is much less effort and usually much more expedient for the maintainer to simply take the PR in its incomplete state and just fix it directly. Very often the problem is involved enough that the maintainer needs to be involved in restructuring in any case, even with a very well written PR.
The reality of the pull request is that it is in the vast majority of cases a more verbose form of bug report or feature request. They are quite often just as much work, if not more, than a plain bug report, for the maintainer of a well-written project.
> The reality of the pull request is that it is in the vast majority of cases a more verbose form of bug report or feature request. They are quite often just as much work, if not more, than a plain bug report, for the maintainer of a well-written project.
OK, so what, though? If it makes the software better for the users, I don't understand the problem. If the problem is "but it's work for me," see above: you knew the job was dangerous when you took it. Volunteerism should be a labor of love. If it isn't, find a replacement for yourself.
> OK, so what, though? If it makes the software better for the users, I don't understand the problem.
there isn't a problem! your pull request might take me 6 months to respond to. That's the point. Contributors shouldn't have a problem with that, either.
I don't believe prospective co-committers should ever be taxed for their contributions. If their contributions aren't helpful/don't live up to their standards, you can reject the request with a polite explanation.
Open-source project maintainers should understand that by posting their code on GitHub, they're inviting contributions -- that's why GitHub is called "social coding." Its purpose is to make code better through a marketplace of contributions. If you put your code there, you voluntarily accept the burden of dealing with PRs. If that's the tax people are concerned with, there's an easy way to escape it: don't use GitHub, or disable the "issues" feature in the repository. I'm not sure if you can disable PRs; but you can certainly say that you won't accept patches via GitHub in your CONTRIBUTING and/or README document.