> The comment I screenshotted is passive-aggressive at best It's polite and it asks questions that are very pertinent, given how you claim to manage your repos

> The comment I screenshotted is passive-aggressive at best It's polite and it asks questions that are very pertinent, given how you claim to manage your repos. > How can the community support? I've been involved in a project that accepted drive-by PRs and I get that that sucks. You know what helped? People who asked how they could tick something off my personal todo list before they tried to crowbar their pet feature in. > Can we expect development by the maintainer? > Are you open to PRs and reviewing them? > What's your time commitment? > Should someone just fork the repo? All of these questions really just ask the same one: should I fork your repo if I want to make a change. Your very next point discusses a repo where you don't accept PRs, don't reply to issues, but also refuse to say it's not being "developed". You literally ask for PRs in the README.md, but then ignore them? Are people supposed to figure out that you think it's perfect as-is and doesn't need more input in contradiction to that?. All of the questions other than #2 are literally just trying to get you to put that in writing. Forks suck. There's no if's, and's, or but's. At best the original project is dead and the fork goes on to be kind of a successor. But it never really will be, because 90% of people will stay on the original, 5% of people will move to the fork, 18% of people will post on both repos about how it's unclear which one they should use, and 7% of people will post on the new repo threatening to sue because they found a similar-sounding project in some disclosure and they don't agree to your imaginary terms that allow you to sell their private info to the Illuminati. But the worst is when the original project isn't dead. You go and do a significant amount of work to fork it, and then the original author comes back with some pretty major changes that completely break the foundation of your fork. Now you're stuck on a legacy fork, or a ton of work to rebase onto the core library. If other people are depending on your fork that's a difficult question to answer. This email is basically asking "should I go and do all of that work?" in as polite a way as possible. If you put together a canned response (cough CONTRIBUTING.md cough) that would solve 100% of this: > Thanks for your interest in contributing. I think this project is pretty complete as-is. If there are breaking changes or zero-days that come up, I plan on fixing them. Otherwise I don't expect to approve many PRs. If you feel you need to get a change in, feel free to fork the repository and make your change there.