Git it Right! Measuring What Matters in OSS Contribution

Katie (00:00:05): Hi, Maxim.

Maxim Wheatley (00:00:12): Hello there. Can you see me and hear me okay?

Katie (00:00:14): Yes. I'm using my standing desk.

Maxim Wheatley (00:00:18): Excellent. And then if I click this, just a quick final-

Katie (00:00:23): Looks great.

Maxim Wheatley (00:00:25): So now you can see and hear me and then you can see the presentation. Is that correct?

Katie (00:00:31): Indeed. Yeah.

Maxim Wheatley (00:00:33): Excellent. Excellent. Brilliant. So I think we should be good to go here.

Katie (00:00:39): Great. Did you have a moment to play with Butter before this?

Maxim Wheatley (00:00:46): A little bit. A little bit. Yeah, I feel like it's certainly super capable. I think the challenges, and I maybe should have proposed this to all of us workshop people, I think there's some features that are challenging to really go through by yourself that I think if we were doing it as like-

Katie (00:01:09): Okay.

Maxim Wheatley (00:01:10): ... cohort being a dummy audience for each other would definitely be helpful. But yeah, that being said, I feel totally comfortable to navigate this.

Katie (00:01:22): Okay, good. Well, thank you. I'm curious to know, while you're sharing your screen right now, can you see the chat?

Maxim Wheatley (00:01:30): Let me see here. So if I surface the chat, so what can you see is the question? Because I can see the chat, I can see you, and I can see my slides.

Katie (00:01:42): Nice. I see the same.

Maxim Wheatley (00:01:45): Okay. So you're seeing all of that in the same view as well?

Katie (00:01:49): Yeah. Yep. I see you're going to the next slide. Yep.

Maxim Wheatley (00:01:49): Okay. So I wonder what the most audience-friendly way for us to do this would be.

Katie (00:01:49): Oh. I love the old timey doorbells.

Maxim Wheatley (00:01:50): Yeah. Yeah.

Katie (00:01:51): Let me know when you're ready for me to let people into the workshop, but I think just encourage people to be active in the chat, if they have questions to ask it there. Yeah.

Maxim Wheatley (00:02:26): Lovely, lovely. Yeah. Feel free to let people in. I'm ready to go and we can toggle back and forth with the chat here and I should be good.

Katie (00:02:35): Yay. People are joining. Warren, I can't believe, Warren has attended every workshop today. I'm done. Yeah.

Maxim Wheatley (00:02:47): It's funny too, I spotted Warren in some of the other sessions and at first I was like, "Wow, he's just so dedicated to that thumbs up," because I didn't realize it was just the selfie from the avatar. It's very funny.

Katie (00:03:00): Oh, I love the doorbell vibe.

Maxim Wheatley (00:03:09): Yeah, no, I think that's in my view what distinguishes Butter from everything else that I've seen is it seems to make it a much more fun and interactive screen share-

Katie (00:03:20): I agree. Have you found, there's a way that you can do sound effects. Have you found that?

Maxim Wheatley (00:03:28): I did see that. I did see that, yeah.

Katie (00:03:30): I think that's so hilarious.

Maxim Wheatley (00:03:38): It is great. It is great. Yeah, no, I've talked a lot about the value of reaction emojis in communities and just in day to day collaboration, right? Where being able to develop a culture, which we have at my company, of using certain types of emojis to signal certain responses or certain statuses and things like that can go a tremendously long way and keeping everyone flowing, but without the need to be explicitly typing things out and creating all this static.

Katie (00:04:09): I totally agree with that. At Orbit, we have similar norms and one that I really like is any public channel that you put something in as an announcement, it's a norm for people to react to it with the eyeball emoji just to say that they've seen it. And I really appreciate that. I like that.

Maxim Wheatley (00:04:30): Yeah.

Katie (00:04:30): Yeah.

Maxim Wheatley (00:04:31): Yeah. It goes a really long way. And then it also helps you set up a conversation in a more productive way where you can be like, "Oh, okay, Katie has seen this so I can ask her about it," versus... So it does keep things moving nicely.

Katie (00:04:44): It lets you know if you have shared context.

Maxim Wheatley (00:04:47): Exactly.

Katie (00:04:48): Yeah. Rich, I'm calling you out. I'm saying hey. Hi Rich.

Maxim Wheatley (00:04:58): Hey Rich. And thanks, everyone, for joining. I know you've had a long, but certainly awesome conference here. The session with Richard just now was a great one. I learned plenty and it's certainly a tough one to follow. So my hope today is that I'll be able to really distinguish my content from his in many ways by focusing a little bit more from a really developer-centric perspective and share some of the lessons that I've learned in my journey building some open source projects to some reasonably large scale and we'll dive in in just a second. So Katie, I'll wait for your go ahead based off of the flow of today, but yeah-

Katie (00:05:41): Go ahead. Yeah, you've got this. This is your session.

Maxim Wheatley (00:05:43): All right. All right. So we'll get started and then let people trickle in.

Maxim Wheatley (00:05:49): But first off, thanks everyone for joining. My name's Maxim, and really what I'd like to share with you guys today is a different kind of perspective, I think. So I think Richard brings lots of fantastic value as someone who's very focused on community at large and from the perspective of an expert consultant and he's surely world class and excellent at what he does. I'm going to bring a different perspective, which is one of someone in progress, learning this on the fly, having done it over the last two, three years, share some of the insights that I've found being in the trenches, finding things that work, finding things that don't. And I think the most important thing that distinguishes today's session, and I'll look forward to soliciting your questions and us jamming together, is I really want to look at community through the lens of code. So really taking a more mindful look at what really matters when it comes to thinking about how your project or product is perceived as you're looking to build community in an open source universe.

Maxim Wheatley (00:07:00): So a little bit about me so that you can hopefully ask questions that will be well suited to my expertise and experience. So I've been at Merico for about three years. I'll be celebrating my three year anniversary in July and it's a company I've helped grow from five people when I joined to a little over 100 today. So it's been a really exciting journey building that. My role, we build a lot of technology. A lot of it is open source and my role is really to help make that technology grow, respond to product market feedback, building our communities, engaging with developers and users, contributors across a variety of products and projects.

Maxim Wheatley (00:07:43): In my past, I've also started and sold a consumer electronics company of my own. So I consider myself a very product-centric person and I believe I bring a lot of practical knowledge to the conversation here. When it comes to really understanding what does it take when you're figuring out how do you go from zero to something and how do you actually take an idea and turn it into something that's real, which is something I love doing in my day to day here at Merico.

Maxim Wheatley (00:08:14): So, let's jump in here. So my hope is that we'll cover these three core areas and do so as organized as we can. And certainly feel free to jump in and ask questions as you flow through. I'm going to solicit some feedback from you guys and the audience as we flow through this. So, what are we going to cover? The meat for today's presentation will be around this basic framework that I've put together for myself that I like to call The Four Cs of Contributor Conviction. We'll jump into that.

Maxim Wheatley (00:08:49): Oh yeah, Warren, good bit of feedback there. If you're not seeing the screen, I believe there should be two ways to do it. One of which you'll be able to follow the presentation with me, but you might need to follow along with me by scrolling for yourself. That part of Butter is unclear to me, but in any case, so we are on the what we will cover slide here. So I mentioned Four Cs of Contributor Conviction, a little bit about the ways to focus your attention on this very big, complex set of challenges. We're going to touch a little bit on the contributor funnel. We're not going to spend too much time on that because I think Richard covered it in great detail and it follows less on... Oh, looks like someone jumped me back there.

Katie (00:09:39): Oh, I'm sorry, that was me. I 100% thought I was only controlling my own screen. Sorry.

Maxim Wheatley (00:09:45): No worries. No worries. No worries. We're learning in real time, which is fun.

Katie (00:09:49): Oh, yeah.

Maxim Wheatley (00:09:50): But I think I want to share what are the goals, right? And here's my promise to you that I hope I can keep this promise to the audience here, is obviously every project is going to be really, really different. So I'm not going to give you some kind of guru type perspective on something that's going to solve all of your challenges. But what I do hope is that I'm going to equip you with a set of lenses and a set of frameworks so that you can take a look at your own project, your own goals, your own products, and really split apart what can feel very overwhelming and turn it into something that doesn't feel overwhelming. This is coming from someone who's been a one-man army for quite some time dealing with these things. And these are in some ways, as silly as it might sound, these are high-performance coping mechanisms. So let's share these with everybody.

Maxim Wheatley (00:10:46): So where I want to begin, like I said, this is really focused on an open source perspective, right? I think many, many technology companies, probably many of you in the audience, have some kind of open source strategy and there's all kinds of reasons that companies are going open source, right? I think one of the most basics is that products benefit from a more global development perspective. They benefit from the contribution of talented people around the world. It can give you all kinds of benefits in terms of credibility, in terms of trustability, with transparency. All of these things matter and businesses of all kinds have different reasons, but open source is becoming more and more important in my perspective, but open source doesn't happen without contributors. So that brings up this really key question of, how do you win the conviction and trust of contributors? How do you earn that right and that privilege to have them join in on your project? And that's what we'll jump into here.

Maxim Wheatley (00:11:48): So that's where this framework that I came up with, the Four Cs of Contributor Conviction really comes in, and we're going to split it today into these kind of four key categories. The first of which is code, second of which is community, the third of which is concierge, and the final is calling. And I apologize for being a little cheesy finding ways to wedge this into the four Cs, but hopefully it'll be memorable and hopefully you'll enjoy going through it with me.

Maxim Wheatley (00:12:16): So what do I mean when I say code? So at least in terms of contributor conviction, I think there are a few really important things to think about and we're going to go several layers deeper, especially on the code aspect in just a minute. So I think where a lot of open source projects go badly wrong is this first question, which is, can I get up to speed? So how are you putting together a really coherent, really user-friendly ReadMe, getting people up to speed, helping them understand the project, helping them understand the tech stack, helping them understand the purpose, giving them a clear jumping off point to dive into documentation. This kind of getting up to speed piece is critical. If you have a funnel that's bringing developers in, but they can't get up to speed on the code base, they can't get up to speed on the project quickly, this is going to become an instant blockade.

Maxim Wheatley (00:13:08): So, things to really think about as you go through this; think through your documentation, right? How do you put together a gradual flow for people to really get up to speed with things in terms of, how do you understand the fundamental building blocks of this? Before you get into any nuances around use cases, before you get into any nuances around how to engage with the community, or the kind of specifics of what makes the project unique or tricky, give them a clear guide of, "Here's what this thing is. Here's how it works." Documentation can solve that. Doing frequent code walkthroughs, especially if you're building a community, can also be really important.

Maxim Wheatley (00:13:49): We've started doing this on our end by hosting weekly huddles. We actually found that the weekly format was a little too frequent, so we switched that to a biweekly huddle, but in that case, depending on how new our cohort is in each of those sessions, we might do a fresh code walkthrough, but the importance is acknowledging when you have new people in the orbit and working really quickly and really diligently to get them up to speed with what it is that they're working on.

Maxim Wheatley (00:14:22): The other important part of code, which we're going to touch on in quite a bit of detail going forward, is what I like to refer to as tech stack alignment. And tech stack alignment really splits into two kind of perspectives in my opinion. There really are two types of open source contributors. I think there's one who are really focused on finding projects that I'm really great at, right? So if I'm a wizard with a certain set of frameworks, libraries, languages, maybe I really want to flex those muscles and create a showcase for myself, show off a bit, build my own reputation, build my own credentials by contributing in this way, right? So finding something that aligns with what I'm great at, and the docs, the ReadMe, everything on your GitHub can help them discover that.

Maxim Wheatley (00:15:13): The other cohort, which I think is arguably more important, and it's been my experience in open source is this question of, what do I want to become great at? We've found all kinds of really exciting moments in building our community and working with developers around the world, from people looking to make a career change, developers looking to make a career change, university students and computer science programs who are really looking to double down on a certain technology or a certain language and learn from people and put that learning into production.

Maxim Wheatley (00:15:50): These kinds of alignments are absolutely critical. So I like to think a lot about this as these key pieces that I've mentioned here is how do you get people up to speed? How do you split that out into particular action item lists that might revolve around huddles, code walkthroughs, a nice update, and real deep audit of your ReadMe, assembling documentation that helps onboard people and help them understand how they're going to go through this. And then last but not least there, also being mindful of how you can align the tech stack of your open source project to one of those two cohorts, right? Making it clear to them of, "Here's how you can really flex your muscles and show off those skills and build a showcase in something you're already awesome at." And as you discover people entering the community, if they're that, help them find high-impact issues. And if they're the former here where they want to get better at something, how can you really help nurture that part of the project?

Maxim Wheatley (00:16:55): So, Richard covered this in some really great detail and I'll try and cover it in a way that isn't redundant and a little bit different. So something that we still are challenged with, and I talk about this a lot with colleagues and other companies, is as you build community, community is an essential hub to coherently develop open source. You need to be able to have that kind of dialogue with contributors. You need to have that dialogue with prospective contributors, as well as users, right? You need a place for them to be gathering. And I think that ultimately is the role of community from an open source development perspective.

Maxim Wheatley (00:17:33): But I think to really make your community fly, it has to go several steps beyond that, right? It can't just be this hub to be discussing the ins and outs of the project. It has to also have a theme or purpose that wraps around that project and makes it a little bigger and I think that serves part of the funnel challenge, right? Where I'll give you an example for us, right? Our project is DevLake and we've grown it to many thousands of developers around the world downloading it, using it, messaging us about it.

Maxim Wheatley (00:18:08): And that project is really ultimately focused on what we like to call data-driven engineering. So when we think about the theme or purpose of our communities, as we really look to grow them, that's something we can wrap around it is declare this the place to be if you're excited and interested in understanding the role in software engineering. So thinking about this, the theme or purpose, I think really gives you this capability to make the community something more useful to people, help attract people who are maybe not so far along in terms of developing conviction on your project. That's where theme and purpose comes in in my opinion. So really seeking out that why, I think is really critical.

Maxim Wheatley (00:18:54): The other piece is thinking about how can you keep your community active and accessible? So I think we've probably all seen this challenge before where a community can feel a little bit like a ghost town or there's sudden fits and spurts of activity that can be difficult to catch up on or feel a little overwhelming. So I think making sure you're finding ways with your team, building in public, holding discussions, having a dialogue on decisions that are happening, all of that is part of what makes it feel active. In terms of making it feel accessible, I think that's really where the role of community managers comes in is making sure that you're greeting people and making sure that you're getting ahead of where they might be getting stuck, finding out, asking them questions, what have you struggled to get up to speed with? What's the purpose? Why did you come here? What brings you here today? Finding out if there's language barriers, right? Finding ways to keep it feeling easy for them to jump into.

Maxim Wheatley (00:20:02): The last piece here in talking about the open source spirit, as I mentioned, this is really a presentation and discussion focused on this open source perspective. And I think what a lot of communities seem to get wrong in my opinion, and we still haven't nailed it and we're working to get better and better at it is I'm staying true to this open source spirit. And what do I mean by that? I think ultimately what it boils down to is making sure that decisions are not done in the dark, right? And making sure that the context for things is shared with the community and making sure that there's this sense of best ideaships, best codeships, best logic wins the day, finding ways to make sure you're not just selectively putting certain pieces into your community, whether it's Discord, whether it's Slack, whether it's Discourse, whatever you're using.

Maxim Wheatley (00:20:59): Staying true to the open source spirit, in my opinion, means that you're really committing to building in public, having those discussions in public, inviting people sometimes proactively to weigh in on something. Maybe you've seen someone who has a particular expertise or focus area and their voice should be part of a discussion, finding ways to invite them into that proactively can really make sure you're staying true to the community spirit of open source. And I think, as Rich says there, transparency is so important, right? And as silly and basic as all of that may sound, I think so many communities are getting that wrong. And the result of that, when we're focused here on, how do you develop contributor conviction? These are the things that really matter. These are the things that people can sniff from a mile away. Developers can detect really quickly if it's disingenuous or not, and that's either going to make them believe that you're really here for the right reasons and doing it the right way or they'll feel you're not and they'll vanish again.

Maxim Wheatley (00:22:08): The last piece before we jump into the calling piece here is this thing that I like to refer to as the concierge, right? And I think this is especially important as you're growing from zero or building something that's early stage, which is doing the stuff that doesn't scale. And I really do like to see myself in my role in the community as a concierge to the people that matter, where we want to make sure our developers feel super welcomed. We want to make sure that they feel really guided and nurtured along in their journey. And where I'd like to double click on this concierge point, and we'll talk about this further into the presentation, and I mentioned this previously about tech stack alignment, making sure it's aligning with their own goals, when you think about yourself as a concierge in terms of taking care of your developers, you really want to understand, what does success look like to them when it comes to being a part of your community? And what does it mean to them to be contributing to your project?

Maxim Wheatley (00:23:14): It's surely a lot deeper than just saying, "Oh, you have a cool project and I want to tinker with the code." Sometimes it is that, right? But I think there's always a bigger purpose where maybe they want to learn about a particular technology or a particular technique or maybe they're looking to make that jump into a different type of role within their company, or maybe they're looking to make a complete career change, or maybe they're looking to break into a certain community. There's 100 reasons, and I think as your role as a developer-focused community manager, taking this concierge approach to saying, "Let's find out what this person is really most interested in. What do they want to accomplish? What does it mean to them to be a contributor to this project? And how can we really be supporting that?" And if you can find that alignment where you're supporting them as a contributor to the project, they're naturally going to take care of the project.

Maxim Wheatley (00:24:11): So I think it's a good way to think about your role there, right? Which is, you're not trying to extract stuff from them, you're not trying to find ways to enhance their productivity in terms of building your project. If you help their career, you help their goals as a great side effect of being part of that community, of being part of your circle of contributors, everything else really does take care of itself. This I'm absolutely sure of.

Maxim Wheatley (00:24:39): The last piece here, calling. So I kind of touched upon some of this, but I think it's important to really think about purpose, calling, this kind of interchangeable set of words. Splitting it between project level and personal level. So I think this personal level piece, I touched on concierge, is figuring out what's in it for them? What are they going to consider success? What's driving their sense of purpose, of belonging, of goals in that project?

Maxim Wheatley (00:25:12): But I really like to think about it across two levels, and I think when you think about it this way, hopefully it'll help you to identify really actionable goals, which is first thinking about, what's the calling at the project level, right? How are you orienting people to focus on the right tasks, the right issues, maybe the right parts of the product? Figuring out, "Okay, here are kind of things that you can dive into that we feel you specifically have impactful skills for?" Giving people that real sense of, "Right. We're building a house together and here's the part of the house that we think that you should be most focused on, where you can drive the most impact, that will be most visible, et cetera, et cetera." I think giving people that sense of purpose, that they're not just swimming in this enormous ocean of open source code, but they have a set of goals that they can be focused on can A, make them feel more invested in helping grow and evolve the project, but it can also help them feel a lot less lost. And I think where you can develop a purpose, you can really develop engagement and retention, which I think is everyone's goal here in this audience.

Maxim Wheatley (00:26:24): And then the last piece here that I mentioned is that sense of calling on a personal level. And that's where that concierge kind of mindset comes in, is figuring out, how do you align all of this to a developer's goals that they might have around developing new skills, cracking into new networks, building a brand for themself, right? If you can map all of these things to the evolution of your open source project, it's going to make it easy for those developers to want to stick around, to want to keep coming back, to want to increase their engagement and sense of ownership in the project. So, that's really what I mean when I talk about the Four Cs of Contributor Conviction.

Maxim Wheatley (00:27:07): So I invite you, whether you're sitting down with yourself because you're a one man show or whether you're part of a team, to split things out into these categories and think about, what are the things that we're doing here to really specifically address these pieces of the puzzle? So let's go a level deeper, or I guess, firstly I wanted to keep this a little bit more engaging rather than just talk to you guys. So we'll give it just a quick second and I'll pull the chat open here to see if anyone has anything they want to share and then we'll try and wrestle here with Butter.

Maxim Wheatley (00:27:52): But this is a question I would like to have everyone reflect on and maybe talk a little bit about is, what have you guys seen or done that helped you to develop your conviction? Especially if it relates to these four Cs. Did you do anything with your ReadMe? Did you do anything with your documentation? Did you do anything that was really high touch, minimally scalable to make people feel like they were seen, making them feel taken care of? Would love to see any cool stories of how you might have helped a developer accelerate their career or get a promotion or make a big jump in something by being a part of your community.

Maxim Wheatley (00:28:39): So yeah, some great chatter in here. We'll move forward because I think it's a challenging question and we don't have too much time, so we'll keep going through here.

Nikita (00:28:51): I can bring an example if you want.

Maxim Wheatley (00:28:53): Yeah, that would be great. That would be great.

Nikita (00:28:55): So basically, I think it's basically from the book, I think it was called The Goal. So you need to take something you love and you need to understand which group you are aiming. So let's say developers who did something nice, and then you need to connect it to what they want to achieve, get a higher salary or something. And then for example, he wants to get a higher salary so he needs a good feedback for the manager, so you notice his contribution and you just sent email to his manager and such and such person did a really nice job. That's cool. And trust me, his manager that is not getting these emails all the time. So stuff like that, it actually helps. Or find something he's interested in, it might be, I don't know, docs or something and then if you see he's stressed to upset, just asking about his docs and some service, these things they actually help.

Maxim Wheatley (00:29:55): For sure, for sure. And I want to give a shout out too to Nikita, he's one of the developers on DevLake based in London. And Nikita and I crossed paths digitally a couple weeks ago and we've had a great time collaborating together and getting to know one another. So Nikita, thanks for joining the session as well, really appreciate it.

Maxim Wheatley (00:30:18): So before we jump into the next section, I think if there's any one thing that I want to point out when it comes to thinking through these four CS in a smart way and staying true to the open source spirit, is it's this idea, that at the end of the day, transparency and inclusivity and being proactive about inclusivity, asking people to be part of the discussions, making sure that you're pushing everyone to not share things in one on one discussions or on Zooms that are composed of only a few people or doing DMs where context and content is only shared with a few people, right?

Maxim Wheatley (00:30:58): If you're really thinking about optimizing around these things, you're going to be true to the open source spirit. And I always like to phrase it this way, right? If they don't plan the battle, they're going to battle the plan. So when you're looking to build momentum on your project, you really want to make sure that people have conviction around the spirit of the product, the spirit of the project, the goals, the priorities, the objectives, and wherever you have this back and forth behind the scenes of people disagreeing, feeling not aligned, feeling unpurposeful, feeling like they don't have context as to why decisions are being made, that's where people inevitably, because you're going to be dealing with smart people, there aren't really any dumb people building open source technology in my experience, they're going to be critical thinkers and they're going to battle the plan and that's where you're going to have these big taxes on momentum is how I like to think about it. So think about those four Cs and figure out ways, always, to be proactively transparent, proactively inclusive, and make sure that people aren't battling the plan and make sure they're part of the plan for the battle.

Maxim Wheatley (00:32:09): So now let's jump into some more actionable stuff, right? And I think maybe this is hopefully why many of you came here is the topic of discussion today is get it right, right? A riff on GitHub, on GitLab, Source Control, really thinking about the role that code is going to have as you think about developing your community. And as I like to think about it here, this is really where the rubber hits the road. You can have gorgeous landing pages. You can have fantastic Slack channels. You can have cool swag, but I think if your code is terrible and your project is ugly from this perspective, this is where you're going to have the ultimate leaky funnel where people are going to come and go and never come back if they don't believe in it.

Maxim Wheatley (00:32:57): So I'll preempt this section with a couple of qualifiers, right? This is such a huge topic that there's just no chance that I'm going to be able to cover everything. So instead, what I've wanted to do is surface, after pulling many, many developers on our own team, many of our open source contributors, as well as colleagues, I tried to surface a slated, probably 10 things that you can focus on that are going to make a really, really big difference and that's what we're going to dive into here.

Maxim Wheatley (00:33:29): So again, keeping this within frameworks to make it feel less overwhelming. I think when you think about understanding your code from a developer's perspective in building that conviction, in building community, it's helpful to think about it in these three categories, and we're going to jump into these; so quality, responsiveness, and productivity, and these things may not mean what you think they mean. So we'll jump in here.

Maxim Wheatley (00:33:53): So I like to point this out when I talk about quality, right? Because I've worked with closed source B2B SaaS organizations, and I've worked with the most open of open source organizations, and something that they all share in common is they often talk about open source quality in their engineering teams. And we'll talk about here what open source quality actually means. It's something to aspire to and if you can get it right, it really does mean a lot to people.

Maxim Wheatley (00:34:24): So here are four actionable items that we can talk about here when you think about your code quality in terms of how it's going to impact developers' excitement around your project and their willingness to jump in. So first off, issue density, right? Somewhat self explanatory even to non-technical folks, which is really boiling down to how buggy is the code? So a lot of developers are going to run your code through a variety of products and tools, all to understand, how good is this really? And this is something that I think goes underappreciated and here's why, so I think if you have immaculate code, if it's clear that your team is really putting a crazy, crazy emphasis on reducing issue density and nothing but, anecdotally I can say that some of the developers I've worked with can almost see that as a warning sign also, which is maybe this team are just perfectionists, maybe they're focused on building the most stable iteration of what they have today without thinking forward about new features, new capabilities, new versions, right?

Maxim Wheatley (00:35:41): So I think issue density can be one way that you can assess, are we at the right level of quality where our code is surely not buggy, that people can see that it's stable enough to be worth tinkering with and that it's not going to be an enormous headache to work with? But at the same time, I want to point that balance out that immaculate code isn't necessarily something that's going to get developers excited. It's not going to give them something to go work on, something to go make repairs on and get started with maybe some low hanging fruit, but on that more abstract level, it can almost be an exclusionary aspect if they feel like there's no opportunity here for me to introduce new ideas, there's no opportunity here for us to take risks collectively and build something exciting.

Maxim Wheatley (00:36:32): So really putting together some KPIs around, what does a good issue density look like for us? And if there's anything I would want you guys to walk away from this presentation, it's to put together maybe a dashboard of your own, maybe just a checklist that you're going through, set some benchmarks for yourselves and work with your engineering team, if you're not on the engineering team, to figure out how are we setting some parameters around these things? What are we defining as a good issue density? And then how are we turning that into actionability? And as Warren pointed out there, which is exactly the point, issues at the end of the day and bugs create fantastic first issues for people to contribute to. And I'll be talking about that in a minute, which is providing people with these low hanging fruit opportunities to feel like they've made an impact, feel like they've solved a challenge, giving them a sense of purpose in the project.

Maxim Wheatley (00:37:39): The other piece here is code coverage, and you'll see this on a lot of really great ReadMes in my opinion. GitHub has all kinds of great badges, some of which include test coverage, right? And I think it's generally safe to say that while it shouldn't be the only thing you're focused on is creating great, great test coverage, having a real kind of appreciation and respect for unit tests, caring about it, making sure that you're building technology that is going to be easy to scale, easy to continue to build upon, code coverage is often a great way for people to be taking a quick look at this. So making sure that you're setting high standards for code that gets committed, what's acceptable versus what isn't, whether for internal or external contributors, and then showing off on this with your GitHub profiles, and with the ReadMe in particular, this is always an important thing.

Maxim Wheatley (00:38:43): And I think, for those of you who aren't necessarily writing code on a day to day basis or writing code ever and you're just focused on community, a good way to think about this ultimately is developers are kind of window shopping projects going, "How breakable is this thing? Am I going to just waste my time and effort and build something that's going to fall apart immediately because they're not testing it properly and they don't have code coverage that gives me confidence?" Or on the flip side, "This is a project that I can have confidence isn't going to fall apart if I move one thing here, and therefore I can do some stuff that's going to be impactful and exciting?"

Maxim Wheatley (00:39:26): Comment-to-code ratio. Again, I think hopefully none of these things are super, super surprising, right? The goal here is to point out what are the fundamentally important things here that will ultimately move the needle. So, you'll see a lot of chatter. I'm not going to specify a number on what percentage comment to code is good. I think you'll see it ranging between zero and 50% depending on what forum or thread you're reading, but I think the important aspect to think about as a community manager is finding ways to quantify this, to track it, and then to build processes and goals around it, invite developers to build upon things they've submitted or invite new ones to maybe create comments on stuff that they're either refactoring or just getting up to speed with.

Maxim Wheatley (00:40:22): These are important things for developers to really be able to get themselves up to speed, being able to familiarize themselves with why things are the way they are. And as I mentioned here, quality of comments matter. So I think having a dedicated focus on this as a community manager can help you build open source code and open source projects that are going to really resonate with developers when they see it, they're going to have high levels of conviction. So establishing this benchmark of, what do we consider good comment-to-code ratio? That way we can signal if we're on or off target, and then I would invite you if you have the capability and bandwidth to go layers deeper ultimately, and periodically audit some of the comments in the code.

Maxim Wheatley (00:41:09): Figure out if it's just something flippant like, "Did this to fix something that gave me a headache," is a bad comment, versus something that's providing context of, "Tried this. Didn't work. Did this instead. It does work. Here's something I felt like I didn't get enough time on," really rewarding and encouraging developers to build this level of comment out goes a tremendously long way. As new people are evaluating your code or going through it, feeling like they can learn, feeling like they're seeing context and feeling like there's opportunity here.

Maxim Wheatley (00:41:49): Last and not least on this quality list, average function size I think is something that for many, many people is going completely underappreciated, but was interestingly something that really popped out with many of the CTOs I've spoken with and many high profile, open source maintainers that I've spoken with. This can be a make or break stat, if you will, for savvy developers who are looking what projects are going to be worth contributing to and whether or not the code base is actually going to be something they're excited to work with. The easiest way to think about this for non-technical folks is if you have enormous, enormous functions and you're seeing that in the way the project is mapped, basically what that's indicating is you have components of your machine that are responsible for just too many things, right? So if you touch or tinker with something, it creates a high risk of something going wrong or creating many, many, many, many, many problems.

Maxim Wheatley (00:42:59): So if you're really focused on creating a benchmark around relatively small average function size, it makes all of those components of your machine easy to tinker with, more easy to wrap your head around, easier to get up to speed with. And this as a result makes it a more inviting and more appealing project to dive into. So these are four things, and Warren is putting some awesome additional thoughts here in the chat, so definitely follow along there, but these are four things. As I mentioned, I spoke with many maintainers, spoke with many developers on our team and in our community, these are the things that really jumped out to me as being the consistent signals of, is your project up to snuff from a quality perspective and is it going to be worth us spending time with? And these are important parts of what it's going to take to make developers excited to dive in and make them excited to stay.

Maxim Wheatley (00:44:04): So the next part is responsiveness and I have this cheesy little joke here, that it's more than just a multi-device support. It's more than just something displaying on your iPad and iPhone in a gorgeous way. So let's jump into responsiveness a bit. And as I mentioned, the goal here is really to make sure that we're putting together a list of items that you can track, that you can establish your own benchmarks for, establish your own action items for that are really going to make a big difference here.

Maxim Wheatley (00:44:39): So lead time, really the easiest way to think about this is, what's the amount of time that it's taking from something to go from an idea and going all the way through development to production, right? And this can go for really simple things like quick bug fixes or it can go for really big things like new features. And something that few projects that I've seen are actually tracking, but those that are are finding make a huge impact in terms of attracting developers. And so if you can really optimize around this and find ways to display it, find ways for people to see it. They're navigating the JIRA, they're navigating the GitLab board, whatever it is, if they can see that things are moving swiftly, that things aren't getting stuck in purgatory, it's going to make a really, really big difference.

Maxim Wheatley (00:45:39): The next key piece here, as you can read, is PR review cycle. And ultimately what this boils down to is the key part of the process, of what happens once I've written some code or made some updates to this project, how long is it taking for that to pass through the hands of the people that can provide feedback on it, the people that can approve it, and the people that can ultimately make it part of what's sitting in production?

Maxim Wheatley (00:46:07): So, I've certainly found in many larger scale open source projects, they end up getting really stagnant. And it's because this is something they're not really so mindful towards. So their poor request review cycle can, in some cases I've seen, take months, right? So it's very demotivating for developers on just a fundamental level if they're seeing, "Oh, I can write something awesome that I'm proud of, that I want to show off to people. I'd love to see it in production, but no matter how good it is, it's going to take four or five months for this to be visible to people on the extreme side." That's really demotivating for anyone, right? You want that instant gratification of, "I did something, it works, now it's happening." So finding ways to really optimize around this and commit to it is crucial.

Maxim Wheatley (00:47:03): I think it's really exciting, if you can invite a developer into your community, you can give them a first issue, something that's exciting and accessible for them to dive into, it's reviewed quickly and it's pushed straight into production, right? If you can make that really fast, that's exciting for everybody where they can immediately see like, "Hey, I discovered this project, this technology. I'm welcomed into the community. I can see how I can grow with it. I can see where I can be purposeful and impactful in terms of not just my career, but in developing this technology." And then bam, it's in production and I can show it off and I can point to something that I built that's actually doing something. That kind of responsiveness is really critical and I think goes really underappreciated. If you have this really stagnant process around processing tickets from creation to going into production, and then you're taking a long time to review the things that ultimately get pushed into the world, you're not creating a sense of exciting responsiveness that is going to incentivize developers to stay and to keep being a part of this.

Maxim Wheatley (00:48:12): The other key pieces here, somewhat obvious, but I think something worth creating benchmarks around is, how quick are your team responding to people on things like Slack, on Discord, on Twitter, whatever you're managing? Finding ways to make sure that when a developer's come in with a question, with an issue, that there's a rapid response so that you're engaging them rapidly while there's high levels of intent.

Maxim Wheatley (00:48:41): The last piece here, which I split apart importantly, around technical support is, and I think this is where a lot of projects really get jammed up is all of this stuff can be really challenging to get up to speed with. Getting a self-hosted technology running locally can be an enormous headache, even for the most experienced folks. So having really dedicated approaches to support the people who are working to get your technology up to speed here, having channels that are completely focused on this, making sure it's as synchronous as you can possibly make it, these are important ways to make sure you keep people.

Maxim Wheatley (00:49:24): And I think if there's anything I would want you guys to walk away from this presentation with as a superseding set of goals, it's this idea that funnels don't matter if they're leaky in these hidden nooks, right? You can have 10,000 developers come to your project. You can have half of them jump into the Slack, but if they get lost here, it's where you're going to get these really kind of sinister, hidden leaks. And I think most importantly, it's leaks that are in some cases, perhaps irredeemable, where if someone gets stuck, they're invested four hours in getting the project set up locally, testing it out, taking it for spin before they even begin considering anything else. And they get stuck on one of these things or they feel like there isn't a level of responsiveness, you're going to lose those people.

Maxim Wheatley (00:50:21): So these four things, in my opinion, signal a sense of this community, this code base, this project. It's responsive, it's active, I can get the support I need, things are happening, features, updates are moving into production quickly. High levels of responsiveness are going to play really well when it comes to winning the trust and winning the excitement of developers.

Maxim Wheatley (00:50:49): So productivity, another key piece of what I... And this is a slide that is not correct, but productivity, I think, is a really dirty word in engineering. I think it can be misinterpreted as how much work is being done and are you maximizing and the extractive processes of getting code out of brains. But instead I want to kind of reframe productivity in the spirit of open source community development and focus on really three things here, some of which we have alluded to a little bit here. I want to signal that these three pieces, I would argue, are maybe the most important parts of this presentation and are really good ways as a community manager to determine whether or not your project is working or is not.

Maxim Wheatley (00:51:47): So PR merge rate. So ultimately, what this boils down to is how frequently is your code that's submitted by external contributors actually going into production? How frequently is it going from someone else's MacBook into the wild for others to work with? And this, I think, is super critical for two important reasons. From a developer perspective, this can be something they can start to look at. They can either generate their own metric on this or they can just get a gut feel sense based off of exploring the project of, how likely is stuff that I'm doing actually, what's the likelihood that it's going to go into the wild and how likely is it that my work is actually going to be meaningful versus going to waste?

Maxim Wheatley (00:52:41): I've spoken with a lot of developers who've made contributions to open source projects where they're proud of the work, they felt like it had value, and it ultimately either got disregarded or rejected and that's no fun. They're creating, they're doing something, they're investing time and energy into something that doesn't really get seen by anybody. So I think if you can find ways to increase your PR merit rate, it's going to signal two things. It's going to signal that you have clear standards that developers can wrap their heads around and say, "Okay, here's what it takes to build something or contribute something that's acceptable, that's going to go out there."

Maxim Wheatley (00:53:24): And it can also, as a community manager, indicate to you whether or not you're failing people on this part. And if you're finding you have really low PR merge rates, that can be an indication that you either need to work with the maintainers of your project if you're not one of them to either change the way they're thinking about things or make them a little less stringent in some cases. A lot of perfectionism in this space. But perhaps if it isn't the maintainer's fault at all and indeed, everything that's getting submitted isn't up to standard, it can be a really good opportunity for you to start reposing that and figuring out how do we make tickets and issues easier to understand or more prescriptive to meet what our requirements end up being? How can we put together documentation, blogs, huddles that are going to make it easier for new developers to really understand what it's going to take to get something shipped? These are really important parts.

Maxim Wheatley (00:54:28): Code churn, I think, is another really important part, but I'm going to go a level deeper here. So code churn ultimately boils down to how often are things really being updated and changed? But I think what's really important to track if you're building an open source project and community from this developer-centric perspective is figuring out, what does your churn actually look like from an external contributor perspective? So this piggybacks on the PR merge rate, which is PR merge rates talking about how often is stuff actually going into production from anybody? But I think when you look at code churn, it lets you get a little bit more granular. And if you're focused on code churn from the perspective of flagging external contributors, you can actually see like, "Okay, how often is stuff actually entering this project from people that are true external contributors?"

Maxim Wheatley (00:55:28): We've actually done some analysis of our own on projects and this one surprises us in some cases and we've found, and this is some work that I'd like to publish at some point, a correlation between these really high growth projects that have really high levels of churn basically from external contributors indicating that there's a lot of work that's going into the code base from outsiders, correlates quite strongly with high growth. And the projects that are really becoming stagnant or slowing down are the ones that are maybe looking like they're developing quite a bit. You can see there's frequent updates. You can see the heat maps are looking exciting, but when you really go a level deeper, it's a lot of internal or sponsored developers, and therefore less accessible to outsiders to join in. So, this kind of code churn metric, I think, can be a really great way to think about how you're optimizing for the right things and making sure you're inviting people to make these contributions.

Maxim Wheatley (00:56:38): This last piece here around productivity is the issue life cycle. And this is perhaps a less quantitative piece, but one to be thinking about and keeping your finger on the pulse of as a community manager, which is this idea of, how frequently are new issues created? Is the project feeling fresh? Maybe a developer comes to your GitHub page and they find, "Oh, this is interesting. It aligns in many ways, but the set of issues right now are not things that I'm necessarily interested in or feel equipped to address," but maybe they'll bookmark it. Maybe they'll come back and look for things that are going to be good first issues for them. So being able to create this steady influx of new issues, super, super important.

Maxim Wheatley (00:57:28): Equally important is the tail end of this, which is, is your project creating all these issues that aren't getting solved or sitting in the backlog? So that's the kind of question I want to pose there is, is there a balance? Are you creating new things to create new opportunities? And are you demonstrating to your community that you're solving them in a way that people can feel like this project isn't stagnant, that there's timeliness and responsiveness cooked into this? The balance here is really critical.

Maxim Wheatley (00:58:00): So I'm realizing here that we're coming up on an hour, so we're not going to go too much further, but I want to point this out here before we jump into any kind of closing Q&A. One thing that I hear a lot of business people talk about is the concerns around open sourcing stuff that, this is a way for us to lose our grip on what it is that we're doing, losing the value that's buried in our IP here. And I think one way to think about this is, you can fork code, but you can't fork responsiveness. You can't fork stability. You can't fork lead time. And you certainly can't fork community, right? So when you think about really building momentum on something that's open source, really think about these key pillars that we've talked about here.

Maxim Wheatley (00:59:01): If you're focused on these things, it doesn't matter if the project gets forked, it doesn't matter if someone tries to create a derivative of it, benevolently or malevolently. If you're the one fork to rule them all, which I cheesily put here, because you are the most responsive, you are the most welcoming, you're committed to clear standards of quality, you're tracking these things that make the project feel active from a lead time, going to production perspective, they matter, people will take notice, and it will pay dividends in the end.

Maxim Wheatley (00:59:34): So I'm going to pause there because we are at this hour and I don't want to be disrespectful of everyone's schedules here. I'll share these slides for you guys to dive into if you want because I have very many more things that are worth diving into here in terms of splitting out these complicated issues into more manageable focus areas. I'll leave it to you guys to jump in to if it's useful. I'm certainly excited to review any questions with you guys, so please do reach out. I love talking about this stuff, but yeah, let's pause there. We'll close the screen share and see if Butter is working with us.

Maxim Wheatley (01:00:18): So thanks all of you guys for sticking along with me. I know it's pretty late in the day for many of you. It's been a long conference, but I appreciate you guys being part of this and I hope what I shared is helpful and I'm here for any questions wherever. Let's just pull up the chat here in case-

Nikita (01:00:43): So when you are speaking about the call, because I'm quite fresh in this project guys, so I think it's important not to only think about test coverage, it's important to be extendable. So there are things which check for security issues early in the cycle, there are quite some solutions for that. And there are also things which check for code quality. Of course, they want replace your engineers, but what they will do, they will give them some space to think because they will remove all the easy things, and so developers will be doing what they're paid for. And personally, if I can do these things and developers will leave office two hours earlier, but happy, I will be happy because I don't want them to be tired because their goal is to bring value to the business. If they do it in four hours' time, I actually like it, as long as they don't get too drunk.

Maxim Wheatley (01:01:54): Absolutely. Yeah. And I think for those sticking around, I know I've said there's many things I would want you to walk away with, but I think the important thing to really think about with all of this stuff is how can you use these tools, how can you use these processes, how can you use these metrics that relate to code to establish some kind of actionable goals for your community? How can you use those to guide what kind of specific projects or action items you want to pursue? And understanding that these are things that, maybe to outsiders, aren't going to feel too important or too impactful, but to the people building your technology, to the people that are being the builders in your open source community, these are things that matter and ultimately make a difference.

Maxim Wheatley (01:02:51): All right. Well, thanks everyone for joining. Katie and the Orbit team, thanks for letting me come play with you guys and be part of this. And I apologize too if this wasn't as polished as I'd like. I had some tech issues in having to dig up an old MacBook to get this all to work today. My production machine is broken here today, which was a very stressful day, so I came into this feeling like I got thrown out of an airplane, but I was able to get back on the line here and hopefully this was worth your time. It was certainly worth mine.

Katie (01:03:34): Thank you. Thank you so much.

Nikita (01:03:39): It was actually quite good.

Katie (01:03:42): Yeah. I feel-

Nikita (01:03:44): Because open source is a huge thing now and the biggest problem is to bring people to the first commit, so that's the hardest part, at least as the chief people in GitLabs think. So yeah.

Maxim Wheatley (01:04:03): For sure. For sure. And Nikita, as an aside, we were chatting earlier today, we're wanting to set up a jam session with you for early next week. So we'll ping you for that, but thanks so much for joining.

Maxim Wheatley (01:04:27): Katie, I don't know how I do this. If we hang out in the room, I'm happy to, or if we end it, but...

Katie (01:04:33): I think you could just X out. Just X out the browser tab and it'll end.

Maxim Wheatley (01:04:37): All right. All right. Well thanks so much everybody. We'll make sure the slides get shared and definitely reach out to me at Twitter, LinkedIn, email, wherever if there's nothing you want to double click on here.

Katie (01:04:48): Thank you, Maxim. Thank you everyone.

Maxim Wheatley (01:04:48): All right. Bye, guys.

Katie (01:04:48): Bye.