Why Slack Is Inappropriate for Open Source Communication

"Reposting from the fabric mail list… Some discussion arising at the Montreal Hackfest community health meetings. Tldr: chat has downsides. Think about whether your conversation should be on the mail list. Excerpted from the Dave Cheney’s blog (linked 'above') “Slack, et al, are based on synchronous communication, which discriminate against those who do not or can not take part of the conversation in real time. For example, real time chat discriminates against those who aren’t in the same time zone–you can’t participate fully in an open source project if all the discussion happens while you’re asleep. Even if you are in the same time zone, real time chat assumes a privilege that you have the spare time–or an employer who doesn’t mind you being constantly distracted–to be virtually present in a chat room. Online chat clients are resource hogs, and presume the availability of a fast computer and ample, always on, internet connection, again raising the bar for participation.” Below, Brian relates some of the practices that were effective with Apache. I feel our use of Git is excellent in capturing a healthy review of appropriately scoped commits. I also think our new RFC process is working well. It directly captures the design rational both as the RFC and in the review dialog. Some of that design discussion benefits from being in realtime and ends up on rocketchat. To Dave Cheney’s point, though, it does strain or exclude contributors in other timezones. Most of our RFCs are probably up for too long before being approved so I don’t think that chat has become a real issue – yet. The last point that comes to mind is our sprint planning. We have eliminated our only community sprint planning meeting. That was the right decision both for geographical diversity issues as well as the reality that we all operate on different sprint cycles. Think about how we communicate direction to each other outside of that meeting. Does Jira become more important or do we stop paying attention to it and sort of diverge on our own priorities independent of Jira? Cheers, Dan"