[00:00.000 --> 00:14.240] Great. Again, I hope everyone's had a great first day at FOSSTEM in person again, and [00:14.240 --> 00:19.920] thank you for staying to the last presentation. My name is Lauren, and I'm a software engineer [00:19.920 --> 00:25.800] at Condor Labs, and I work on the open source project ZULIP, and I'm going to be talking [00:25.800 --> 00:39.400] about how you can collaborate via chat, hopefully transparently, efficiently, and asynchronously. [00:39.400 --> 00:46.400] So as a collaboration tool, and we're thinking especially here as open source communities, [00:46.400 --> 00:50.760] open source software projects, open research projects, what are some of the benefits of [00:50.760 --> 00:56.640] chat that we have? And really, I mean, we have so many collaboration tools and communication [00:56.640 --> 01:05.200] tools. We have email, we have our issue trackers, but chat can really be a place of generating [01:05.200 --> 01:11.280] some community and connection, and also it's kind of a low friction, lightweight place [01:11.280 --> 01:15.320] to connect, right, and create some of those things. So it's a really, can be a really [01:15.320 --> 01:28.080] beneficial place for our projects, but it comes with some challenges. So who here works with [01:28.080 --> 01:33.840] some folks that are maybe in a different time zone than them? Yeah, me, I definitely do. [01:33.840 --> 01:38.240] And so that can be really challenging if you have a chat application going because we think [01:38.240 --> 01:41.840] of chat as being live, right, when we're all sitting down at our computers together, [01:41.840 --> 01:47.160] but if you're working with someone in a totally different time zone, then your chat is not [01:47.160 --> 01:53.080] going to be synchronous. It's going to need to be functional in sort of a different sense. [01:53.080 --> 01:58.520] So that's a challenge of chat in our communities. Also in our communities, we have so many [01:58.520 --> 02:02.680] things going on, right? We have new features that we want to implement. We have bugs that [02:02.680 --> 02:08.600] we're fixing, issues that we're dealing with. We have releases to manage, conferences to [02:08.600 --> 02:14.320] attend. So we've got a lot going on and that can really make chat become very overwhelming [02:14.320 --> 02:19.120] very quickly. And we have a lot of different folks in our communities, right, and they [02:19.120 --> 02:25.280] all have different needs and play different roles. And so I'm going to go through an analysis, [02:25.280 --> 02:29.000] and I encourage you to kind of think about your open source community, your open research [02:29.000 --> 02:34.000] community maybe, and these roles and what their needs might be, in addition to the ones [02:34.000 --> 02:40.240] that I've kind of specified here. So project leaders, the folks who are leading the charge [02:40.240 --> 02:46.240] of your project, the people who are making it happen, what are some of their needs and [02:46.240 --> 02:51.240] challenges with chat? Well, they want to be there and have those connections with the [02:51.240 --> 02:56.320] community in chat, but they also really want to make sure that they're not missing anything [02:56.320 --> 03:01.400] in chat, right, if they're not there. So there's this kind of balance between connecting and [03:01.400 --> 03:08.400] also being able to step away from it that we have as project leaders. We have core contributors. [03:08.400 --> 03:14.040] I'm a core contributor to Zulip and when your core folks come on, you know, they're working [03:14.040 --> 03:18.880] more often, they're checking on a chat more often, but what they really want when they [03:18.880 --> 03:25.800] check in with chat for it to be some relevant to the work they're doing and helpful that [03:25.800 --> 03:30.880] they're participating in chat. And then they also kind of want to be able to go away and [03:30.880 --> 03:34.800] focus on their work and then come back to chat. So it's again this kind of coming and [03:34.800 --> 03:42.280] going that becomes a challenge. Our casual contributors, folks who are maybe invested [03:42.280 --> 03:48.480] in our projects but are not there day to day, folks who are checking in maybe on the weekends [03:48.480 --> 03:58.160] or once in a while. So what about these folks? Well, honestly, if the chat is just a big [03:58.160 --> 04:04.000] volume of messages that are coming in in this huge stream, they may not even use chat as [04:04.000 --> 04:07.960] a collaboration tool, right? Because when they come in and see that there are hundreds [04:07.960 --> 04:11.480] and hundreds of unread messages that they have to sort through and see through, they're [04:11.480 --> 04:15.400] going to say, hey, I'm going to go somewhere else to collaborate. I'm going to look at [04:15.400 --> 04:22.280] the issue tracker. I'm going to be on the email list or whatnot. And they're not going [04:22.280 --> 04:28.680] to really know what's going on in the way that chat is. So that can be really a challenge. [04:28.680 --> 04:32.920] If we want our communities to grow, we need new folks coming in, right? New contributors, [04:32.920 --> 04:40.200] new people getting invested in our projects. And when they come in, we don't want those [04:40.200 --> 04:46.200] people lurking, hiding. I don't know what to do, what's going on, you know? We want [04:46.200 --> 04:50.400] those people to be able to feel like they have a space to step forward and start participating, [04:50.400 --> 04:55.600] right? Have a voice and not be kind of this shadowy person in the background until they [04:55.600 --> 05:01.840] figure things out, right? And we want them to get a sense of who our community is, what [05:01.840 --> 05:09.360] they're doing, what we're doing together, what we're building. And we have end users, [05:09.360 --> 05:15.320] right? The people who are using our projects. So when they come into a chat, again, it's [05:15.320 --> 05:21.680] overwhelming, lots of conversations going on. And they have a question or a doubt or [05:21.680 --> 05:25.720] maybe some feedback to give. They may not choose to do that in your chat if there's [05:25.720 --> 05:29.640] not a space for them that they feel like their voice is going to be heard, right? So if it's [05:29.640 --> 05:34.080] this kind of chaotic, loud, cacophonous, like chat, hey, what's going on, da-da-da-da, lots [05:34.080 --> 05:38.240] of things going on, they may be like, all right, no, this is not, I'm not going to be [05:38.240 --> 05:44.480] able to engage here. So we really want to create a chat space that they can have these [05:44.480 --> 05:51.600] needs met. And, of course, we have lots of interact, we're talking about interacting [05:51.600 --> 05:57.240] with these people, but it was 20 minutes and kind of going on. These are kind of three [05:57.240 --> 06:03.400] characteristics of collaboration and communication with chat that I've identified as being kind [06:03.400 --> 06:09.680] of core to serving open source, open research projects. And that's as well as live having [06:09.680 --> 06:15.920] an asynchronous ability to chat, having an efficient chat experience, and having a transparent [06:15.920 --> 06:23.520] chat experience. So something that we're working on together. [06:23.520 --> 06:28.360] So going back to Zulip, again, I'm a contributor to the Zulip open source project. It's 100% [06:28.360 --> 06:34.040] open source, modern chat application. We have many, many contributors from all over the [06:34.040 --> 06:39.680] world, lots of people making their first time contribution to open source through either [06:39.680 --> 06:47.880] an internship program like Outreachy, or Google Summer Code, or just for their own interests. [06:47.880 --> 06:52.840] And folks can choose to self-host, obviously, open source, their own server with their own [06:52.840 --> 06:58.880] chat application, or we also host Zulip Cloud for folks who want to be organizations on [06:58.880 --> 07:08.440] the cloud. So let's start talking about tackling those characteristics that I talked about. [07:08.440 --> 07:14.760] So Zulip has this unique topic-based threading model. So you're probably familiar from chat [07:14.760 --> 07:19.680] applications who has, everyone has a chat application they're using, right, with some [07:19.680 --> 07:24.160] shape or other on their phone or whatnot. So we have maybe, we call them in Zulip, we [07:24.160 --> 07:30.360] call them streams. You might be familiar with them as channels or rooms. And this is kind [07:30.360 --> 07:36.400] of the big bucket that we set out for conversations that we're having. And the thing about Zulip [07:36.400 --> 07:44.040] is we create another layer of context in our streams. So, for example, I have an image [07:44.040 --> 07:49.120] here of a stream for our annual summit that we're having. We're going to have a great [07:49.120 --> 07:55.120] time at our annual summit. And we've actually, within our annual summit conversation, our [07:55.120 --> 07:59.400] stream, we have topics that are coming in and binding those groups of conversations [07:59.400 --> 08:06.080] together, kind of like an email subject line would have. So it's the end of my day. I've [08:06.080 --> 08:13.480] just got my CI passing on my issue. I'm super excited, but I'm going to sign off. But I [08:13.480 --> 08:18.240] signed into chat just before I go, and I look and I have 78 unread messages in my annual [08:18.240 --> 08:22.000] summit stream. And I was supposed to check in about this today. And I'm looking through [08:22.000 --> 08:26.880] it and I look up, I open up the topics and I say, you know what? They are having a very [08:26.880 --> 08:32.560] lively discussion about a bouncy castle at our annual summit. But you know what? I don't [08:32.560 --> 08:38.000] like bouncy castles. I could care less about the bouncy castle. I have no interest in bouncy [08:38.000 --> 08:44.360] castle. I'm not going to be jumping in the bouncy castle at the summit. So that is 48 [08:44.360 --> 08:49.440] messages that I know right there from the topic. I don't need to read right now. I can [08:49.440 --> 08:54.760] save those for later. I can mark them unread now, whatever I'd like to do. But I can look [08:54.760 --> 08:58.000] at these topics and say, you know what? I'm really interested in the catering because [08:58.000 --> 09:02.360] I know some people attending our summit have some not allergies that are very severe. And [09:02.360 --> 09:08.440] I want to make sure that's part of this discussion focused on our catering. So I'm going to look [09:08.440 --> 09:12.760] at that topic and that focus conversation context there. And if no one's brought that [09:12.760 --> 09:18.440] up in those four different messages, then I'm going to put in a pertinent question there. [09:18.440 --> 09:22.360] Hey, do we know that people are coming with not allergies? Are we making sure our catering [09:22.360 --> 09:29.920] is accommodating that need? So by reading through my topics, topic by topic, I can focus [09:29.920 --> 09:35.180] on what my interests are, where I can add value to the chat, and it makes the whole [09:35.180 --> 09:40.920] experience much more manageable. So topics really make asynchronous chat work. We now [09:40.920 --> 09:50.360] have folks all over the globe who can participate with more contextual feedback when they're [09:50.360 --> 09:54.960] online. So again, if they really care about that bouncy castle conversation that happened, [09:54.960 --> 10:00.400] they can still jump in and add their feedback there. Again, we make some space for people [10:00.400 --> 10:09.000] whose voices might get lost, new folks and users. And so chat becomes more useful for [10:09.000 --> 10:18.400] them. But of course, topics are being used by humans. Humans do not always work. We don't [10:18.400 --> 10:23.640] have conversations in straight lines. We don't always make sense all the time. And we need [10:23.640 --> 10:26.680] to make sure that they work with the humans that are working with them. So at Zulip, we've [10:26.680 --> 10:32.680] made a number of tools to work with this kind of patterns of conversations that we have. [10:32.680 --> 10:38.040] So for example, maybe we have this really, we have this new feature we're implementing [10:38.040 --> 10:42.840] during this really intense design conversation in our design stream. And somebody has this [10:42.840 --> 10:47.080] really great new idea right here. What we're going to do is take that new idea message. [10:47.080 --> 10:50.880] We're going to move it over here to its own topic with the new idea. We're going to create [10:50.880 --> 10:55.480] a link between these two topics in the same stream for the design. And now we have two [10:55.480 --> 11:00.760] parallel topic conversations going on in the same stream about design that have context. [11:00.760 --> 11:08.080] We can go back. We can connect them. Maybe we're having this really intense conversation [11:08.080 --> 11:12.080] about the new release. And we have a really excited new contributor jump in to say, hey, [11:12.080 --> 11:15.600] my name is, and I'm really excited. And what do we do? How do I get things done? And we [11:15.600 --> 11:20.600] can take that message, move it over to the new person stream, say introductions. Hi, [11:20.600 --> 11:23.760] welcome. We're so glad you're here. Please read our documentation. Let us know if you [11:23.760 --> 11:26.840] have questions. And this really important release conversation that's going on in our [11:26.840 --> 11:33.680] release stream continues uninterrupted, and we keep our flow organized and efficient. [11:33.680 --> 11:40.800] Maybe you have some come in with a help question, right? They're asking for help. They're working [11:40.800 --> 11:45.280] on upgrading to the new release. They have some questions. They've had some issues. Some [11:45.280 --> 11:53.600] of our SysOps people get on, work with them with a question, and they come to a resolution. [11:53.600 --> 11:58.160] That user can then mark that topic as resolved. A big check mark will show up in front of [11:58.160 --> 12:03.680] that topic visually. And now we know that that question has been answered and resolved. [12:03.680 --> 12:14.560] And so we have this kind of, they have the ability to step out and say, hey, you know [12:14.560 --> 12:21.800] what? My question was answered. Thank you so much. This is done. So again, creating [12:21.800 --> 12:27.320] organization within our topics makes things more efficient. People can prioritize their [12:27.320 --> 12:33.160] time. We can move conversations forward. And people have agency to say, thank you. I'm [12:33.160 --> 12:38.760] done. Or, hey, this unresolved this topic. We thought we fixed it, but we didn't. It's [12:38.760 --> 12:43.160] still an issue. Let's unresolve it. And we're building up all of this. These conversations [12:43.160 --> 12:45.800] are happening. They're branching off here. They're branching off there. They're branching [12:45.800 --> 12:49.800] out there. And we built this big tree, this repository of knowledge. Now our chat is not [12:49.800 --> 12:53.920] something ephemeral, happening in the moment. We're really starting to create sort of a [12:53.920 --> 12:59.640] repository of knowledge that's there for everyone to share. So we've got this asynchronous [12:59.640 --> 13:05.480] conversations. We've got this repository of knowledge. What about the transparency, right? [13:05.480 --> 13:14.480] So in our most recent Zulu release in November, 6.0, our public access feature was landed. [13:14.480 --> 13:21.440] And what public access basically is, is an organization with a Zulip can decide, you [13:21.440 --> 13:25.760] know what, that help stream we have, that's really important information we want to share [13:25.760 --> 13:30.080] with everyone. So we're going to make that web public, which basically means that anyone [13:30.080 --> 13:35.040] on the Internet can access those conversations without signing in and without logging into [13:35.040 --> 13:41.360] your Zulip. So that now is information that's on the Internet available to anyone. Whatever [13:41.360 --> 13:45.920] their questions are, however they get there, they can start accessing that information. [13:45.920 --> 13:50.000] Those help questions right away. Maybe we have our design conversations and we don't put [13:50.000 --> 13:54.440] those in a public. So people know, what is our design ethic? Where are we moving? What [13:54.440 --> 14:00.560] are we working on? And we can make that web public and people can engage. Maybe we've [14:00.560 --> 14:04.640] had this really great conversation about a new feature that we're implementing in our [14:04.640 --> 14:11.080] chat. And we have over here in GitLab our issue tracker for that feature. We can actually [14:11.080 --> 14:17.000] now, if that conversation happened on a web public stream, we can take that, make a link [14:17.000 --> 14:21.840] to the chat. And again, anyone who gets to GitLab and looks at our issue and says, oh, [14:21.840 --> 14:26.400] there's more information here, click relevant chat conversation. And now all of that information [14:26.400 --> 14:31.040] without logging in is available to that person. So again, we're really taking our chat with [14:31.040 --> 14:36.480] the public access and moving it beyond our community and making it relevant to anyone [14:36.480 --> 14:40.280] who's curious about our open source, our open research projects, like what we're doing. [14:40.280 --> 14:47.000] This is a value of open source that we have. So again, if we're making decisions in chat, [14:47.000 --> 14:52.360] this is available for people to see. New community members can start learning before they even [14:52.360 --> 14:57.840] sign up. And we have this repository, this tree of knowledge that we built that's now [14:57.840 --> 15:04.320] out there in the wild, in the forest of the internet that we have, that we're sharing [15:04.320 --> 15:11.120] with everyone. So really creating that transparent and chat's becoming much more relevant beyond [15:11.120 --> 15:19.680] just an ephemeral conversation. So as I mentioned, Zulip is 100% open source, free. You can [15:19.680 --> 15:26.560] start your own server. And we also have our Zulip Cloud, which has a free level of support, [15:26.560 --> 15:31.880] similarly to Slack before they made their change this summer, which is like limited. [15:31.880 --> 15:39.080] You have a certain history of messages. With non-profits, open source projects, academic [15:39.080 --> 15:43.440] research, we actually offer sponsorship on our Zulip Cloud standard, which is normally [15:43.440 --> 15:49.600] a paid platform. So you get even more history available to the public. It's not limited. [15:49.600 --> 15:55.560] That public access is there. So we really are committed to being part of the open source [15:55.560 --> 16:04.080] community and making sure that all of our projects have great connection, collaboration, [16:04.080 --> 16:08.920] and are engaging all of the people who want to be involved in the organizations. Again, [16:08.920 --> 16:12.960] thank you so much. That's about it for me. I have some great links that are in the slides [16:12.960 --> 16:17.800] here. The community's directory is a directory of organizations on Zulip that have opted [16:17.800 --> 16:22.800] into the public access already. So if you're curious, that's a great place to start looking. [16:22.800 --> 16:26.880] You can find me at Zulip Development Community. That's where we are talking about Zulip and [16:26.880 --> 16:32.400] the features that we're implementing and what we're doing. We have some case studies, etc. [16:32.400 --> 16:38.800] So I want to open it to questions or I can jump into one of these open Zulip instances [16:38.800 --> 16:43.000] if anyone's interested. Yeah, so thank you. [16:43.000 --> 16:55.680] Yes. So for topics to work efficiently, you need to be really strict with moving messages [16:55.680 --> 17:04.560] around. That means that moderators, I guess, would have to scan every message and move [17:04.560 --> 17:11.200] things around. Yeah, yeah. So the question is, for topics to work and we're moving things [17:11.200 --> 17:17.520] around and when people come in, you take on a lot of moderators who have to kind of be [17:17.520 --> 17:25.160] very active and efficient in that. Yes, definitely in my experience in Zulip Cloud, it depends [17:25.160 --> 17:29.960] on your organization. You can actually set that up. So for example, just moving topics [17:29.960 --> 17:35.560] within the same stream, like maybe somebody didn't name it very well, you can actually [17:35.560 --> 17:40.560] set that permission level to a generic user right now and we're actually working on our [17:40.560 --> 17:46.600] user groups so that they can be even more designed to be unique to the organization. [17:46.600 --> 17:51.600] So like those levels of permissions can kind of be shared out throughout your user base. [17:51.600 --> 17:57.720] So we actually have this in our new users a lot of times are coming in and to Zulip who [17:57.720 --> 18:03.320] want to contribute and they're sending messages and very quickly, they'll start actually, [18:03.320 --> 18:08.040] if they see a message kind of go jump into a stream and interrupt a conversation, they'll [18:08.040 --> 18:12.480] even just move that out right as like a person maybe who is there for two weeks. But it does [18:12.480 --> 18:18.720] require that kind of communal engagement, but you can disperse that so it's not just [18:18.720 --> 18:22.560] on your core contributors or your moderators, it can kind of be dispersed and hopefully [18:22.560 --> 18:27.000] with user groups which is a feature that we're working on and planning, that'll be even more [18:27.000 --> 18:30.960] can be fine tuned to your organization and how you, the community you want to create [18:30.960 --> 18:37.960] with your Zulip chat. Other questions, yes. [18:37.960 --> 18:59.920] Right, so each Zulip organization is deciding, so the question is how do you control privacy [18:59.920 --> 19:06.840] with public streams and what's going on for the folks listening at home. So definitely [19:06.840 --> 19:11.840] your organization is deciding what streams are web public, right? So that is definitely [19:11.840 --> 19:17.880] kind of when you sign on and you're posting in those streams, it's kind of like this information [19:17.880 --> 19:24.120] is available in general on the internet. There are private streams in Zulip, there are streams [19:24.120 --> 19:27.720] that are public within your Zulip organization that people have to sign in. So for example, [19:27.720 --> 19:35.520] on our Zulip development community, the stream for like asking help with, for new contributors [19:35.520 --> 19:39.000] like getting help with development, that's not a web public stream because that's kind [19:39.000 --> 19:42.680] of folks being vulnerable and maybe asking questions and saying like, I don't know how [19:42.680 --> 19:46.480] to do this, can someone help? Like obviously that's not something, I mean that's super [19:46.480 --> 19:50.480] brave of them and we're proud, you know, we want that as public within our organization [19:50.480 --> 19:54.680] but we're not sending that out to the internet. So we've made that choice culturally as an [19:54.680 --> 19:59.720] organization. So each organization that decides. So I believe like the Rust language that's [19:59.720 --> 20:03.320] using the public access feature, they've decided that all of their streams are web [20:03.320 --> 20:09.080] public. So basically when you sign up to be part of that chat discussion on the Rust [20:09.080 --> 20:13.880] language community, whatever your discussion you're having there is available on the internet. [20:13.880 --> 20:17.520] And so that's just part of kind of like the culture of each organization that you're [20:17.520 --> 20:21.880] setting up. You can definitely set it up so there are more privacy, you know, focused [20:21.880 --> 20:25.640] organizations. But again, thinking about open source communities and the fact that we want [20:25.640 --> 20:29.280] to be having, you know, there are definitely certain parts of our conversations and chats [20:29.280 --> 20:36.280] at me. We might want to be having as publicly as possible, right? So, yeah. Any other questions? [20:36.280 --> 20:37.280] Yes? [20:37.280 --> 20:41.280] Do you have any integration at the end? [20:41.280 --> 20:52.280] Yes, yes. We have lots of integrations. [20:52.280 --> 21:09.280] Right, yeah. So you can move from Slack to Zulip, for instance. [21:09.280 --> 21:14.280] Yes, yes. Well, GitHub for tracking issues and Zulip is a chat application work together, [21:14.280 --> 21:21.720] yeah. So like, so we track our, we're on GitHub for our open source that's where our [21:21.720 --> 21:27.040] code is. And so our issues link and we use integrations for like bots to communicate [21:27.040 --> 21:33.040] and stuff. So, but definitely there are lots of integrations and such that one can use [21:33.040 --> 21:37.600] lots of different authentication methods, et cetera. It's a fully fledged modern chat [21:37.600 --> 21:40.440] app. Yeah. [21:40.440 --> 21:47.640] Other questions? Curiosity. Again, if your curiosity has been for your open source projects, [21:47.640 --> 21:51.720] please I'll be around tomorrow or come on the Zulip development community, check us [21:51.720 --> 21:56.160] out. We have lots of public streams and I'm just been really excited to see everyone here [21:56.160 --> 22:09.320] at Pustum and thank you for having me.