They supposedly can be disabled in settings- but we all know that won’t last. They’re going full Microsoft Skype mode and it’s only a matter of time.
They supposedly can be disabled in settings- but we all know that won’t last. They’re going full Microsoft Skype mode and it’s only a matter of time.
We used Slack and we had a Confluence Wiki. No one bothered to keep Confluence up-to-date because everyone was just used to ask ad-hoc questions on Slack and get an answer by one of the respective team members. We “solved” this issue at one company with one reasonably simple policy: people were free to ask questions on Slack as much as they wanted, but the response should always have a link to the related Confluence page. You could even answer the question directly with a TL;DR, but the Confluence Page link should always be part of the answer.
Every time that there was an Slack response without a link to Confluence, the responder’s team would get a mark, and every month the team with the most marks would have to bring something to the rest of the company. Basically, it forced everyone in the team to step up their documentation game, and it got everyone in the spirit of “collaborative editing”: sometimes, people would just write create a page with a very basic paragraph. Another team member would use that to extend the answer and so on. In just a few months, every department had a pretty solid documentation space and we even got used to start our questions with “I looked for X on Confluence and didn’t find anything. Can someone tell me where I can find info about it?”
So, yes, you are right about the disconnect between “what experienced people want” and “what beginners want”, but even in this case it would make sense if most project managers used real-time chat platforms only for initial inquiries and triage, but used this inflow to produce long-term content in a structured document or wiki.
This seems like a reasonable approach when all actors are being paid to contribute.
I think where discord actually ends up helping is for community projects where everyone is basically a volunteer. It works because it lowers the barrier to helping.
The official documentation of your favorite programming language or highly popular library or framework is probably pretty locked down with a semi high quality bar for contributions. This is a good thing, those docs are consumed by lots of people and the documentation has no context for what the person is trying to do so making sure they are clear, concise, and easy to understand creates a high quality bar.
A lot of projects end up with enthusiastic helpers who probably aren’t going to dedicate the time and energy it takes to become a core maintainer. You can either leave these people and their possible helpfulness on the table or you can harness it with a discord server.
People that might not be the right fit for writing an in-depth general purpose getting started guide are still pretty great at answering peoples questions when given context and the ability to discuss it back and forth. That’s what projects are actually taking advantage of, a large group of people that are willing to help others learn how to use the programming language / library / framework.
The people they help end up having a good time with the friendly helpful community and hang out and help others. If you do it right you get this virtuous cycle where people using the thing you made help each other be successful making the thing you made even more popular.
RTFM, is ok in a corporate environment when part of your paycheck is for RTFMing. But for the last 70 years people that know how stuff works have been shouting RTFM at people wanting to learn how stuff works. But some people just aren’t good at RTFM or plain don’t want to. Discord, and other chat platforms, end up facilitating their learning models.
If there is one belief that I’ve held for long is that we Free Software would be in a better situation than it is today if we simply dropped the whole idea “community”, “done by amateurs” and “volunteers in their spare time” and really start treating the whole thing as a professional industry. This whole xz crisis further exacerbated this belief.
Almost everyone takes this work for granted and this is why is not properly valued. We should raise the bar at all levels: someone who wants to contribute in a project needs to show that they can deliver everything, maintainers should not accept “half-baked” proposals because “it is better than nothing”, developers should be more than comfortable sending a quote with a proper rate to someone that requests a feature.
And if those people don’t want to do any of that, then let go see how much the commercial alternative would cost them.
I get the frustration and there’s a lot of free software that is so vital to our modern way of life that it’s crazy that it’s always one dude in Nebraska maintaining it for the last 60 years for free as a hobby.
That said, I think you should consider the great landscape of dependencies and who the competition is.
For example, I’ve open sourced a bunch of things in my life and I have a library used to make testing more ergonomic. I worked very hard on it and I like it. There are other libraries that solve this problem to, I’m biased, but I like mine the best. I like when I can help people write higher quality software with nicer tests.
My “competition” isn’t commercial offerings it’s other free offerings. Now in the grand scheme of things, it doesn’t really matter if anyone ever uses the thing I wrote, but since I wrote it and put it out into the world I get to decide how I want to interact with the wider community of people that use it or might think about using it.
If I take a hardline stance, everyone has to be committed, but the right quality bars, do things the right way, etc. I’m free to do that. The most likely outcomes are two fold. One, I’ll have a very high quality thing to my standard. Two, probably not a lot of people are going to be using it because I’ve made it too hard to participate and they will go off and use an inferior solution. Again, if it solves my problem no big deal. But I might be missing out on someone that, if they had been allowed to participate more easily, could have made my thing better, faster, more secure.
So that’s the bargain. Do you have strict controls and limit your exposure to the good and bad out there in the open source community. Do you have lax controls and expose yourself to all the good and bad. Most maintainers end up shooting for the middle, open enough that good contributors can come and flourish but strict enough to keep bad contributors out. It’s a spectacularly difficult problem though, so I’m always happy to hear how other people think about it.