Some pretty good advice here. Couple of other (and perhaps contradictory advice).
Get CI up as soon as you can and working for all branches. This goes a long way towards knowing if that PR is legit or not.
Make sure that you have detailed instructions on how to run the test suite and that they all pass. It is infuriating to pull down a repo, run the tests and find a bunch that fail -- if only because now I don't know whether my changes are going to make it worse or not. The more complicated the project the more details the instructions need to be. Call out specific version requirements if necessary, etc.
If you've got a style guide, get that into CI and the contribution guidelines as well. Tell me what tools I need to make it work too so I don't have to try and guess what tool that .randomstyleconfigdotfile wants to use. Tell me what version. Rubocop in particular can vary dramatically from version to version.
Unless you are popular and have a team of folks that can help, I wouldn't advocate a live chat. You have zero control over when you'll be interrupted. You're not being paid for this. I feel as the maintainer you have the right to take some time for yourself and address issues when you can. Obviously this is a double edged sword. Ignore them for too long and you're gonna lose people, but people who expect me to respond to their issue in <1 hour are gonna be unhappy.
Have a Roadmap. This will give people an idea of where you want to go -- and more importantly where you aren't willing to go so they don't waste time writing up a PR you have no intention of merging.
Remember that it is okay to say no to PRs. You are the visionary and guide.
Thank people for submitting PRs. They are doing this for free too.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Some pretty good advice here. Couple of other (and perhaps contradictory advice).
Get CI up as soon as you can and working for all branches. This goes a long way towards knowing if that PR is legit or not.
Make sure that you have detailed instructions on how to run the test suite and that they all pass. It is infuriating to pull down a repo, run the tests and find a bunch that fail -- if only because now I don't know whether my changes are going to make it worse or not. The more complicated the project the more details the instructions need to be. Call out specific version requirements if necessary, etc.
If you've got a style guide, get that into CI and the contribution guidelines as well. Tell me what tools I need to make it work too so I don't have to try and guess what tool that .randomstyleconfigdotfile wants to use. Tell me what version. Rubocop in particular can vary dramatically from version to version.
Unless you are popular and have a team of folks that can help, I wouldn't advocate a live chat. You have zero control over when you'll be interrupted. You're not being paid for this. I feel as the maintainer you have the right to take some time for yourself and address issues when you can. Obviously this is a double edged sword. Ignore them for too long and you're gonna lose people, but people who expect me to respond to their issue in <1 hour are gonna be unhappy.
Have a Roadmap. This will give people an idea of where you want to go -- and more importantly where you aren't willing to go so they don't waste time writing up a PR you have no intention of merging.
Remember that it is okay to say no to PRs. You are the visionary and guide.
Thank people for submitting PRs. They are doing this for free too.