[Tools-discuss] Zulip Trial & the IETF

[Tim April <[e-mail]>]

Hello IETFers. As the chat system trials continue, I figured I would add 
my thoughts on how the Zulip service might fit into existing IETF work 
flows. If there are any comments / questions / suggestions about zulip 
or the text below, please let me know. (I have also posted this text to 
the Zulip trial server 
[here](https://zulip-trial1.ietf.org/#narrow/stream/19-trial1-feedback/topic/Zulip.20Trial.20.26.20the.20IETF/near/15457))

Thanks,

--tim

## Overview of Zulip

First, if you're new to Zulip, I would recommend reading the [Getting 
Started with Zulip (~300 
words)](https://zulip-trial1.ietf.org/help/getting-started-with-zulip) 
documentation found on the Zulip trail server. This is a quick intro 
written by the Zulip developers and some of its users. I would also 
suggest going a little deeper into the documentation, specifically 
reading about [Streams and Topics (~300 
words)](https://zulip-trial1.ietf.org/help/about-streams-and-topics), 
which covers the Zulip conversation model.

The most important difference, in my opinion, between Zulip and most of 
the other popular chat systems is their conversation model. With most 
systems, like Slack, Matrix or even XMPP, conversations are separated 
into channels, rooms or chat rooms respectively. For some of the newer 
chat systems, threads have been added to conversations as an after 
thought, but in Zulip, threading was an initial design feature so the 
system was built to support threading, in a similar way to email.

Zulip started out as a web based re-implementation of 
[Zephyr](https://en.wikipedia.org/wiki/Zephyr_(protocol)) to allow 
better separation topics within a conversation, very similar to how 
there are threads within a mailing list.

As Zulip has grown over the years since it was introduced, the threading 
model has remained nearly the same, and in the 6 years I have been an 
active user, I have found that it helps quite a bit with focusing on the 
topics I need to focus on while letting me go back and review other 
conversations as I have time.

## Proposed use of Topics

Since the new chat system trials have started, I have spent some time 
thinking about how the IETF might make use of Zulip if it were to be 
selected as the replacement for XMPP. Below are my thoughts on how 
conversations might happen in the tool. It is important to note that the 
way conversations happen in Zulip tend to drift towards a set of roughly 
agreed on norms rather than any hard and fast rules.

### Working Group Use

For each working group, I would think that it would start out with two 
Zulip streams, one would be for the mailing list mirror and the other 
would be for other discussions like what exists in XMPP right now.

For the mail mirror, I would imagine that this stream would be set up to 
receive messages from each of their respective mailings lists. As an 
example, in the trial system, the stream named "list:dnsop" receives any 
messages to [e-mail].

Additionally, another stream would be setup for discussion within a 
working group which might just be the working group name like "dnsop". 
In the working group stream, conversations about current work could take 
place with its own topic in the stream for each piece of work.

In addition to using public streams, a private stream could be employed 
to allow working group chairs to communicate with each other. Depending 
on their work flows, the working group chairs may wish to have their 
mailing list(s) copied directly into Zulip, or to just use the system as 
a chat replacement.

It is also worth noting that additional streams could be used to further 
separate some work items, such as focused work on a particular draft. In 
the case where a draft has its own stream, there might be different 
topics for each work item that is open for the draft. If the draft is 
using GitHub, there might be a conversation in the stream for each of 
the GitHub issues to better separate each of the conversations.

Speaking of GitHub, Zulip does have an extensive set of 
[integrations](https://zulip-trial1.ietf.org/integrations/), including 
GitHub which can send all sorts of events directly into Zulip as changes 
happen to the repository.

### Non Working Group Lists

Like working group use, non-working group lists can have similar 
integrations using the "list:" prefix for the email mirror and then a 
separate stream for chat based discussions.

## Archiving

One concern that might come up is archiving messages sent to Zulip, 
similar to how all email messages are archived. There is a 
[zulip-archive](https://github.com/zulip/zulip-archive) tool maintained 
by the Zulip developers which can export all messages in public streams 
to a HTML format for archiving. Other alterations to this tool could be 
made to archive directly into the mail archive maintained by the tools 
team if it would seem valuable.