Well, I can’t tell whether it works well or not, however what I’m absolutely certain about is that if it works, it’s 100% thanks to you given that you respond to every single post, so thanks a lot for doing that.
I just think that there are different populations. Just like there are people following kernel-related stuff on the mailing lists, others on LWN and others seeking help on serverfault, I think there are different expectations that need to be addressed.
At the moment we have two discussion channels. That’s little compared to some projects but it’s a lot for a moderately small project like ours. So in the end some users don’t find exactly the format they’re looking for, and we can hardly task more people to follow and animate more channels in various formats.
Despite this I noticed that we don’t see people complain anymore about how to serve them, so we’ve probably reached what we need to reasonably satisfy most users by adding discourse.
I totally agree on the fact that we need to complete the github migration, especially for the issues. The thing is that I’m often identified as the obvious person to deal with such things, but there are 3 important things to consider to understand why each time I have to be associated with such operations it ends up poorly :
- I’m terribly bad at anything more or less administrative and with processes. To give you an idea it took me one year to cancel my ISP subscription after I moved, just because for me it is complicated to find how to do this, so I give up.
- I have a horrible relation with browsers (I would say they have a horrible relation with me because apparently they are designed just to annoy me specifically). Even here I’m typing this response in a highly inefficient 3cm*9cm text area while the window is in full screen, being very careful not to accidently click anywhere etc, and I’ll copy-paste it into a temp file before posting just in case it gets lost so that I don’t have to retype it. Yes it’s a huge pain for me.
- it takes me a long time to learn and adapt to new tools and processes (strangely, see first point above :-))
Being on the critical path of the project, I can’t conceive to waste so much time dealing with stuff that is so complicated for me while other people have much less trouble with them.
I consider we’re a community : developers, users, bug reporters, people helping on their free (or even work) time, people writing blog articles to explain how to use certain features, those providing free service like discourse, people dealing with the minimally needed infrastructure and tools, often behind the curtains, like you, Cyril, Adrian and Benoit are doing for example.
I’m all for encouraging the community to explore different tools that people see fit. However my responsibility is also to warn people against the risk of fragmentation. At least we should avoid using different tools for the same task, especially when content is stored. An example is issue trackers. We don’t want to force people to use multiple issue trackers. And I consider that the opinion of the people who spend a lot of time dealing with issues is orders of magnitude more important than the one of those reporting a bug and leaving without even saying thanks sometimes (and I’m among those dealing with bugs so I claim my voice here). For plain discussions it’s a bit different. When you have to meet a friend you can meet him at many places, at your home or his. Here it’s the same, we must not force people to go to a single place. But we must be clear to them about the type of services they can expect to find at various places.
What I think regarding our tools is that :
- people reading discourse regularly are those regularly willing to poll for news, or having spare time to read this. It’s very convenient for first-time reporters, and it’s convenient to index config excerpts. It’s not suited to report bugs but it’s suited to decide if what they observe is a bug or not ;
- people on the mailing list are those willing to be asynchronously notified about the project’s progress and news, and willing to quickly be able to sort out what they’re interested in and what not. Participating to design discussions is much easier there, you’re not forced to use a slow crippled browser, you can quote some sentences in replies etc, making the conversations more natural and much faster. Archives there exist now (mail-archive.com) but are less convenient to search and link to than articles on the forum.
- for issues, something like github’s issue tracker is really good. While I really hate their infamous web interface in general, for issues it’s more or less correct, and it supports mail back-and-forth, which is critical for such tools, while not that common. However we have to be aware that once we reopen it, it will become a discussion place because users will report usage trouble there considering they’re hitting bugs all the time. So it will require more manpower to keep it clean. But there might be options we could discuss with the github team regarding this. Eg if only a few people could open an issue simply by forwarding an e-mail from the mailing list after a discussion confirming the bug, it would be really cool to limit unexpected pollution, and at the same time encourage users to explain their problem (and possibly get a quick response). An issue tracker should first be a TODO list with some annotations and links to original reports, not a discussion place.
So these are mainly my thoughts on the subject. We’re still too few to share the high load of help and reports, and I really think that this also goes with crediting people for their involvement or giving them more responsibility (which will also offload us). There are roughly 10 persons on the list+discourse helping 1000 persons all the time and this is a thankless job. I don’t know how we can make this situation better. At least being recognized for their efforts is the minimum we can do and the minimum they deserve.
But seeing this from a more positive perspective, it’s what you get with a successful project handled by a small competent community. Users mostly complain about the lack of clarity in our escalation process but are often satisfied with the time we take to fix their issues. And when you think about it, some bugs are fixed in a few hours between the report here, your analysis, your forward to the ML, another developer jumping on it, troubleshooting it, fixing it, sending me the fix so that I merge it, and then you respond with the commit ID and the report confirms the fix. It’s awesome! This proves that our model is quite efficient for end users. It’s probably still harassing for the persons in the chain like you and a few others, but thinking about it for a few seconds, we would probably not estimate to ~1 million the number of deployments with a different process. And the ML, you and discourse are a significant part of this successful chain, which is why I can hardly say that it doesn’t work.
Oh by the way I think it will be archived in a totally unrelated topic here, so apparently off-topic also exists on discourse 
It’s a bit confusing and annoying to search two sources for maybe known issues. I’d prefer using github for that (it’s 2017).