 Thank you to all the 1000 fans here in our live audience and tens of thousands of you joining online. We're happy to be here today. Yeah, so we'll be talking about from storming to performing growing your projects contributor experience. I'm Matt Butcher. I lead a team at Microsoft called Deus Labs. We do a lot of open source development have done a lot of community work. We built Helm and Brigade and CNAB and Porter and the whole litany of other projects. Most recently we've been working on crusted in some web assembly based projects. And I was one of the original authors of the illustrated Children's Guide to Cooper. I still don't even know how to say the illustrated Children's Guide to Kubernetes. And this is my co author. Hi, I'm Karen. I am a community program manager at Microsoft. Externally I do a lot of work in the CMCF space. I'm a member of the Kubernetes kind of condo committee, and I'm also a bootstrap member of the CMCF tag focused on contributor strategy. And then at Microsoft, I am a community manager for vaccine. Like you mentioned, we worked on the illustrated Children's Guide to Kubernetes box series together, and you can find me on Twitter at caring h2. So where we're going to start today isn't necessarily with how you get started writing your open source project. We really wanted to start more with once you have a project, and you start turning your attention toward community building. And how you start to get those first contributors and how you kind of work your way through this process we've done it ourselves many times more importantly we've learned from a lot of other people around us how to do things well, and and how to get people highly involved. But where we wanted to start today and the kind of framing for our presentation was with a psychologist who in 1965 Bruce Tuckman surveyed the cycle psychological literature on how groups form and then how they become productive. And Tuckman analyzes all of this literature and at the end sort of believes that he sees a pattern that is common to almost all kinds of groups that form. And he says there are there are four very distinctive phases. It's forming, followed by storming, followed by norming and concluding with performing. Now if you've read any literature like getting a company started up or how to do group therapy or things like this you are likely to at least run into this theory somewhere along the line. But we thought it might be fun to just kind of see how it applied to open source projects so that's what we'd like to talk about today. And we'll go through each of these so in the forming phase. This is the first one. This is when you know you introduce something out there and people are excited about it. And you're all kind of together going oh this is great now how do we get started we've got so much energy and we just want to get going. So in the first one I'm going to have to look up there because I can't see contributing code in this first phase is one of the first things you're going to want to figure out. And I mean maybe that sounds obvious but it is actually really crucial step when you open up that community for the first time to come up with a way to sort of welcome people in. So it can be hard sometimes when the first couple of issues or first couple of pull requests come in and they don't feel right to you. You're like oh they didn't get it or oh I can't believe this is the kind of thing that people are and you can sort of naturally take offense. But during this phase the thing you want to do to foster this kind of forming phase is to get yourself all psyched up to create a welcoming and open atmosphere for those kinds of things. Because those represent people who are using your software and then and then you want to help you get better. We had some roles when we were doing Helm where we acknowledged we agreed the Helm Corps maintainers agreed in those early days that each time a new pull request would come in. Even if the pull request was in pretty rough shape we would try and lead off with a good positive comment because we felt like that helped us as contributors say look we recognize that our main job as a core committer is to get people. People involved and it helped validate for them. Yes we recognize that you just put in a lot of time on this. Next is having a website. So it's important to settle on your branding and your messaging early on and this is for you know your team and also like to project outwards right because it's like if you can't figure the stuff out why would someone else understand what your project is about. And so from our experiences we have found that using Netlify or GitHub Pages is a quick and easy way to get started and then ask for communications. Think about where your team is and where your larger community already exists and kind of jump on in there that way the barrier to entry is smaller. And then yeah set up dedicated channels to hold conversations. Again this is something you want to figure out early on and be intentional with because once you kind of set up these channels you're a bit committed. We've had a or I've worked on a project before where we're like we're like oh like we'll do our own slack slack org right and then later on we're like no it makes more sense for us to move this into the CNC of slack. And with that we definitely lost some people having to migrate our community over so again think about this early on before you actually need to address them. Yeah and another one that might I get the obvious points you get the hard ones and I get the easy ones. Maintaining documentation is another good thing to do for your community and maybe that sounds self-evident and I hope it does actually but again you know in those early days of getting the project going. It's a good time to frequently revisit at least a couple pieces of documentation the quick start guide. Carolyn von sleep now I can't pronounce her name von slick on our team is great about reminding us. Hey the quick start guides the first thing anybody's going to look at revisit it with each release make sure it's still in good shape. And and that's just a great thing because when people can come through and get from a zero to dopamine hit really quickly they're likely to stay around. The other good one is maintainer guide to keep the maintainer guide up to date because the first time anybody tries to do their first pull request that's the first thing they're going to look at. So again it's all about removing barriers of entry in this forming phase. The the the less fun topic is the storming phase. So every group starts out you know enthusiastic and you're starting in that building phase but inevitably at some point you're going to run into differences of opinion confusion about what should be done in the storming phase. And the storming phase describes that phase where for the first time interpersonal conflicts sort of enters the arena and this can be kind of a make or break phase for any group and an open source community is no exception. So we wanted to talk about some different things that you could do to you know streamline that process and hopefully build in some mechanisms. So I think this goes without saying but you know I want to be explicit disputes are unavoidable. You know you want to set the right expectations for your team by acknowledging that like you will very well have disputes at some point. And they're okay to have the worst thing you can do is ignore them and be caught off guard so just know that they're going to happen and that's fine. The next is the code of conduct. I serve on a code upon the committee and I highly recommend that you have one for your project. Again this is one of those things you want to have this before you really like need to have it before there are any incidents and this not only protects you it protects your project and it protects your community. And I know for some people they think that this is you know that there's a lot of work that goes into this stuff but you don't have to create this from scratch. There are lots of examples out there like the CNCF code of conduct that you can adopt for your projects. And then next is governance. So a governance stock basically provides rules of engagement around things like decision making and voting for a project and you know sometimes users will decide whether or not they want to participate or use your project based on that. So this is something you want to think about this especially if there's things around like if it's like one company controlling a project right and so this is something again you want to think about before there's a problem. And this yeah take some time think about this early on and involve all the stakeholders that might be involved. I think that in both of those cases the code of conduct and governance those are the areas where some really big issues can come in and really do substantial damage to a project at any point. That's why you want to make sure to have those two but then then again I get the easy one right coding standards are another way to kind of stop like the mundane issues right where a PR opens and you feel like you're almost like bickering about where the PRN goes or how you do semicolons or where the white spaces are and you as a as a core maintainer and as a project creator can very simply create some guides that say hey use this formatter over your code. Hey we tend to follow these particular idioms as best even if you can point to an established set like the go programming language has a really good established set of programming idioms that you can point to. And what you're doing isn't so much being an enforcer trying to kind of heavy handedly lay down that what you're trying to do is remove a ground that could otherwise lead to sort of nitpicky little little problems that could then you know how things occasionally snowball and issues or common threads and before long everything's blown out of proportion. If you can just remove a whole layer of those problems then the core maintainers are really focusing more on the substance of what's being asked and the pull request and conversely your contributors are going okay I feel like I know coming into it what's expected of me. Yeah maybe I would have put my friends somewhere else but I understand that that's what they wanted you to keep their code clean and it just removes that whole area so I think that's a nice easy way to establish something that can solve problems. Now the last one is really something we have to remind ourselves of sometimes especially when we start projects that there's a distinct difference between a contributor and an employee right and sometimes it as you get you know in that in that kind of heavy early days of a project you get really excited and people come in and start committing and start changing the code and you get and then you start thinking of those people as employees right using that model where you're like oh I need you to do this I need you to do can you get this done by Tuesday you know and it's easy to get a little heavy handed on that side. Which becomes unfair to these people and and it is a not the way we should be looking at them right respecting volunteers as people who have very graciously given of their time and talent. Is of course what we all aspire to be but we as maintainers often have to take a look at ourselves as we head out of that forming and into the storming period and go OK. I need to remember to thank people for this and not put pressure on them ask when they feel like they might have it done rather than tell them what I need it done and things like that. So now we move on into the into the third phase so it's forming storming and then norming and in the norming phase this is when the group dynamic really changes more to saying OK alright now we know how to work together. We're now we know how to solve problems how do we work together to sort of head toward the optimal right how do we how do we kind of codify how things are done in this project with the purpose of making it easy for us to continue on. One thing that we can do for that is revisit how we do issue management right in that first time when we're talking about forming we're talking about trying to get people to submit issues and make them feel comfortable. Well you know if your projects doing well all of a sudden you don't you don't necessarily feel the need to get people to start filing issues you really start going. This is a lot of issues I'm not really sure how I can keep up with it so at this point then you start figuring out strategies for triaging. We use labels a lot for some of our projects and and try and categorize things early triage on a regular cycle and prevent things from building up and again the purpose of this. Is not so much is not so much and really the purpose of many of these things in the norming phase isn't so much individualist individualist it's not about me. It's about how the core maintainers who are becoming a group can start to sort through amount of big amounts of information very efficiently in a way they all agree upon so labeling issues is a super super convenient way for somebody to be able to go through and triage things really quickly. And then when somebody else has time they can come back through and say OK I'm going to look for a bug oh these three are labeled bug that one's labeled small I'm going to grab a small bug and work on that today and that helps everybody streamline things without everybody having to do sort of the redundant work of reading every issue in the queue. Delegating work. Delegating work as the project grows is going to become increasingly important to figure out how you're going to parcel stuff out among the maintainers of the project. So Helm is a good example of that and Adam is sitting in the front row so I can pick on him you know as we got going in here it started to be a bigger and bigger deal for Adam and I and Michelle to go around to other people and say hey we noticed you've been contributing in the issue queue a lot. You've opened a bunch of pull requests. How do you feel about becoming a core maintainer and you start building out in this norming phase a process by which you can identify people around you who are going to be productive for the project healthy for the community. And then you know kind of delegate out that that work to them and then make it clear how they can claim work and make it clear how what the expectations are working together and that's when you really start to see the project as a whole strength. You don't have to tackle that right up front in the forming phase but by about this phase that's when these problems become real and they can be solved with this kind of introspective look at how you want to grow the team. So you also want to standardize communication channels and this is for everyone's sake. Figure out what needs to be private with maintainers versus transparent with the community. Again this goes back to building trust and use your dedicated communication channels as intended and this is for consistency and trust. And then when you outgrow your channels and such as what slack consider splitting it for the sake of organization again using home as an example we suggest have a home channel. But then you know it got a bit noisy we started having developers in there and users and so we ended up splitting the channel into a home dev and help users channel again just for organization and clarity. So that and if and when you need to do that do it as soon as possible and then also just for you know when it comes to communications you want to document for the future right like you're not always going to have the exact same people working on your project so you want to kind of leave a paper trail for the people who come into the project later down the line so they can get caught up and just again transparency trust all that good stuff. So we start with forming and we go on and we deal with interpersonal conflict and storming then we get to this place where really starting to solve process problems and that's the norming phase and then the final phase that Tuckman identified was called performing. And the idea here is that the group is sort of settled into their thing right and we understand how we work together we've hit stride on a lot of things we know what are in the case of an open source project like this right what the day to day cadence looks like for things. So how we version how we do this how we do that the last phase the performing phase is really about making sure that we can perpetuate everything we've just built and and continue it on and keep everything kind of healthy over the long term. So, the first one on this list then becomes what do we need to do to keep the people that we have on the project right. All at this point I think painfully aware of the impact of burnout. And one of the things about maintaining an open source project which I'm sure will come as no surprise to any of you is that it can be really stressful to manage things like issue queues right. Nobody comes, I shouldn't say nobody very rarely does anybody come to the issue queue just to say hey I'm not frustrated with this project and it's really working well for me right. And when they show up in the issue queue they're there because they've already hit something that is driving driving them to to complain right or to point out a flaw or to ask for help. And you can oftentimes get people who show up and lay their frustration right out there in in print. And it can be very tiring and burnout among open source developers can be really tough one because when you're volunteering on a project and people get kind of hostile. And you take it personally all of which are natural things right the natural tendency to react to that as well. This was my free time why am I spending my free time on this I could spend my free time on something else. So it became a very important thing to for us to figure out ways of expressing appreciation to core maintainers help them feel appreciated and help them feel valued and Karen had often done really cool things like create some sort of special special swag to give specifically to core maintainers you know here's a t shirt. Here's we gave out we've done a word. We did puzzles. We did puzzles one time but just stuff to say look we recognize that you're in it to volunteer. You know here's a basket of chocolate bars to express our appreciation things like that can just go a long way just to let people know that they're feeling appreciated. And then again just kind of acknowledging that like people will eventually move on you want to actively always be thinking about the future right so treat your current maintainers well because that will encourage new people to step up as contributors and then also ideally become maintainers down the line and just be honest with yourself about this. Yeah just always be thinking about how you can bring in new contributors before you need to I guess that's kind of my current theme right now for this whole talk think about things before you need to. So yeah, as an example we did our home contributor summit earlier this year and with that we did workshops for people who are new to the project to get them caught up to speed on how to contribute to the project. And then we also use that as an opportunity to identify current maintainers that we felt like had potential to become maintainers reached out to them and then we're like currently working with them and mentoring them to become maintainers and this isn't to say that we currently like you know are dying for maintainers but again it's just like we're getting people in the pipeline set up for success. Yeah yeah and being able to keep that momentum once you've gone through all these other phases to kind of build it. It's it felt much easier to have a core maintainer summit and say this is what we've already discovered about it you know come on join us it's going to be fun. But sometimes it is time for people to go right and it's not always because of burnout oftentimes is because a job change impact you or other personal situation. And one of the things that can be hard is for somebody to step down. And sometimes people don't want to step down because they feel an obligation to continue with the project other times they're embarrassed and they just kind of you know ghost out and you're like what happened to so and so. When we were dealing with this with helm. Something from academia really inspired us when you are a faculty member at a and at an institution at a university or something for a long time and you retire. You don't lose your title of professor you become an emeritus professor. And this is a title of respect to kind of wait for the department to thank you for your contribution over the years to your particular specialty to your particular field and we really liked that idea of. Having a title that was a title of respect but didn't necessarily carry with it more responsibilities with the project. And so we introduced a helm emeritus maintainer status that when somebody said you know it's my time job change life change. Tired you know interest change whatever I kind of need to step back then we would give them this title emeritus maintainer and they would go in the code owners file and the emeritus maintainer. And that meant that from then on out they knew that when they put on a resume yeah I worked on helmet yeah I worked on brigade or something like that. They would be able to point back to the file in the repo and say see I'm still listed here right and other people would be able to go oh yeah I know that person they I didn't know they worked on this project and there's this like sense of respect and. And honor in being able to recognize the work that people did so we we coined that title that's something that I really hope other projects do as well because I just think it's a really. Cool way to thank people for for concerted effort and and again volunteering their time and their talent. Right so now we're at the conclusion and you know basically you want to say that in reality open source projects aren't static right like we presented this model to you but at the same time not all the projects that you work with will go through these phases or at the same pace. And so sometimes we move back and forth through this model and all of that is okay. We just hope that we've been able to provide you with some tools techniques and contacts to help you figure out these phases for yourself. Yeah and when when Tuckman was writing that article you know he was thinking very much of a group is sort of a static body that went through a static period of time open source projects tend to go. Longer and have more variety than I think what those early studies he looked at would have indicated. And because of that right the changes can happen anytime you shake up who's the core maintainer or even when you do a major software release and major API is changed and people who are really comfortable with the old stuff are maybe not as comfortable with the new stuff. Those are the times you might slip back into like a storming phase or slip back into a norming phase where you have to revisit how you're going to do things to be productive. And that's OK and as we wrote the presentation we tried to make it so that those same steps you could go back and revisit during the sort of retrograde motions back through those particular periods and say OK OK these are a couple of strategies we can use and try. Many years after he wrote his first paper you know forming storming norming and conforming he realized that he might have missed something. And so later on he came back and offered a final step a fifth step that he called adjoining. And this is a step that we've all seen happen with open source projects as maintainership kind of quiets down the project is no longer quite as relevant. And it's time to just say hey we did a good job. We worked really hard on this and we're kind of done. We didn't have any particular big insights we wanted to add to that but we did want to point out that that too is a natural phase of many open source projects and also the natural phase of a conference talk. So if you have any if you have any questions otherwise we too will adjourn. Let's let's pass this around. Hi. I really liked what you said about the emeritus maintainers. Do you have any suggestions for recognizing and elevating particularly non code contributors but people who are active and supportive of the project in a way that makes them irreplaceable or very notably helpful. That's a good question. Do you want to. I mean I have been one on many projects. I mean like I do a lot of the community non code work for our projects and I've been recognized as such as being like a maintainer or like I'm like maintainer maintainer of several of our community. Yeah, yeah. So that's kind of like the public way that I've been recognized and like have that in writing I guess. Are you talking more about like someone who's currently doing stuff or maybe down the line. I guess you could still do the meridus thing down the line as well too. So we're going to get to the community part so with a lot of our projects will take the GitHub org for the project. And so slash helm and then there's slash helm is the code repository charts is the other and community is one of them and we will often put people who do a lot of design work Karen who does a lot of community work Bridget who does a lot of community work and documentation where people people like that will go in their docs repositories will often separate out from the code repositories we used to keep the two together for the simple reason that then you could pull request one pull request to the feature change in a doc change. But over time we realized that there were a lot of specialist activities that you could do in a docs repository and so we started breaking those out. And then we started assigning maintainers who are doc maintainers who could who would really focus on everything from and correct and feel free to jump up and correct me if I'm wrong but like the consistency of the documentation when we got into translation managing translations. Making sure the quick start guide and the reference material is all up to date. So then we would make maintainers of a community repo that focused on some of that maintainers of the docs repo that focused on that so we didn't necessarily give them titles different than core maintainer. We just split up our repos now I imagine you could definitely just say we're going to have a category called docs maintainer or docs and code code maintainer or something like that but that wasn't anything we've tried out. Oh I forgot about that. Oh yeah that's really good. So in helm we introduced triage maintainers recently because what we were discovering was the issue queue was getting out of control and we were getting burned out just triaging the issue queue. And a lot of times those were questions where somebody could answer in two sentences or point them to the documentation so we introduced a new category of maintainer called triage maintainer that they don't. I mean they're certainly welcome to open PRs and stuff but they're not obligated to review PRs and things like that but they're empowered to be able to go through and label issues and close issues and stuff like that. And that for a project the size of helm has been a tremendous boom to us. It's been very very helpful. I was going to say I don't know that you're like going to hit any resistance for this as well but one of the arguments that I would like to make for you know getting people who are doing non code contributions listed as maintainers is like. For like a lot of our projects because they're CNCF projects there's a lot of communications that have to communication that happens between CNCF and the project and as someone who does the community work like if I'm not listed as a maintainer I don't get those. So like functionally there's a reason to add someone who does non code work as well. Yeah. Okay one more question. You've worked the two of you have worked on large projects that are graduated CNCF projects like helm, but you've recently been starting some small new projects. Can you talk a little bit about people who might see all of the work that goes into a giant project like helm and say, wait what if I'm just starting you give a few tips for people who are starting a project like say crosslet. Do you want to start or do you want me to start. Yeah. Okay. I mean, again, some of those first ones in the forming phase to expand a little about some of those that we think are really important. So the metaphor we'd like to use is has to do with circles. Right. In the very first days of a project before we get into it, the topics of this kind of thing you imagine you got your close circle of people who are working together on the code, and you're all kind of huddled together, looking inward and saying, okay, how are you going to design this? How are you going to code that? Then you get to kind of this first phase where you're ready to start community building. And the metaphor we always use is, okay, so you got this group of people and they all stand up and they all kind of turn away. So they're facing outward and the metaphor is designed to say, you know, everybody's got each other's back because that first phase can be kind of rough. Right. You're going to get challenged a lot on your assumptions everybody's got each other's back but at the same time you're facing outward and starting to bring people in. And so you have to make some very intentional moves at that point to say, hey, this is what we're doing. You know, sometimes we might be a little overly enthusiastic on Twitter about what we're working on and how excited we are about it. But the idea is to start bringing people in. And hopefully some percentage of those people will like the project and want to stick around and use it. And then some percentage of those people who stick around and use it will want to start working with you on it. And so a lot of that, like after the 1.0 phase so much of the effort is really that outward communication thing. But the goal of that, among the other goals, one of the main goals of that in this circle metaphor is that you start building up a concentric circle around you of other people who are interested. And then at some point you start to sort of reform. And some people start working on 1.1 or 2.0 right and so they sort of turn back in and start working again. Well, the outer concentric ring is still facing outward and bringing in more people and trying to eventually and that's when you're really getting more into the into the norming phase right that third phase where it's all about introducing some process and you are working for these kind of concentric rings. So to answer Bridget's question most directly then that that turn out that initial turn outward when you really start focusing time that would otherwise be engineering time on making people feel welcome on, you know, thinking about those PRs and leaving some some positive comments as well as negative comments on thanking people for filing issues. When admittedly sometimes you're like, right, but it's all about respecting people where they're at and trying to build up that next Yeah, I mean, I know like, like we've worked on bigger projects but I just want to say a lot of what we say applies to all projects, because we, yeah, we would have had to start at the beginning for even our small projects even though we've been doing this for a while. And then again, just like I said, think about things before there are problems. Yeah, oh, that is that is so true. Yeah, the code of conduct should go in your repo in the governance license on day one right that you just will spare yourself a lot of problems with that. Because again, your goal in this community building phase is to make the right space for the discussion to be about what you're trying to build and how you're going to do it, not and not having jerky people come in and ruin the exact thing you're trying to do right It's setting the right tone at the beginning. Yeah, yeah. And I really feel very strongly that what sets open source software apart from any other, you know, commercial proprietary doesn't really matter is the fact that when you start to build these communities, we build much better things when we're working together. Collectively, we're smarter about these things and not handling code of conduct issues will just destroy that right away. So, So we have time for one more question one more question like four minutes. Yeah, I'll pick right in the back here. It's like the game show thing where they run out the aisle and hand over the mic to somebody else. I hope this is relevant. I'm wondering if you could speak a little bit about how to make your community inclusive, given that, you know, many people are dedicating their free time. You might have a handful of people who are paid to work on the project. How do you make sure that you're giving those people who just have a few minutes to spare all the opportunity to participate? I have lots. Go for it. Early on in, in helm, I was in a talk with another open source project, and it surfaced that the number one point of contention in the group was time zones because they had some people in Australia, some people in Europe, some people in North America and they were always trying to figure out a time zone that worked. And that was a really good indicator early on that there were all kinds of things, all kinds of things to consider when you're talking about improving the diversity and inclusivity of your project. I definitely am not an expert on this. It has been, I've struggled many times myself to figure out how to build those things in, but I think the first step would be to start to acknowledge all the different things. And you raised a great one. Like some people, like me, like Karen and I are paid to work on this stuff full time. It's very easy for us to show up between nine and five and do our stuff and then check out at five. Whereas a whole batch of people are showing up at five going while I got, or 5.30 going, I got 20 minutes of time before dinner. I wonder what I can do. The triage maintainer role was I think one of the most interesting ones that we did. And part of the reasoning behind the triaging role was that we had a lot of people in China and in Asia who wanted to be able to contribute to Helm, but their work cycle was off the clock of almost all the other Helm maintainers. And so it was a way to start to do things asynchronously so that they could jump in at the triage role and start working on that. And then work their way toward a core maintainership without having to necessarily show up and meet everybody during, you know, what would effectively be the middle of the night. A lot of what Karen has done and a lot of what Bridget has done and and Karina who is not in the room but is also one of the PMs on Helm have all worked very hard when we did this contributor summit to figure out ways that we could start identifying people early based on their interest. And helping them kind of get plugged in so that we could streamline the process of getting them in because otherwise what we noticed happened was that the loudest ones were the ones who got considered for something right. It was the ones who were there the most and who were commenting on the most number of issues which while a good indicator of their interest and expertise is not the only indicator of interest and expertise. So we're getting better. I don't know there are other things we've done that. We're at time here so there's one question from online but we'll probably wrap that up after this session so to Jim who's online thank you for that question and I'll make sure that Karen and Matt see to it. Thank you. Thank you very much.