Hi Sergio,

I don't understand how this:

On Tue, Feb 17 2026, Sergio Pastor Pérez wrote:
> Maybe I have not been clear. I'm not proposing to remove any of those
> platforms, the expectations for those have no reason to change, people
> know what to expect from a mailing list; and if they do not, the will
> find out as they use it.

is consistent with this:

> So I don't think that allowing newcomers to participate on the mailing
> list from a Zulip webclient will necessarily change things for the
> mailing list.

Especially if you're also imagining bridging IRC to Zulip. If the one
space (Zulip) is interacting with both mailing lists and IRC, do the
newcomers using it just need to remember to apply different expectations
in the different channels/topics?

I also think it would be technically tricky to do a bidirectional bridge
between a Zulip channel and a mailing list. There is support for a user
interacting with Zulip entirely via email[1], but that's not the same as
bridging to an existing mailing list.

You can get mail from the mailing list into Zulip pretty easily, but
it's harder to get messages from Zulip back out to the mailing list. You
could probably add the mailing list as a Zulip user, and set it to send
notifications as emails to the list, but that would be pretty horrible.

> The idea is not to replace what we have, but to open new doors to
> different interactions that our current media does not allow.
> [...]
> ... use Zulip for fast troubleshooting problems and recommendations,
> which is the role that most of our fragmented chatrooms are fulfilling
> (Matrix, IRC, XMPP, Telegram, etc).

Adding Zulip will, in the short term, add to that fragmentation. I'm not
as optimistic as you are about the bridging, so I can only imagine us
reducing fragmentation if Zulip replaces at least one form of
communication.

As another relevant factor, we should consider friction. I think Zulip
is an option with high friction for casual use, while being great for
regular use. In some ways, that's the opposite of what we want for
newcomers. There are two particular things that I've struggled with for
communities using Zulip:

- I have joined Zulip organisations for several projects/communities,
  but because each one is on a different domain and with a separate
  login I usually forget to open them and be involved. (You can turn on
  email notifications as a potential solution to this, but I don't like
  to do that for various reasons.)

- Zulip's threading model is excellent, but it's also unusual. My last
  team switched to using Zulip for our internal chat and almost everyone
  complained about the threading model at first. If you're coming from
  almost any other chat application then there's a learning curve before
  you can use it well.

In practice, at present, I do not meaningfully participate in any
communities using Zulip.

I feel like I should reiterate: I really like Zulip. It's probably one
of my favourite pieces of software, and I will happily sing its praises.
However, I'm not sure that it's great for newcomers, and I firmly
believe if we're going to use it effectively then the community would
need to commit to it, not just add it on top of what we already have.

Carlo

[1]: https://zulip.com/help/using-zulip-via-email

Reply via email to