Don't post a GitHub issue unless you have contributed code, or donated $50 cash
9 comments
Do you have any examples of such projects?
Good issues have as much value as contributed code, maybe more.
I think there are better ways to solve the problem of maintainers burning out.
Encouraging code contributions is a good thing, it encourages people to suggest solutions to their problems. I think it fails to solve the burnout issue, though, because processing those PRs is also work for the maintainer.
Encouraging donations is also a good thing, because good work deserves reward, and sometimes cash is an appropriate way of helping a project.
The problem with both of these tactics is that they reduce the overall input of ideas - both good and bad - into the project. They make no distinction about the quality of the ideas or the validity of the issues.
I think a better solution is to address the burnout problem more directly, for example by helping the maintainer manage that huge list of issues. That's hard, because the maintainer is unlikely to trust just anybody with their project, if anybody even volunteers. But if a project you really care about is failing because of this, then maybe that's a way you could offer to help. The worst that's likely to happen is that the maintainer will say "no, thanks".
Encouraging code contributions is a good thing, it encourages people to suggest solutions to their problems. I think it fails to solve the burnout issue, though, because processing those PRs is also work for the maintainer.
Encouraging donations is also a good thing, because good work deserves reward, and sometimes cash is an appropriate way of helping a project.
The problem with both of these tactics is that they reduce the overall input of ideas - both good and bad - into the project. They make no distinction about the quality of the ideas or the validity of the issues.
I think a better solution is to address the burnout problem more directly, for example by helping the maintainer manage that huge list of issues. That's hard, because the maintainer is unlikely to trust just anybody with their project, if anybody even volunteers. But if a project you really care about is failing because of this, then maybe that's a way you could offer to help. The worst that's likely to happen is that the maintainer will say "no, thanks".
Issues are a form of QA -- something that companies can (and should) pay for. Maintainers want more high-quality issues, not fewer.
Paying for a maintainer to prioritize a certain issue (probably just features) is a better idea, and I've seen a few companies offering ways for FOSS maintainers to do it.
Paying for a maintainer to prioritize a certain issue (probably just features) is a better idea, and I've seen a few companies offering ways for FOSS maintainers to do it.
Many issues I've submitted are simply bug reports based on my observations during usage.
Simply by saying "hey you may not have noticed X but when you do Y then this happens..." it can help the author(s) know:
* that a problem might exist in the code.
* that there's no problem but the docs made something unclear which led to the problem I reported.
* how others are actually using their software.
These are worth paying for on their own.
Simply by saying "hey you may not have noticed X but when you do Y then this happens..." it can help the author(s) know:
* that a problem might exist in the code.
* that there's no problem but the docs made something unclear which led to the problem I reported.
* how others are actually using their software.
These are worth paying for on their own.
I saw that on one project.
It has bad user documentation. It has a single dev. It has a user maintained wiki that has signup broken. it has a user maintained forum that is very active, once a week. And it has a good enough UI that is perfect to get people interested and then lost.
The only solution i see there, that may work everywhere: delegate.
give random permissions to people on the social side. Nobody will hack your project if you left everyone you know has a brain maintain your issues page. Don't even ask, just give them access. Probably very few, or nobody will stay around, but they are already trying to understand the project, so they will easy the burden of the next person arriving with a clueless issue that week. maybe not next week, but maybe that people they helped will. and so on.
It has bad user documentation. It has a single dev. It has a user maintained wiki that has signup broken. it has a user maintained forum that is very active, once a week. And it has a good enough UI that is perfect to get people interested and then lost.
The only solution i see there, that may work everywhere: delegate.
give random permissions to people on the social side. Nobody will hack your project if you left everyone you know has a brain maintain your issues page. Don't even ask, just give them access. Probably very few, or nobody will stay around, but they are already trying to understand the project, so they will easy the burden of the next person arriving with a clueless issue that week. maybe not next week, but maybe that people they helped will. and so on.
Why wouldn't the author want things like bug reports?
It sounds pretty stupid, self-defeating and is conflating two different things, bug reports and support.
Bug reports should be all that goes on Github, for people telling you that your code is broken you should be paying them, they're doing you a favour.
For support, that should stay off Github and be a user generated forum, If you build a community there it'll take care of itself leaving you to just deal with the code.
If you need money you could always offer priority support for those who donate or contribute in some other way.
Bug reports should be all that goes on Github, for people telling you that your code is broken you should be paying them, they're doing you a favour.
For support, that should stay off Github and be a user generated forum, If you build a community there it'll take care of itself leaving you to just deal with the code.
If you need money you could always offer priority support for those who donate or contribute in some other way.
I see no problem in encouraging contributions and donations in your CONTRIBUTING.md (that shows when creating an issue).
Especially in a large project.
But requiring a donation or code would mean that lots of bugs would go un-reported. Issues are just as much of a contribution to a project as code is.
Founders getting overwhelmed is solved by adding maintainers or transferring maintainership. Popular projects will be forked if the maintainer burns out and leaves.
But requiring a donation or code would mean that lots of bugs would go un-reported. Issues are just as much of a contribution to a project as code is.
Founders getting overwhelmed is solved by adding maintainers or transferring maintainership. Popular projects will be forked if the maintainer burns out and leaves.
I see projects become popular and then overwhelmed with issues and then the project founder gets burned out and gives up. Maybe something like this could help.