I want to add two (maybe very) controversial comments.
1). It should be considered RUDE to contact a solo maintainer in any way relating to the project (email, issue, pull request, etc.). You should ALWAYS fork the project and use the forked project on your own terms.
Most people write their projects, on a whim, on a Saturday, for a bit of fun. They do not want to be shackled to a hobby for the rest of their lives.
2). Opening an issue and opening a pull request are IDENTICAL requests for effort.
Think I'm wrong? How many people were so incensed by this renegade maintainer that they FORKED the repo?? Why didn't people FLOCK to the safer fork? Why did people still care about the original repo??? The answer to those questions underlie the fundamental problem of open source. No one wants to do the work. People want to work on what they're passionate about. But they don't want the responsibility of ANOTHER FULL TIME JOB.
An issue is a request to write "native" code. A pull is a request to maintain "foreign" code. I have never had a large, successful open source project. To date, I've had one repo with ONE issue and ONE pull request. Both required more effort than I ever wanted to give.
I have stopped opening issues completely. If a project is maintained by one person, you will never hear from me. Large projects with paid maintainers will receive issues because I believe it the only appropriate time to do so.
---
Here is a simple flow chart for contributing to a solo maintainer's open source project.
1. A problem has been discovered.
2a. I do not know how to solve the problem.
-> Move on. Don't reach out to the maintainer in any way.
2b. I can write a fix for this problem but I don't want to maintain this project in its totality.
-> Move on. Don't reach out to the maintainer in any way.
2c. I can write a fix for this problem and I want to maintain this project in its totality.
-> Fork it. Don't reach out to the maintainer in any way.
A maintainer that you can't reach out to is no maintainer at all. If that's the behavior they expect from others, they should clearly state that the project is not being maintained, and be open to others taking up that effort instead.
1). It should be considered RUDE to contact a solo maintainer in any way relating to the project (email, issue, pull request, etc.). You should ALWAYS fork the project and use the forked project on your own terms.
Most people write their projects, on a whim, on a Saturday, for a bit of fun. They do not want to be shackled to a hobby for the rest of their lives.
2). Opening an issue and opening a pull request are IDENTICAL requests for effort.
Think I'm wrong? How many people were so incensed by this renegade maintainer that they FORKED the repo?? Why didn't people FLOCK to the safer fork? Why did people still care about the original repo??? The answer to those questions underlie the fundamental problem of open source. No one wants to do the work. People want to work on what they're passionate about. But they don't want the responsibility of ANOTHER FULL TIME JOB.
An issue is a request to write "native" code. A pull is a request to maintain "foreign" code. I have never had a large, successful open source project. To date, I've had one repo with ONE issue and ONE pull request. Both required more effort than I ever wanted to give.
I have stopped opening issues completely. If a project is maintained by one person, you will never hear from me. Large projects with paid maintainers will receive issues because I believe it the only appropriate time to do so.
---
Here is a simple flow chart for contributing to a solo maintainer's open source project.
1. A problem has been discovered.
2a. I do not know how to solve the problem. -> Move on. Don't reach out to the maintainer in any way.
2b. I can write a fix for this problem but I don't want to maintain this project in its totality. -> Move on. Don't reach out to the maintainer in any way.
2c. I can write a fix for this problem and I want to maintain this project in its totality. -> Fork it. Don't reach out to the maintainer in any way.