
Don't post a GitHub issue unless you have contributed code, or donated  $50 cash - hoodoof
What do you think of the idea of requiring people who post github issues to first have contributed either code to the project or made a cash donation of a certain value?<p>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.
======
Cozumel
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.

------
lucaswilric
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".

------
whatnotests
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.

------
davewiner
Good issues have as much value as contributed code, maybe more.

------
gcb0
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.

------
Samathy
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.

------
smt88
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.

------
nicky0
Why wouldn't the author want things like bug reports?

------
slucha
Do you have any examples of such projects?

