regarding your first point: often there doesn't seem to be a dedicated support channel/community. Mailing lists are less and less popular, if one exists its web interface is likely a long way behind GitHub. There are no forums. Some languages have project-independent channels (e.g. message boards for python users will try to help you with whatever library you're messing with right now), but they don't exist for all ecosystems and are shrinking. Stack Overflow has a low tolerance to badly asked questions and a reputation for it (and probably killed the message boards that dealt with them before).

Initially, it makes sense that questions go to Github (public, no extra infrastructure needed, no community yet), but at some point they have to be moved. Even a %project-questions repository might help, if enough non-core-devs take care of it.

EDIT: to add to the last point: if a core contributor has to click the "close issue" button on a question that's a problem. Either give community members the power to do so (at least some are going to feel honored by that, a great motivation), or push questions to a channel that doesn't have that notion.

Project Q&A sites, subreddits, and IRC channels are a pretty good solution to this (based on my experience with Rust for the latter two), as at least it separates "support" from "issues". Doesn't fix toxicity, that requires consistent and effective moderation, another thing Rust does well.

I agree subreddits and IRC, can be moderated by users who don't need to directly have repo access, sort of an abstraction, unlike how github repo members/collaborators would, can be a huge assist to eliminating that toxicity. It even has the potential to be handled before the negativity ever gets to those who have so much going for the project, unlike github issues currently which really require the collaborators who have usually contributed a lot to the project, to directly mitigate the toxicity there. I think it would be a great asset if github added the ability to give certain collaborators access to issues only which might aid in fixing this issue allowing there to be sort of moderators/support users who love the project but maybe are better at giving back by moderating issues more than contributing code.

Sort of like gitlab's Reporter role?

Also, the biggest problem with IRC/subreddits with a dedicated community team is that it takes a long time for many projects to reach the point where this is feasible. Rust is large enough it's fine, but many small projects (like what's common in the JS community) will never get enough people to dedicate some of them to "community management".

I think so I haven't used gitlab enough. Yeah libraries do need to become large enough but I think angular2 is ~19k stars & 2k watchers which is more than expressjs/express watchers but less stars, but it depends because I do sort of this role with expressjs/session which is pretty small 1-2k stars I try to help with what issues I know how to and to get all the information from the users to help debug. We have only had one issue (that I know of) of users negatively critiquing the library.

  > often there doesn't seem to be a dedicated support channel/community

That got me to post in "issues" a few times, while apologizing and pointing out they should have a forum. It's so easy too: Just create a new subreddit (or use an existing one) and - that part is important!! - point to it as an official channel. Flow(type.org) is an example. Their "support" links are: SO, Github issues, Twitter, IRC. All of them are very bad for discussing general usage questions. If your question isn't already very well formulated and very specific, with code, SO will downvote and close your question. IRC or any chat mixes everything and it is about that particular moment, it does not collect people's responses over the course of a day or two.

Oh and please don't create your own forum. Almost all forum software sucks. As much as one wants to complain about reddit, their forums work, and I mean the technology and design and usability. There is a Flow subreddit, but since the Flow support page doesn't point to it it's pretty empty. Flow is just an example.

There isn't a dedicated support channel because OSS contributors don't want to support a project - that's a job you need to pay someone to do, they just want to write some code that scratches their itch. If you want more than this you need to be prepared to put down some money.

Stack Overflow and forums certainly do not pay their contributors. Many forums do not even pay their moderators. Just because there are coders that do not enjoy these things does not mean there is nobody who does. The tricky bit is to find the right people and allow them help as efficiently as possible.

I had a recently gone onto SO, and a question was asked about an error in a minified file... I suggested he try the unminified version to see if the problem still existed.. I was then asked where to get the unminified version. It went downhill from there...

People really expect people volunteering time out of their day online to walk through how to troubleshoot an issue. It gets aggravating and it seems half the questions are like this.

I agree 100%. GitHub muddles the contribution process and support process. Couple that with the irony of developing free software using a bunch of proprietary, commercial tools, and I much prefer the tried & true IRC/mailing list approach to the trendy Slack/GitHub stack.

I think a large part of the problem is that the current generation of new developers is completely conditioned by Facebook, Google, Dropbox, etc to relinquish control of their data rather than deal with the slightest inconvenience of configuring an IRC client or whatever else it may be.

I'm sorry, but having lived in the times where sourceforge was the old github, this strikes me as quire absurd.

Firstly: sourceforge was widely used and was also hosted – the architecture didn't really change.

Secondly: Github is simply the best thing that ever happened to OSS. It's a fantastic interface that allows you to:

- Immediately get a sense of the project: You know where to look and can quickly scan Stars, Issues, Checkins etc.

- Makes contributing a no-brainer: I never ever sent anyone a patch by email. With GH, it's basically more difficult NOT to contribute back.

- Makes forking easy: OSS projects often stagnate. Now, someone can fork the project, maybe update the dependencies and get it running again in half an hour or so. There's a graph right there showing you all the forks, so it's easy to figure out which one you want to trust.

- Makes discovery easy. I check the trending repositories every few days, and there's no better way to learn than to get lost reading other peoples' code.

- The whole industry of CI platforms etc. being given out for free to OSS projects was created around Github.

So I'm quite happy people are happy to "relinquish control of their data", considering I don't even know what that's supposed to mean in the context of OSS.

Creating barriers or deliberately keeping them up is never the solution. Every time you create more obstacles, you'll end up losing a future contributor or two. Contributors that might end up solving larger future problems or ones that end up owning the whole project after you have moved on. It's not about the slightest inconvenience and obviously you might get slightly larger signal-to-noise ratio but when was the last time keeping into your own small bubble paid off? Most likely never.

At the Brackets project (https://github.com/adobe/brackets) we have seen lots of new active contributors that started from none to giving steady stream of PRs and the effort needed for that was just a slight push to the right direction.