Great. Again, I hope everyone's had a great first day at FOSSTEM in person again, and
thank you for staying to the last presentation. My name is Lauren, and I'm a software engineer
at Condor Labs, and I work on the open source project ZULIP, and I'm going to be talking
about how you can collaborate via chat, hopefully transparently, efficiently, and asynchronously.
So as a collaboration tool, and we're thinking especially here as open source communities,
open source software projects, open research projects, what are some of the benefits of
chat that we have? And really, I mean, we have so many collaboration tools and communication
tools. We have email, we have our issue trackers, but chat can really be a place of generating
some community and connection, and also it's kind of a low friction, lightweight place
to connect, right, and create some of those things. So it's a really, can be a really
beneficial place for our projects, but it comes with some challenges. So who here works with
some folks that are maybe in a different time zone than them? Yeah, me, I definitely do.
And so that can be really challenging if you have a chat application going because we think
of chat as being live, right, when we're all sitting down at our computers together,
but if you're working with someone in a totally different time zone, then your chat is not
going to be synchronous. It's going to need to be functional in sort of a different sense.
So that's a challenge of chat in our communities. Also in our communities, we have so many
things going on, right? We have new features that we want to implement. We have bugs that
we're fixing, issues that we're dealing with. We have releases to manage, conferences to
attend. So we've got a lot going on and that can really make chat become very overwhelming
very quickly. And we have a lot of different folks in our communities, right, and they
all have different needs and play different roles. And so I'm going to go through an analysis,
and I encourage you to kind of think about your open source community, your open research
community maybe, and these roles and what their needs might be, in addition to the ones
that I've kind of specified here. So project leaders, the folks who are leading the charge
of your project, the people who are making it happen, what are some of their needs and
challenges with chat? Well, they want to be there and have those connections with the
community in chat, but they also really want to make sure that they're not missing anything
in chat, right, if they're not there. So there's this kind of balance between connecting and
also being able to step away from it that we have as project leaders. We have core contributors.
I'm a core contributor to Zulip and when your core folks come on, you know, they're working
more often, they're checking on a chat more often, but what they really want when they
check in with chat for it to be some relevant to the work they're doing and helpful that
they're participating in chat. And then they also kind of want to be able to go away and
focus on their work and then come back to chat. So it's again this kind of coming and
going that becomes a challenge. Our casual contributors, folks who are maybe invested
in our projects but are not there day to day, folks who are checking in maybe on the weekends
or once in a while. So what about these folks? Well, honestly, if the chat is just a big
volume of messages that are coming in in this huge stream, they may not even use chat as
a collaboration tool, right? Because when they come in and see that there are hundreds
and hundreds of unread messages that they have to sort through and see through, they're
going to say, hey, I'm going to go somewhere else to collaborate. I'm going to look at
the issue tracker. I'm going to be on the email list or whatnot. And they're not going
to really know what's going on in the way that chat is. So that can be really a challenge.
If we want our communities to grow, we need new folks coming in, right? New contributors,
new people getting invested in our projects. And when they come in, we don't want those
people lurking, hiding. I don't know what to do, what's going on, you know? We want
those people to be able to feel like they have a space to step forward and start participating,
right? Have a voice and not be kind of this shadowy person in the background until they
figure things out, right? And we want them to get a sense of who our community is, what
they're doing, what we're doing together, what we're building. And we have end users,
right? The people who are using our projects. So when they come into a chat, again, it's
overwhelming, lots of conversations going on. And they have a question or a doubt or
maybe some feedback to give. They may not choose to do that in your chat if there's
not a space for them that they feel like their voice is going to be heard, right? So if it's
this kind of chaotic, loud, cacophonous, like chat, hey, what's going on, da-da-da-da, lots
of things going on, they may be like, all right, no, this is not, I'm not going to be
able to engage here. So we really want to create a chat space that they can have these
needs met. And, of course, we have lots of interact, we're talking about interacting
with these people, but it was 20 minutes and kind of going on. These are kind of three
characteristics of collaboration and communication with chat that I've identified as being kind
of core to serving open source, open research projects. And that's as well as live having
an asynchronous ability to chat, having an efficient chat experience, and having a transparent
chat experience. So something that we're working on together.
So going back to Zulip, again, I'm a contributor to the Zulip open source project. It's 100%
open source, modern chat application. We have many, many contributors from all over the
world, lots of people making their first time contribution to open source through either
an internship program like Outreachy, or Google Summer Code, or just for their own interests.
And folks can choose to self-host, obviously, open source, their own server with their own
chat application, or we also host Zulip Cloud for folks who want to be organizations on
the cloud. So let's start talking about tackling those characteristics that I talked about.
So Zulip has this unique topic-based threading model. So you're probably familiar from chat
applications who has, everyone has a chat application they're using, right, with some
shape or other on their phone or whatnot. So we have maybe, we call them in Zulip, we
call them streams. You might be familiar with them as channels or rooms. And this is kind
of the big bucket that we set out for conversations that we're having. And the thing about Zulip
is we create another layer of context in our streams. So, for example, I have an image
here of a stream for our annual summit that we're having. We're going to have a great
time at our annual summit. And we've actually, within our annual summit conversation, our
stream, we have topics that are coming in and binding those groups of conversations
together, kind of like an email subject line would have. So it's the end of my day. I've
just got my CI passing on my issue. I'm super excited, but I'm going to sign off. But I
signed into chat just before I go, and I look and I have 78 unread messages in my annual
summit stream. And I was supposed to check in about this today. And I'm looking through
it and I look up, I open up the topics and I say, you know what? They are having a very
lively discussion about a bouncy castle at our annual summit. But you know what? I don't
like bouncy castles. I could care less about the bouncy castle. I have no interest in bouncy
castle. I'm not going to be jumping in the bouncy castle at the summit. So that is 48
messages that I know right there from the topic. I don't need to read right now. I can
save those for later. I can mark them unread now, whatever I'd like to do. But I can look
at these topics and say, you know what? I'm really interested in the catering because
I know some people attending our summit have some not allergies that are very severe. And
I want to make sure that's part of this discussion focused on our catering. So I'm going to look
at that topic and that focus conversation context there. And if no one's brought that
up in those four different messages, then I'm going to put in a pertinent question there.
Hey, do we know that people are coming with not allergies? Are we making sure our catering
is accommodating that need? So by reading through my topics, topic by topic, I can focus
on what my interests are, where I can add value to the chat, and it makes the whole
experience much more manageable. So topics really make asynchronous chat work. We now
have folks all over the globe who can participate with more contextual feedback when they're
online. So again, if they really care about that bouncy castle conversation that happened,
they can still jump in and add their feedback there. Again, we make some space for people
whose voices might get lost, new folks and users. And so chat becomes more useful for
them. But of course, topics are being used by humans. Humans do not always work. We don't
have conversations in straight lines. We don't always make sense all the time. And we need
to make sure that they work with the humans that are working with them. So at Zulip, we've
made a number of tools to work with this kind of patterns of conversations that we have.
So for example, maybe we have this really, we have this new feature we're implementing
during this really intense design conversation in our design stream. And somebody has this
really great new idea right here. What we're going to do is take that new idea message.
We're going to move it over here to its own topic with the new idea. We're going to create
a link between these two topics in the same stream for the design. And now we have two
parallel topic conversations going on in the same stream about design that have context.
We can go back. We can connect them. Maybe we're having this really intense conversation
about the new release. And we have a really excited new contributor jump in to say, hey,
my name is, and I'm really excited. And what do we do? How do I get things done? And we
can take that message, move it over to the new person stream, say introductions. Hi,
welcome. We're so glad you're here. Please read our documentation. Let us know if you
have questions. And this really important release conversation that's going on in our
release stream continues uninterrupted, and we keep our flow organized and efficient.
Maybe you have some come in with a help question, right? They're asking for help. They're working
on upgrading to the new release. They have some questions. They've had some issues. Some
of our SysOps people get on, work with them with a question, and they come to a resolution.
That user can then mark that topic as resolved. A big check mark will show up in front of
that topic visually. And now we know that that question has been answered and resolved.
And so we have this kind of, they have the ability to step out and say, hey, you know
what? My question was answered. Thank you so much. This is done. So again, creating
organization within our topics makes things more efficient. People can prioritize their
time. We can move conversations forward. And people have agency to say, thank you. I'm
done. Or, hey, this unresolved this topic. We thought we fixed it, but we didn't. It's
still an issue. Let's unresolve it. And we're building up all of this. These conversations
are happening. They're branching off here. They're branching off there. They're branching
out there. And we built this big tree, this repository of knowledge. Now our chat is not
something ephemeral, happening in the moment. We're really starting to create sort of a
repository of knowledge that's there for everyone to share. So we've got this asynchronous
conversations. We've got this repository of knowledge. What about the transparency, right?
So in our most recent Zulu release in November, 6.0, our public access feature was landed.
And what public access basically is, is an organization with a Zulip can decide, you
know what, that help stream we have, that's really important information we want to share
with everyone. So we're going to make that web public, which basically means that anyone
on the Internet can access those conversations without signing in and without logging into
your Zulip. So that now is information that's on the Internet available to anyone. Whatever
their questions are, however they get there, they can start accessing that information.
Those help questions right away. Maybe we have our design conversations and we don't put
those in a public. So people know, what is our design ethic? Where are we moving? What
are we working on? And we can make that web public and people can engage. Maybe we've
had this really great conversation about a new feature that we're implementing in our
chat. And we have over here in GitLab our issue tracker for that feature. We can actually
now, if that conversation happened on a web public stream, we can take that, make a link
to the chat. And again, anyone who gets to GitLab and looks at our issue and says, oh,
there's more information here, click relevant chat conversation. And now all of that information
without logging in is available to that person. So again, we're really taking our chat with
the public access and moving it beyond our community and making it relevant to anyone
who's curious about our open source, our open research projects, like what we're doing.
This is a value of open source that we have. So again, if we're making decisions in chat,
this is available for people to see. New community members can start learning before they even
sign up. And we have this repository, this tree of knowledge that we built that's now
out there in the wild, in the forest of the internet that we have, that we're sharing
with everyone. So really creating that transparent and chat's becoming much more relevant beyond
just an ephemeral conversation. So as I mentioned, Zulip is 100% open source, free. You can
start your own server. And we also have our Zulip Cloud, which has a free level of support,
similarly to Slack before they made their change this summer, which is like limited.
You have a certain history of messages. With non-profits, open source projects, academic
research, we actually offer sponsorship on our Zulip Cloud standard, which is normally
a paid platform. So you get even more history available to the public. It's not limited.
That public access is there. So we really are committed to being part of the open source
community and making sure that all of our projects have great connection, collaboration,
and are engaging all of the people who want to be involved in the organizations. Again,
thank you so much. That's about it for me. I have some great links that are in the slides
here. The community's directory is a directory of organizations on Zulip that have opted
into the public access already. So if you're curious, that's a great place to start looking.
You can find me at Zulip Development Community. That's where we are talking about Zulip and
the features that we're implementing and what we're doing. We have some case studies, etc.
So I want to open it to questions or I can jump into one of these open Zulip instances
if anyone's interested. Yeah, so thank you.
Yes. So for topics to work efficiently, you need to be really strict with moving messages
around. That means that moderators, I guess, would have to scan every message and move
things around. Yeah, yeah. So the question is, for topics to work and we're moving things
around and when people come in, you take on a lot of moderators who have to kind of be
very active and efficient in that. Yes, definitely in my experience in Zulip Cloud, it depends
on your organization. You can actually set that up. So for example, just moving topics
within the same stream, like maybe somebody didn't name it very well, you can actually
set that permission level to a generic user right now and we're actually working on our
user groups so that they can be even more designed to be unique to the organization.
So like those levels of permissions can kind of be shared out throughout your user base.
So we actually have this in our new users a lot of times are coming in and to Zulip who
want to contribute and they're sending messages and very quickly, they'll start actually,
if they see a message kind of go jump into a stream and interrupt a conversation, they'll
even just move that out right as like a person maybe who is there for two weeks. But it does
require that kind of communal engagement, but you can disperse that so it's not just
on your core contributors or your moderators, it can kind of be dispersed and hopefully
with user groups which is a feature that we're working on and planning, that'll be even more
can be fine tuned to your organization and how you, the community you want to create
with your Zulip chat. Other questions, yes.
Right, so each Zulip organization is deciding, so the question is how do you control privacy
with public streams and what's going on for the folks listening at home. So definitely
your organization is deciding what streams are web public, right? So that is definitely
kind of when you sign on and you're posting in those streams, it's kind of like this information
is available in general on the internet. There are private streams in Zulip, there are streams
that are public within your Zulip organization that people have to sign in. So for example,
on our Zulip development community, the stream for like asking help with, for new contributors
like getting help with development, that's not a web public stream because that's kind
of folks being vulnerable and maybe asking questions and saying like, I don't know how
to do this, can someone help? Like obviously that's not something, I mean that's super
brave of them and we're proud, you know, we want that as public within our organization
but we're not sending that out to the internet. So we've made that choice culturally as an
organization. So each organization that decides. So I believe like the Rust language that's
using the public access feature, they've decided that all of their streams are web
public. So basically when you sign up to be part of that chat discussion on the Rust
language community, whatever your discussion you're having there is available on the internet.
And so that's just part of kind of like the culture of each organization that you're
setting up. You can definitely set it up so there are more privacy, you know, focused
organizations. But again, thinking about open source communities and the fact that we want
to be having, you know, there are definitely certain parts of our conversations and chats
at me. We might want to be having as publicly as possible, right? So, yeah. Any other questions?
Yes?
Do you have any integration at the end?
Yes, yes. We have lots of integrations.
Right, yeah. So you can move from Slack to Zulip, for instance.
Yes, yes. Well, GitHub for tracking issues and Zulip is a chat application work together,
yeah. So like, so we track our, we're on GitHub for our open source that's where our
code is. And so our issues link and we use integrations for like bots to communicate
and stuff. So, but definitely there are lots of integrations and such that one can use
lots of different authentication methods, et cetera. It's a fully fledged modern chat
app. Yeah.
Other questions? Curiosity. Again, if your curiosity has been for your open source projects,
please I'll be around tomorrow or come on the Zulip development community, check us
out. We have lots of public streams and I'm just been really excited to see everyone here
at Pustum and thank you for having me.