Perhaps a hot take, but, as FOSS devs making tooling/libs, we shouldn't be annoyed that people are asking for support in our issue trackers. We're making tools for engineers, and if they can't figure out how to use them, our documentation needs work.
@tindall does that mean that instead of just answering support questions that come in through bug trackers, it should be treated as a documentation bug, and resolved with an improvement of documentation?
@zatnosk yep! I tend to answer reports like that with "I've updated (link), does that answer your question?"
@tindall I get annoyed when people make support issues, I ask follow up questions, and then they just disappear.
I kind of wish there was more accountability on people posting issues. Sometimes people have very niche requests/questions, and I put in a lot of time trying to answer, only for that time to be wasted on someone who has suddenly lost interest. I don't like closing issues people make because I feel like it makes me look unreasonable and impatient. But if I leave them hanging, it clogs up the issues page with stuff that will never get accomplished.
The solution I have now is to just disable the issue tracker and have people email me directly with questions. This thins the user base, but the few people who do end up reaching out to me are always very enthusiastic about my projects. And I'd much prefer managing a FOSS project with only dozens of enthusiastic users than a project with thousands of mostly passive/neutral ones.
@tindall What we really need, in my view, is some kind of general funding towards doing this work, so that we can focus on it properly (or at least better) -- including taking more time for documentation.
I do what I can to document, but there's still this constant scramble between really polishing stuff vs. "just get that thing limping along well enough so I can use it," because doing other stuff towards improving finances is always a competing priority.
...or something like that.
I'm probably not explaining myself very well.
@tindall This is one of the reasons why I prefer the BSDs over Linux. They come with documentation, the documentation tends to be more detailed (with examples, which really help) and the developers consider filing a bug pointing out an issue with that documentation to be a valid bug.
@tindall I honestly don't understand why this is a thing. You put a package out into the world, people are going to use it and have questions and feedback. Isn't that really the whole point?
I ran a couple pretty large FOSS projects, and I actually enjoyed interacting with my userbase, taking items into the TO FIX queue, asking for updates, etc. It made me feel good to see/hear my software being used by others. Validating.
@RoyGreenhilt @tindall The problem is that code hosting platforms only have bug trackers built-in, and we don't have free and easy to use _discussion_ platforms that would be popular with people and could be used for support requests.
People misuse bug trackers for support requests, and repo maintainers get annoyed because indeed closing what is supposed to be a bug report is logically on the one who opened it, and having many open bug reports looks bad.
@dmbaturin @tindall I hear that, and you're right. (You don't know my background, but the opensource project I wrote was one of the very popular bug / support trackers back in the 90s). It could handle both support and bug requests, and was used for both.
In modern FOSS though, things like github's Issues are... issues. Bugs. Things that can be linked to PR's. Using them for support is definitely a weird mix.
@RoyGreenhilt @tindall Yeah, my point exactly. Sometimes I'm thinking of a free and, ideally, federated platform for "bugs+discussions", where discussions can be converted to bugs if needed, but are separate concepts.
GH/GitLab/Gitea issues have, well, multiple issues even as pure bug trackers, starting from the fact that they are limited to a single repo.