> I might be wrong about OP's intentions when giving my reply, but I am pushing back against a narrative, not against a specific person.
What narrative? Your comment is vague. Would you mind expanding on this accusation and how it relates to open source, especially when today's maintainers on platforms like GitHub and GitLab have an array of tools at their disposal to deal with issues?
OP replied to my comment and I now see that it makes sense as an observation. The narrative I was referring to is something that I see common in discussions surrounding abuse; "there's nothing to be done about it; [people should] just grow a thick skin." If we agree that this exists, then I posit that it's a toxic thing to say to someone who's coming forward and saying that they're suffering from this. It's also toxic to use that as a way to dismiss measures that we can build in technologically to combat abuse, like building blocking mechanisms or modifying them to make them better. Hope that clarifies things.
Are you familiar with the Open Source Guides Best Practices for Maintainers [1] and Maintaining Balance for Open Source Maintainers [2]?
Perhaps these helpful pages and the resources linked within may give you some guidance on how experienced maintainers can handle such matters without a hostility-first mindset.
For my own projects, I do try to avoid scope creep. (In some cases I had thought something should be in scope but later changed my mind (before actually implementing it), though.) I did not add a file called VISION but maybe that would help, so I will consider that. I do want to keep communication public (mainly using NNTP, although IRC and GitHub issue trackers can also be used), but nevertheless there isn't any communication on there.
> If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork. Forking a project doesn’t have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project’s vision.
This is correct. However, it is also possible for some of the features of a forked version to later be put into the official version (or a different fork) (after being reviewed by the maintainer). This does happen sometimes, too.
> Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
Nevertheless, it make sense; there is more to say if they have a complaint (or a suggestion for improvement, or a question, etc) than if it works OK.
I don't mind this; my problem is that I rarely receive any feedback at all, regardless of good or bad.
(However, I think that it is helpful even for positive feedback to be specific. This way, it can also help other people to decide whether or not they think this program is suitable (or almost suitable) for their intended uses.)
(I have received stars on GitHub (for some projects), but they don't help me at all, since they do not say anything.)
> Working alone: Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
This is my problem; lack of other people discussion and contributions.
What narrative? Your comment is vague. Would you mind expanding on this accusation and how it relates to open source, especially when today's maintainers on platforms like GitHub and GitLab have an array of tools at their disposal to deal with issues?