Ugh, very true. Folks forget that most FOSS work is volunteer & berating the hackers who make it won't help one bit. Worst is the issue reports about a fixed bug, followed by "What version do you have?" aaaaand silence. At the very least come back and close the issue.
What are we doing next, what version did we fix Y in, what VCS branch are we working on Z in, who is working on X, etc. are separate from Who reported problem, what version of the product do they report having used, what did they expect and what did they get, is that part of the design of the product, did they ever get back to us, etc.
The other problem is ill-defined roles. If everyone's a developer is a support volunteer, is a user, then you can have people be pretty shitty and reflect on the project in a way that they shouldn't be allowed to.
Random users should be able to file support tickets, but only to view project management tickets.
Only designated volunteers should be able to respond to existing support tickets and create project management tickets from them, these people speak as the public face of your project, that's really really important to have a handle on.
Support tickets probably shouldn't be public, for that matter.
Now of course this is all unpaid, volunteer -- I'm not saying any of these queues should have a defined SLA or anything. By all means keep project a bazaar -- let support queue handle outside feature requests and feedback and everything -- continue to have a public repos, roadmap and changelog, etc.
> Support tickets probably shouldn't be public, for that matter.
Open GitHub issues, combined with Google, have turned out surprisingly useful to me as a user of open source packages. Often an answer to some trouble I've run into is found in an issue -- both 'support' ticket style issues, and development roadmap style issues, and the line sometimes gets blurred.
Also, there's a positive aspect of the blurring of the boundaries in open source -- when a user contributes code, or documentation.
But yeah, people running open source projects need to at least think about how they're going to deal with project management as well as support at some point, and just the thinking about it and the iterating to figure out how to do it better is for some a chore they don't want to do. The projects that figure out how to do this well are the ones that are a joy to use or to contribute to though.
Oh, and my experience I'm talking from is with open source code packages meant for use by developers. Open source end-user applications (including OSs like Linux) are a different animal, and are _much harder_ to deal with support and project management and the overlap, in my observation. Not sure which you were thinking of, but now I'm thinking maybe end-user apps.
There's also nothing preventing common support issues getting turned into documentation improvements, creating googleable (but more concise) results. I'd rather find a wiki page for "libchitz Error: Insufficient Flurbos in /var/lib/blips" than a forum post/issue with tens of comments and have to scrape through the results.
Also, there's plenty of times googling something should get you a documentation page on a subject but instead gets you forums/issues/etc. that aren't helpful.
Nothing but someone with the time, willingness, and skill to do it well. Which is not nothing. A lot of the amazingness of GitHub's effect on our work is how it gives us lots of useful stuff that happens as 'byproducts', without someone needing to spend time and energy to do it well.
- https://www.jwz.org/blog/2013/02/wow-remember-when-people-tr...
It’s hard to find a good solution.
Which a lot of people in the free software crowd dislike, because of privacy implications. I, personally, dislike it, too.