Managing Community Contributors With Alya Abbott  ## Metadata - Author: [[The Business of Open Source]] - Full Title: Managing Community Contributors With Alya Abbott - Category: #podcasts - URL: https://share.snipd.com/episode/a2228b57-9332-408a-9fc8-744be483b076 ## Document Notes ## Highlights - **Zulip's Contributor Scale & UX** - Zulip had code commits from 121 people in a release cycle with a paid team of 16, showing strong community involvement. - They approach the contribution process as a product, even doing user experience testing for developer onboarding. Transcript: Alya Abbott Yeah, great question. And I think I'm going to have a long and multi-stage answer and we can dive into different aspects of it. Just for a little bit of context, so for example, on our last major release, which we do a couple of releases a year, we had code commits from 121 different people in that release cycle With a paid team of 16 people. So that just gives you kind of a scope. Looking at the numbers of commits, which are obviously a flawed metric, a quarter of the commits in that release were community contributions. So that gives you a little bit of a sense of where we are at. I would say the first piece is just when you're even just getting started, being intentional about what you're trying to do with your community. There's lots of different reasons why people make their software open source. So the first question is even was whether having that community and having community contributions is even a priority for you or priority for you at your current stage, right? Maybe you're very early on still figuring out even just the architecture, what technologies you're using. Maybe it's just too early for you to be taking external contributions and it's going to be a distraction. And that's totally fine and you can decide that. And that kind of defines what you're trying to accomplish at that phase. But then if you do think it's important for you to get community involvement, get community contributions, then that's something that's not going to happen on its own. And it's something you need to be actively thinking about. We really think of that contribution process as a product in its own right that we're building alongside building our application. And so if you start thinking about it as a product, then you can also apply some of the thinking that you do when you're taking a product to market. So for example, there's kind of a sequencing of how people come to discover your project and to start participating in your contribution process. And you really need to focus on kind of those early stages of that funnel before you even need to think deeply and really, and optimize the later stages of the funnel. So like, for instance, what I mean by early stages, okay, imagine, put yourself in the shoes of a potential contributor to your project. So somehow they learned about you, they're interested in contributing. What is their entry point, right? When they come to GitHub, is there a readme that explains what they need to do? Or maybe you have a separate documentation site does that site have an overview of what it takes to get started what is that what are those first steps that they're going to take um another Thing that you're probably going to need to think about really early on is what is the process of just setting up to your development environment so is that some if it's something where You have you know you and your buddy are working on a project and you guys are the only ones who need that dev environment set up, it doesn't really matter if it's a pain in the neck. You've done it once, you've done it twice, that's it. Nobody ever needs to think about it again. But if you're having new people coming in, that's going to be a really big piece of their experience. And if they get stuck, it doesn't work on their machine, they can't figure it out. A lot of those folks who are potentially interested in contributing are just going to bounce at that very early stage. Maybe they'll come ask you something in your community chat or something like that, but maybe they won't. Maybe they'll just try it, see that it doesn't work, and they're done. So, for example, early on in Zulip's history as an open source project, we actually did a lot of user testing on that dev environment setup experience. So we would go to, I wasn't personally involved at the time, but folks would go to like conferences, meetups, places where you can actually sit next to somebody in person and watch them Trying to get started running the development environment on their machine and see, oh, this is where they're getting lost. This is where they're getting confused. This part of the script is not working on a Mac, whatever it is. And then, you know, then you can work on fixing that with some combination of improving the tooling and documenting the process. So maybe at the start, you do a bunch of documenting of here's this part is awkward. Here's how you work around it. And then later on, you improve the tooling. And in Zulip's case, we even we hired a technical writer early on as well to actually work with us on that documentation for how to get your dev environment set up and also how to make small Changes, like a tutorial, like a new feature tutorial. So, yeah, it's a very intentional approach, I would say. Emily O'Meara So let me take a step back even from this question. This is a lot of work. Why is it worth it? Like, why even put all of this effort into this process to thinking about your contribution experience as a product and putting so much effort into making this happen, basically? Alya Abbott Great question. ([Time 0:03:54](https://share.snipd.com/snip/da9f7af4-538a-478a-96ae-7483cf0dfa8e)) - **Optimize Early Dev Setup Experience** - Make the first steps of contribution clear, including documentation on setting up the development environment. - Fix and improve developer setup tools iteratively to reduce early drop-off of potential contributors. Transcript: Alya Abbott And you really need to focus on kind of those early stages of that funnel before you even need to think deeply and really, and optimize the later stages of the funnel. So like, for instance, what I mean by early stages, okay, imagine, put yourself in the shoes of a potential contributor to your project. So somehow they learned about you, they're interested in contributing. What is their entry point, right? When they come to GitHub, is there a readme that explains what they need to do? Or maybe you have a separate documentation site does that site have an overview of what it takes to get started what is that what are those first steps that they're going to take um another Thing that you're probably going to need to think about really early on is what is the process of just setting up to your development environment so is that some if it's something where You have you know you and your buddy are working on a project and you guys are the only ones who need that dev environment set up, it doesn't really matter if it's a pain in the neck. You've done it once, you've done it twice, that's it. Nobody ever needs to think about it again. But if you're having new people coming in, that's going to be a really big piece of their experience. And if they get stuck, it doesn't work on their machine, they can't figure it out. A lot of those folks who are potentially interested in contributing are just going to bounce at that very early stage. Maybe they'll come ask you something in your community chat or something like that, but maybe they won't. Maybe they'll just try it, see that it doesn't work, and they're done. So, for example, early on in Zulip's history as an open source project, we actually did a lot of user testing on that dev environment setup experience. So we would go to, I wasn't personally involved at the time, but folks would go to like ([Time 0:06:08](https://share.snipd.com/snip/ca129935-3737-4bb9-a17a-f24e5283226c)) - **Open Source Empowers & Scales Dev** - Open source allows users to become changemakers of their tools, empowering them. - Community contributions enable scaling development and faster feature coverage like integrations. Transcript: Emily O'Meara Happen, basically? Alya Abbott Great question. Yeah. So I would say, I'm not going to say that it's worth it for everybody. As I said up front, maybe for your project or your project at its current stage, it's not. I think there's a few things. So one piece of it is, I think the reason many of us are really passionate about open source is that it gives people control over the tools that they're using. It really lets a user of the software become somebody who can change things about their software, right? Like that power. And so if your software is open source, but in practice, that experience of trying to make any changes to it is really, really difficult. In some ways, it might not be living up to that full ideal of people can hack on their tools. If you're a developer, you can make it work how you want it to, change things, play with it. So I think that's one piece. A piece that's important for us is we're working on a product that has a really large surface area. It's a team chat app. There's tons and tons of functionality that go into that. It's an app that needs to serve all kinds of different users, different use cases. And so while we still have core team members building the most difficult features, the most kind of sensitive features, there's also just a lot to cover. And so having the community really lets us scale and build our app faster, that is definitely a very practical consideration where, for example, Zulub has ([Time 0:09:29](https://share.snipd.com/snip/5248cb7d-67f2-4053-b56a-a44ea6df9dd2)) - **Students Drive Zulip Contributions** - Majority of Zulip contributors are students or recent graduates learning to be developers. - They spend many hours over months contributing, gaining expertise and maintaining subsystems. Transcript: Alya Abbott Different that different apps can have. So we talked a little bit about the idea of users of software being able to like hack on it and make contributions for us. For us, actually, the great majority of contributions, maybe upwards of 90 or 95 percent, come from folks who are more um learning to be developers so like students recent graduates So they're coming to us not so much as uh users of the product who are trying to make some change there we get some contributions like that as well um but as um you know people who are trying To learn how to build good software, and we are able to provide a really great educational experience for them. And so that, but in part what that means is that these are folks who have a lot of time, usually, this is like the main thing they're trying to do is become a great engineer so if zulip is a Really contributing to zulip is a really effective way to do that they can spend lots of time doing that um many of our contributors for example are based in india which has a kind of a british Style school system with exams so you know there'll be a couple weeks where people are really um occupied with that but then the rest of the semester is pretty chill. It's not really like you get intense problem sets or things like that. So people are really spending many, many hours a day working at Zillip over the course of months. And so what that means is that we're really able to train folks to teach them how to be really effective contributors to our project. And they become experts and maintainers for subsystems of the project. Emily O'Meara So this is a really interesting point, ([Time 0:11:47](https://share.snipd.com/snip/a8c4d259-1539-4d82-9bde-ae5be7622603)) - **Write Accessible Issues for Newbies** - Write detailed, specific issue descriptions for new contributors, reducing the need for extensive context. - Structure contributions so newcomers can tackle isolated parts without full system knowledge. Transcript: Alya Abbott So we really try to write up when I do a lot of our issue write-ups. And I'm always thinking about, okay, like what kind of person will be picking this up? So if I'm writing something for a core team member, it still needs to be specific enough, but there's a lot more places where I might kind of like wave my hands and be like, make this look, You know, I'm not going to say like, make this button look this particular way because I know that they know how buttons in this part of the UI work and they will just do that. Whereas if I'm writing something I'm expecting, it's a really simple issue and I'm expecting maybe somebody brand new to the project will be picking it up. I'll actually be like a lot more specific about the specification so that you don't need to have a lot of context about what's normal, what do things look like in this app to be able to get That issue done. Emily O'Meara So you mentioned that you also handle product. And I wanted to talk about ([Time 0:14:39](https://share.snipd.com/snip/b2081e1d-c96e-442f-b482-6f83fbc31c70)) - **Set Clear Contribution Boundaries** - Require new features to be based on clearly specified issues before accepting contributions. - Set contributor expectations upfront to avoid disappointment and unruly project direction. Transcript: Alya Abbott Yeah, so a few things. So one is we do say quite clearly in all our contributed documentation that we expect folks to work on either issues that are specified in our tracker and Mark just help want it on that Issue. We give it a label. There's some things that we don't necessarily write everything up as a full issue. Maybe there's a bug that's being discussed in the development community and people can pick it up kind of just from that discussion thread. That's fine. But if it's a new feature, that really is only something that we will take contributions only if it implements something that we specifically spec'd out. And even sometimes we'll have issues tracking features that we're potentially interested in, but we just haven't actually prioritized getting a concrete product spec'd together. And that is also something we don't view as available for contributors to work on. But I think to avoid that disappointment, we just try to communicate really clearly upfront about what our expectations are. Yeah. ([Time 0:16:31](https://share.snipd.com/snip/4c7f33bf-b715-4ed1-98fd-966a77d100c8)) - **Invest Heavily in Communication** - Maintain extensive contributor documentation including PR structure, commit standards, and communication style. - Coach contributors in effective communication to improve review efficiency and collaboration. Transcript: Alya Abbott A ton. So, I mean, so I guess I've been on and off mentioning documentation, and we have a lot of contributor documentation. So that's a type of communication that is touches on all the different aspects of the contribution process. There's an overall, here's how you get started doc. But then that links out to all sorts of more specific things like, how do you put together a pull request that we'll be happy to review? What commit structure do we expect? What commit messages do we expect? How do you test your own work? How do you test somebody else's work? We actually have a lot of peer reviews among contributors, especially once they start doing. We have a lot of folks who participate in the Google Summer of Code mentorship program. So folks doing that will also review each other's work. We have a page about our communication style and how we expect people to communicate in our development community. So yes, it's huge. And it's not just how we, us communicating to, as maintainers can communicate to contributors. We're also actually do a ([Time 0:17:41](https://share.snipd.com/snip/03b1f967-cd9a-4e72-914b-97641b0b734a)) - **Open Source Builds Trust & Collaboration** - Zulip's open source nature fosters collaboration, transparency, and trust through community code contributions and translations. - Open source allows users to self-host and inspect code, promoting data control and digital sovereignty. Transcript: Alya Abbott Why does it matter to Zulip to be an open source company? Oh, I think I would say there's not a single answer to that question. I expect that if you talk to different folks working on Zulip, each would have their own personal take on what matters to them. I think some pieces that many of us really value and that I personally really value, one is what we've been talking about in terms of the process of building the product, where it's this Very collaborative open process. It's collaboration with our folks who are contributing code. But for example, our translations of Zulip, it's translated into 20 something languages. All those translations are community contributed. And in our development community, we have users coming by, giving feedback, participating in the, talking about the design of different features. And that's, it's just really open and collaborative. And I think some pieces of that you could do as a proprietary app, like you can have a user community, but I think as people still engage with it in different ways, and certainly the code Contributions couldn't happen in the same way in a proprietary product and that's really just like a very rewarding way and to build a product. And that mission of helping educate folks and helping them become better developers as part of the process, I think is really something that I value and a lot of folks working in Zillip Value. So that's one piece. I think there's also a major piece for the users of the product. So Team Chat is something that's a really critical piece of, like it's software that you really have to trust. People put really sensitive information about their company by themselves um they trust the product to do the right thing with that information and when it's proprietary you really Just kind of have to take it on faith what happens once you once when you do that with our software so for one you can self-host it so then that data just remains under your control that kind Of goes together with that open source nature um so i think that's really powerful and i know like folks these days are thinking a lot about things like digital sovereignty and when you Could just self-host the software you have really full control so i think that's really something really important that we can provide for our users. But even for folks who are using the cloud service, because that's maybe simpler, more convenient for them, there's still that ability to inspect and understand the software you're Writing that open source provides. So I would say those are a couple of the pieces and definitely can talk more and ([Time 0:19:20](https://share.snipd.com/snip/d5ca7676-bab6-4eb8-885a-49129ecc6df7)) - **Balancing Community and Core Focus** - Community contributions help Zulip expand broadly but make focus on core hard problems tougher. - They use a multi-stage review and strict PR guidelines to manage quality and filter contributors. Transcript: Emily O'Meara Absolutely. Alya Abbott Yeah. And I would, you know, I don't want to paint a like 100% glowing picture in the sense that you, it does make it, there's a few things. So one, it makes it harder to focus. So if you think that what you need for your product is like a very small set of a small set of very specific, hard things, then what the community is going to help you is that it's going to Help you go broad. And that's what and that for our product, that makes a lot of sense. And, you know, we try. We try to communicate with the community as well about priorities. So for, for, if somebody is brand new as a contributor, we're happy to have them kind of pick up anything that's easy that they can tackle. That's fine. But once somebody has been working with us, we really try, we have, for example, a public priorities board and good hub where we're tell contributors, okay, here are the issues that Are the projects we would love for the community to contribute to so and that's been definitely like an iterative process of how do we guide folks to the things that are actually priorities For the project as opposed to like something that you know they just happen to pick up because it's in the tracker and then um we have a multi-stage review process for community contributions Because like code quality and maintainability is a huge priority for our project. And so we'll have maintainers reviewing the code. We'll have integration review by the tech leads. So building out and there's sort of more to it than that. So they're building out that review process and how we manage the reviews is a really big part of how we try to not get too kind of distracted from what our core team needs to be working on. So for example, we have very specific guidelines on how a pull request should be presented to make it easy to review in terms of commit structure, in terms of what's in the description And so on. And we basically will not start the technical review until their pull request meets those guidelines. And that's both saving time for a team in terms of once they're actually looking at the PR, it's nice, it's pleasant to try to figure out what's happening. But it ([Time 0:22:43](https://share.snipd.com/snip/f2850213-758e-4467-bf5d-60027ee64a16)) - **Nurture Repeat Contributors** - Provide fast, iterative feedback to keep contributors engaged and motivated. - Show appreciation even when contributions fail, and assign more responsibility to foster ownership. Transcript: Emily O'Meara From the same person. So how do you try to cultivate these contributors? Alya Abbott For sure i think there's a lot sort of different pieces to it so one is we do try to be really prompt with our feedback um i think it's really it's a very different experience if you submit A pr and the same day or maybe the next day you hear back you at least some initial set of comments and that's where those kind of partial reviews come in where we're not trying to figure Out everything about this pull request we're just providing enough feedback to get you to the next stage but we're trying to do that quickly to keep things moving to keep to do it while You're still excited and interested and before you kind of jump to something else with your limited time. I think there is just kind of the kind of attitude we have towards contributions. Like our view is that we really appreciate that folks are trying to contribute whether or not they're successful actually it's something that where they're putting themselves out There they're taking a risk they're trying something new and they're trying to help and so you know you'll never see us like even if somebody is not yet successful or maybe they're just Not mature enough as a developer to be successful, we really try to make that a positive interaction no matter what happens. So even if we're closing a pull request that we think is never going to emerge because it's just not even on the right track, which we'll definitely do, we'll still leave a comment that Says, thank you for giving this a try. And we'll, or like, if somebody redoes a piece of work, we'll say hey maybe you want to check out the new way that they did it you might learn something interesting um so i think that kind Of the positive interactions certainly help just on a human level um i mean for us a lot of folks who are contributing, they are interested in that Google Summer of Code program. So for them, and the way that we admit folks into the program is that they've all already demonstrated their ability to contribute effectively to the project. So that's kind of some motivation to keep going. I think another piece is just providing a great learning experience throughout for these folks who are doing open source contributions to learn how to be better engineers. If they feel like their review process maybe took a while, maybe it was challenging, but they learned something during that process that's that um keeps them going because then they Can submit the next pr and learn even more and um also i would say maybe giving increased responsibility these increase a kind of um making folks feel like they are you know own some area It's sort of responsibility. So maybe you've put up a couple of pull requests in some area. And now we might actually now, seeing that, ask you to work on a particular issue that is related to what you've done. And I think that feels really nice, good for folks to be like, okay, this is my thing now. And yes, I will, I will make it, I will work on this thing. And I'm being recognized as somebody who's now getting, gaining expertise in this part of the project. So there's ([Time 0:27:33](https://share.snipd.com/snip/9f99003d-4b33-4efc-8de6-c3a958980602)) - **Iterate Toward Clear Community Priorities** - Continuously improve contribution processes with clearer public priorities to avoid confusion. - Coordinate community efforts around release goals like bug squashing for cohesive progress. Transcript: Alya Abbott I guess I wouldn't, this is, I'm not sure if I would call it an interesting mistake per se, but I would say that we've just are constantly iterating on our process. And, you know, arguably it's a mistake that some of the things that we're doing now, we weren't doing maybe three years ago, or maybe some things we will be doing in two years that we don't Know about yet we're not doing now. So for example, I would say that communication about project priorities we've become a lot more mature about in the last few years where previously it was a lot more something that was Kind of lived in the heads of the core folks on the project like but was you know we had some idea of what we wanted to do but it wasn't presented in a way where it's easy for anybody else to Access or uh wasn't in a very wasn't very granular for other folks so a lot of the coordination would really have to happen on a one-to basis where maybe we ask somebody to work on something Or they ask what to work on and we make this make a suggestion and we've been really trying to move towards having a clear public set of priorities and and i'm sure we're still not perfect About how that's set up but um really trying to make it kind of more of a one-to communication where we can say, okay, like, here's overall what things that are important. Please take the initiative to pick up the things that we've said matter. For putting out our releases. We do have maybe a month or so of really trying to do a lot of bug squashing and really trying to bring the product to a really clean state. And so, again, communicating with our community so it's not just maintainers are squashing bugs and contributors are building random new features. But we're all together trying to do this, trying to squash those bugs, trying to get everything ironed out. So I think that's, I would say we, you know, maybe a mistake is it took us a while to get to the point where we're really explaining to the community as much as we can what our overall priorities Are and really trying to get everybody on the same page and involved in making this happen. I think this has been a really good ([Time 0:32:17](https://share.snipd.com/snip/fe8dd7c8-24d0-4639-93c3-8b54051b4a74)) - **Community Makes Development Fun** - Working with excited community contributors creates a fun, energetic environment. - The communal effort of building something together is a highly rewarding experience. Transcript: Alya Abbott If you haven't had this experience yet, it is just a really rewarding way to work. Like, it's really fun working with folks who are excited to contribute. The activity and the discussions and just the kind of feeling of a whole community coming together to build something, I think it's just, it's very fun, which we maybe haven't talked About as much as a benefit quite yet. But I think if you can make it work, you'll find that it's very rewarding. ([Time 0:35:00](https://share.snipd.com/snip/8d325ce2-7615-4c46-a585-6d29859ddb90))