Another chat solution to consider is Zulip [0]. Zulip's UI encourages all chat messages to go under an appropriate thread which makes it a bit easier to use for asynchronous communication. I think one of the difficult aspects of using something like Slack or IRC for development is a lack of nice threading which makes them more of a synchronous communication tool rather than an asynchronous one. Using threads in Zulip, it becomes a lot easier to navigate the chat without having to read several days of chatter to find the topic you were looking for.
For what it's worth, I'm at that age near the line between people who are used to using email and people who are used to using instant messaging and group chats. I believe that a lack of good threading in chat UIs is what tends to lead to the "always online" requirement to keeping up with the chat, though most chat apps support threading at this point, so I could be wrong. Another issue with people and mailing lists these days are those who don't know or care to tame their inbox. There's a reason why smartphone notifications are used for marketing and such these days; many people's inboxes are bursting with tens of thousands of unread messages. It's been the double edged sword of simple and open protocols: ease of abuse. [0]: https://zulip.com On Mon, Feb 28, 2022 at 6:04 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > > > > > > This is much easier to manage on any channel than "talking to the > > group" which is IMO required for Apache-style development. > > > > What I mean is: > > -Everybody sees the topics of all conversations fly by > > -It's easy to ignore specific or most conversations > > -It's easy to catch up after N days of absence while the rest of the > > team has been active, by quickly skimming the thread's subject lines > > -It's easy to use Precise Quoting in replies to enable deep conversations > > > > To me, the lack of first-class discussion threads, including a subject > > line, in most chat-style channels makes it hard to support that style. > > > > Yeah. I understand that - and Agree that "subject" is important in the > "slower" conversations. Having #channels in slack somehow addresses it for > "broader" topics, but in last few weeks many times in the conversations > there I wrote: "Hey we've started this GitHubDiscussion here, let's move > the discussion there" if we felt the need to "upgrade" casual chat > to "meaningful discussion". And we did. > > That's why I also agree that for example slack might not be the "only" form > of conversation for everything. It's one of the ways. > > I am also absolutely for deep discussions, analysis and all the arguments > you mentioned. And GitHubDiscussions falls squarely in all the criteria you > mentioned - including super easy reference to code (including automatically > displaying snippets of code), issues, mentioning other users in-line, > referring other discussions (autocompletable as you type so that you do not > have to look it up and copy & paste), being able to use emoticons (yeah I > am almost 50 but I think they make discussion more fun), easy quoting (and > what I stress again) - ability to correct typos and update your comments > in-line when you find out more with the right UPDATE: statements, adding > checkboxes that you can check-off as the discussion progress etc. etc. are > all there. > > I am very proficient in using devlist for some of that. I can personally do > it rather easily and I've learned the etiquette when I started to > use devlist more often. But it is all so much easier and more approachable > using tools like GHDiscussions. > Email has a lot of friction and simply many people are excluded by default > and we "lose" their participation. I've been an Engineer and CTO of a > mobile app development company and I know a lot about good, convenient UI > and decreasing friction and how important it is. > > I think 20 years ago "devlist" as a 'common mechanism' was a great choice > and facilitated "let's give everyone the possibility to participate". But > from what I hear from people today (and feel myself), it has changed for > many communities and if anything it "prevents participation" - it stopped > fulfilling some of the basic premises it was started with. > > J. > > > > > > > -Bertrand > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
