Hey Sergio, I'm a big fan of Zulip as a communication tool. I've used it for various teams, and I think it's shockingly good. I did want to comment on one thing, though.
On Tue, Feb 10 2026, Sergio Pastor Pérez wrote: > I'm not familiar with it, I think it does not provide the sync/async > hybrid workflow that Zulip does. I think conflating sync and async communication is not purely positive. As someone who lives in a different timezone of the Guix community (UTC+11 at the moment), I benefit from the separation between sync/async communication in two ways: 1. I know what's expected for response times. With something like Zulip it's not clear how long you should (or will) wait for responses. I think the Zulip UI nudges you towards the sync paradigm, despite supporting async well. If you get some quick responses then you may end up feeling like you've resolved a conversation before everyone has had a chance to be involved. This can make things go faster, but can also exclude people who aren't able to engage at that pace. I've seen this happen in my own distributed teams in the past, where people disengage entirely because they're usually asleep during significant conversations. 2. I don't feel pressure to keep up to date with what's happening on IRC. I generally assume "if it's important, there will be a thread on guix-devel about it", so I'm only on IRC opportunistically (and usually just to help people who need help). The assumption that guix-devel is the place to watch has already been partially eroded by the switch to Codeberg (it's still async, but I find it much harder to keep track of everything). Switching to Zulip would put more pressure on me to keep up on the sync conversations to stay in the loop. I'm not completely opposed to the idea, because I think Zulip is great, but I would like us to be mindful of the costs of collapsing sync and async communication into the same form. I think it is possible to avoid these costs by establishing expectations carefully, but that won't happen automatically. Carlo
