Climbing the Contributor Ladder

Show Notes:

Sponsor Virtual Coffee!

Your support is incredibly valuable to us. Direct financial support will help us to continue serving the Virtual Coffee community.

Please visit our sponsorship page on GitHub for more information - you can even sponsor an episode of the podcast!

Virtual Coffee:

• Virtual Coffee: virtualcoffee.io
• Podcast Contact: podcast@virtualcoffee.io
• Bekah: dev.to/bekahhw, Twitter: https://twitter.com/bekahhw, Instagram: bekahhw
• Dan: dtott.com, Twitter: @danieltott

Transcript:

Bekah: 00:04

Hello and welcome to Season 10, Episode 7 of the Virtual Coffee Podcast. Virtual Coffee is an intimate community of people at all stages of their tech journey, and we're here to share insights, experiences, and the lessons that we've learned along the way. I'm Bekah, and I'm here today with my co host Dan.

Dan: 00:23

Thanks Bekah. This season we are continuing to dive deep into the back pocket topics from our Tuesday Virtual Coffees. Today's topic is climbing the contributor ladder. We are grateful to be sponsored by Level Up Financial Planning that helps you take your financial confidence to the next level. It's real financial planning to help you reach your goals and gain clarity on what actions you need to take now to maximize your tech career. Level Up even has a podcast where you can hear about some of the things, the strategies he uses with his clients. Check out levelupfinancialplanning. com and you can get that link in our show notes.

Bekah: 00:56

All right, so now it's your time to grab your favorite drink, settle in, and we're gonna get started with today's Virtual Coffee. We hope you enjoy this episode.

Dan: 01:12

Yo, what up, Beck? How's it going?

Bekah: 01:15

It is, you know, just trying to make it through.

Dan: 01:20

Make, make it through. Yeah, I hear you. When this episode comes out, it will be near the end of October, right?

Bekah: 01:29

Yeah.

Dan: 01:30

And so we have been cycling through a lot of Hacktoberfest stuff, and it's been very fun. I'm sure Future Dan and future Bekah. I've been having a lot of good times in, in October. Um, just to pull back the curtain a little bit, we are recording this one early, a little bit earlier in October. So Hacktoberfest has started and that has been fun. We did our kickoff, everything like that. We already have a bunch of pull requests in at, um, at Virtual Coffee at the site. So that's been fun. Uh, and yeah, it's a good time. And so today I hear we are talking about. Climbing the contributor ladder. And, um, that sounds like a really interesting topic to me because I didn't even know there was a contributor ladder. So why don't you lay out what that means?

Bekah: 02:14

Okay.

Dan: 02:15

Are you okay?

Bekah: 02:18

to sneeze, but then I was trying to like, shove it back.

Dan: 02:22

Sometimes it's better just to let the, it's okay.

Bekah: 02:25

I know, but I, I also have like sonic boom sneezes, so I like have to make sure that I

Dan: 02:30

All right. Well,

Bekah: 02:31

mute that.

Dan: 02:32

right. I suppose me and maybe the audience also appreciates that.

Bekah: 02:35

Yeah, um, Contributor ladder. Okay, so, um, This is actually something that I just became familiar with in the last year, and we've had a lot of questions from people about that are asking, like, well, how do you get to become a maintainer? And they don't really mean, like, a maintainer of their own project, because you could do that right now, this second. Um, you can start your own project and you are the maintainer of that project by default. Uh, they mean, like, a maintainer of another project. So maybe you've been contributing for a while. How do you get there? And there's no defined path. way to do it. Every project is going to be different. But the contributor ladder kind of means, like, how do you make progress? And how do you grow? And what are the steps along the way, if that's the trajectory you want to go on? So maybe it's becoming a maintainer or becoming a core member of a project, or something that requires maybe a little bit more responsibility and you taking on additional tasks. So it's from kind of, you know, the Think of it from first contribution and I'm using that term loosely because it might mean like talking in the community or something like that all the way up to your goal for where you want to

Dan: 03:44

that people are thinking about it. I don't, I don't always, you know, think in the most goal oriented way, you know, and, um, but I know that some people do. And, um, it's, it's a cool thing to do. It's also, uh, we, we've said it before. It's very rewarding to be at that sort of, you know, position, be helping at a higher level on, on, on projects like that. So I think this is a, it's pretty cool concept to think about. Yeah, I think the first thing that comes to my mind is what you said before is really just like multiple quality contributions to the repository over time, right? You, you're never going to, very rarely going to just like walk in to a new project. And even if they're asking for maintainers, right? If you've never contributed on the project, uh, they might take it, you know, like if they can look at some of the other stuff you've done, but the, it's more likely they'll, they'd rather do somebody that they, uh, know and trust, right? So I think that's first step, right? Is keep contributing to the same, you know, the same project. I think

Bekah: 04:56

I would say like this goes along the line with our episode on trust capital. And I think if you haven't listened to that one, maybe go back and listen to it because if you want to make progression, then building that trust is going to be incredibly important and finding ways to do that will, um, you know, allow you to move forward. The other thing I think that's important about the contributor ladder is that, um, it's good for contributors and maintainers. It's totally fine to be a contributor and not want to make progress, uh, and move up to that position. So I just want to make sure that's clear. Um, but there are certainly people that do want to make progress and grow. And if there's a clear path for people to grow and they can understand, like, this is how I continue moving forward. forward. A lot of people find motivation in that. And so, if you are a maintainer, sometimes it can be useful to retaining, uh, contributors and having repeat contributors if you kind of make that path clear to them. So, um, I know that, I think it's Astro, maybe Nuxt does this too, but they at least have in their mind what the path is. They want, um, their contributors. to be able to go on. And so their docs repository is very easy to contribute to. I, I don't mean easy. I think they, they do a good job of documenting and providing support for people. So especially new contributors. So it's pretty welcoming to new contributors, but in their mind, there's a progression that you can take from docs all the way through the main Astra repository. Um, if that's something that you want to do, so it's kind of like a building up different steps of how you can grow as a contributor to that project and I think that this is one of the reasons why Many people i've never heard anybody say anything bad about contributing to astro Um, everybody talks about the positive experiences they have there in the community And I think it's very it's because they're very deliberate about thinking how they want to support their contributors Um,

Dan: 07:04

Yeah, I love that I'm, I'm kind of going through their, um, Um, Uh, repository in their documentation right now to see if I can find that. Uh, providing that sort of thing is also another thing that I've never, I've never thought about, you know, and I think that can be very valuable. Cause one of the problems, one of the hard things about this sort of thing of climbing the contributor ladder, right. Is there, every single project is. Wildly different from this regard, right? Some projects are very personal, you know, a person, you know, a maintainer might love the love contributions, love the help, but not like have any interest in, um, having somebody, you know, do things like that. Um, or another project like Astro seems like they have set themselves up to. Embrace this sort of situation, right? And, um, mentioning that somewhere, I think, honestly, never really occurred to me at all, you know, uh, but I think that's a great idea for, for a maintainer of a project, right? Um, you know, you, you see, you see projects where they, they have like a pinned issue that says, I'm looking for a maintainer, you know, something where they've, they've moved on from the project. They're, they're like looking for somebody. Um, but, That's, you know, that's like, it's already, I mean, I'm not gonna say it's too late, but you've already passed the point of where we're talking about, right? Like, uh, the better situation would obviously have been if they had, uh, developed some people like this throughout the life of the project while they were still interested in it, you know? Um, all right. So I'm still, I was trying to look through Astro. So you said, you mentioned Astro, you mentioned Nuxt. I, uh, this was like a big question for me was, uh, was what are some examples, you know, of. People who have laid this out. And so, um, I wish I don't want to like sit here and silently browse while, uh, while we're talking, but I'm trying to do like, I guess.

Bekah: 08:55

I would say, like, if, do you want to walk through maybe what a breakdown might look like of, uh, progressing in the contributor ladder?

Dan: 09:04

Uh, you mean from a, from like a contributor point of view?

Bekah: 09:07

Mm hmm. Like,

Dan: 09:07

You mean? Yeah, yeah, yeah,

Bekah: 09:08

and how would that progression go? Mm hmm. Yeah.

Dan: 09:10

Right. I mean, I think the, I think that you mentioned like the starting point is the starting point is going to be the same for everybody and it, and it doesn't, like, it can be really anything. To start, you know, uh, for me, lots of times I, you know, I join a new open source project because I'm using it. It's like a package or something that I'm using for something else. And there's a bug, I found the bug, you know, and, um, and so I. We'll do the whole thing where I, you know, see if there's an issue already for it. If not, you know, blah, blah, blah, follow their contributor guide and stuff like that. But hopefully, you know, um, file a pull request and fix the bug, you know. Um, but lots of times those are harder to find, like, these are lots of times ones where there's not an issue already, you know, and, um, that's not a good, that's like, they come, they come to me as they come, you know, I'm not like, I'm not seeking those out, right. Um, but it's the same situation. I would say whatever level you feel comfortable at, there's millions of ways to contribute to like millions of different projects. Right. So that's the first step. And that's what we're all about in Hacktoberfest is right. Is getting people through the first few steps of this. Um, but then after that, I mean, I think. I think the, the thing that I would do if I found a project that I was like, wow, this is, this is like really cool. It seems like a good community. Um, you know, the maintainers, you know, care or whatever, and are, you know, respectful and everything, um, is at that point I would read everything I could, you know, I would read the contributing guide again, like I hopefully have already read it for the first issue, but I would like, now that I've like gone through the cycle, you know, I would go read it again. Cause sometimes they mentioned things in, in docs that, um, if you're not familiar with the project yet, don't make sense. Right. That you won't catch until, until you've already dug in a little bit. Uh, and then if they have, you know, and then go read other things. Like if they have a discussion board on GitHub, if they have a Discord, if they have other things like that, it just kind of just start cruising around, you know, see what people are talking about. See what the maintainers especially are talking about. And if it's on GitHub, I'm not super familiar with Discord. I'm sure you can do searches and stuff, but if it's on, um, uh, the GitHub, you know, both issues and, and pull requests and, um,

Bekah: 11:19

Discussions.

Dan: 11:20

discussion boards, you can search like. By the author, right? So you can see what kinds of things are the maintainers saying, right? Because lots of times the projects, especially if they're a little bit bigger, they'll have more action. There's always going to be people that are just like, Oh, I need this. You know, I'm like, you know, they need help or whatever. Um, and you can see, okay, here's how the maintainers are like handling some of these things. You also, maybe you can see other people that are doing things like that you want to be doing, right? Where, um, there's maybe if they have a discussion board and there's questions that aren't answered yet. And you know, the answer, you know, like that is an amazing way to do, do things, right. Is because that helps everybody that helps the person ask the question, helps the maintainer because they don't have to deal with it. Uh, same in issues. You know what I mean? If there's like some issue that you've seen where somebody is having a problem and. We've talked in past about creating good issues, right? And that's a skill that takes time to develop over time to develop over time. It takes, you know, it's a skill that you need to develop and not everybody has a skill and that's fine, right? And so you'll get an issue that is. Seems like a bug, but doesn't have maybe a full, like reproduce, you know, reproducible example, right? Things like that. Like that's an important step of this, because if I as a maintainer get an issue about a bug, the first thing I'm going to try to do is try to make the bug happen so I can see it happen. Right. Cause lots of times, especially with packages and stuff, it could be. Well, it's not actually a problem with my package. It's a problem with the interaction, you know, whatever there could be, or it's just a configuration, you know, issue where the person can just tweak something and then it'll work, you know? Um, and so if they haven't done that, if they haven't produced their own reproduction of the issue, um, you could do that, you know, and. You can even say, like, maybe you can't reproduce it, you know, and you can say, Hey, I, and just comment on the issue. Like, if you'll see the maintainers do this all the time and there's nothing stopping any contribution, uh, any, anybody from doing the same thing, right? If the person hasn't, um, for whatever reason, you know, created a reproducible example, go ahead and do it, you know, um, the maintainers will love you for that, you know, and like, that's the kind of thing you don't need to be, you don't need permission to do that, you know, uh, you don't need to have, uh, you know, you don't need to be a member of the repository, you don't need to be like, you know, the different like levels of, Whatever a triage or whatever, um, you can just comment on issues all the time. And if you're doing it helpfully and respectfully, you know, I, I would say I would avoid, unless a maintainer has specifically asked you to do this, I would avoid scolding people as, uh, like, I mean, it can be easy to do, right? So like the same thing, you, you can have Imagine a repository that very strongly says, you need to have a reproducible thing to submit an issue. You know, like, and somebody files an issue without that, um, the maintainers, if they want to can say, Hey, you know, I mean, there's, there's all sorts of different ways to approach that from a maintainer point of view, but as a contributor without like, Having given, uh, you know, a role by maintainer, I would say probably not your call to just like say, you forgot to reproduce your issue. You know, like that's not gonna be fun, but if you can swing in and say, Hey, I noticed you didn't reproduce it, but I was able to reproduce a year, or I wasn't able to be like, I noticed you didn't reproduce it. I worked for like an hour to try to reproduce it and was not able to, you know, you know what I mean? And, and post those results somewhere on, um, CodePen or wherever, you know, that's the kind of work that it takes time. And like I said, if you don't, if it's a, if it's a hard to find bug, like I said, I spent an hour trying to reproduce a bug that I, on my own thing, you know what I mean? Like, uh, like I noticed a bug with a package or something and I wasn't going to file the issue without. Uh, the way you do that is, you know, you, you install just the package and no other things. And then all of a sudden the bug's not happening and I'm like, Oh God, what is happening now? You know, and it's frustrating and, um, it takes time. And so if somebody else, Files and issue without that stuff, the maintainer has to spend an hour trying to reproduce it, you know, and that's, that's just time, you know, time that somebody else could do. Right. So I think that's like a great way to help maintainers, um, and, and build the trust capital and do meaningful work, you know? Uh, so that'd be my first, second step, I guess that's step two, get

Bekah: 15:52

Yeah, and I think, like, you were talking about reading the contributing guide, reading the docs, and I think that's super important. Um, and I think that can be, like, part of that next step as well, because I found, like, sometimes when people are running into problems, it's because the documentation is out of date, so that needs updated. And so, like, those two kind of work hand in hand. Figuring out how to run the project, making sure the documentation is up to date. And in terms of, I spend a lot of time maintaining docs and I, I've seen the progression there with a contributor recently who wanted to work on an issue. And I assigned them the issue. And I kind of like spelled out everything they needed to do. I think it was their first time contributing. And they were like, this is great, I'm going to take this on. I would also really love an opportunity to be able to, um, you know, maybe work on something myself. So like, if there's a project that you have that you've been wanting to do, And you don't necessarily have it outlined in an issue right now. I'd like to do things like make decisions about, like, the hierarchy of how the information is displayed, where it's presented, and that sort of thing. And you could tell that she had already read the docs, and she had already thought through some of these things, and she was like, this is one place where I was thinking about it. Um, possibly doing that. And so, she worked on the first issue, did a really good job, and I said, this is something else that I've really been meaning to get to, but I haven't been able to, because it requires me to reorganize everything, and that's just like, that takes a lot of time and effort. And so, I asked her like, okay, would you be willing to work on this? And so, this is like, one of the reasons why I find Hacktoberfest to be great as well, because This is in my backlog of things that I want to do. I have a contributor that's proven that she can handle, uh, contributing to documentation in a way that works for the overall project and that she understands the project through the questions that she's asked. And so now she's made progress. to move from, you know, maybe a, a more beginner level issue to something that I would say is more in like the medium side or to hard side of things of documentation because it's not just I'm writing a definition, it's I'm thinking about organization, presentation of materials, and how to convey this to the audience. So, um, like I appreciated that, uh, growth in her as well.

Dan: 18:14

Yeah, absolutely. I think that's great. And I also, like, another thing I wanted to call out there is that she reached out and was like, Hey, I would like to do the X, right? And that's, you know, That's really important too, you know, and, um, trying to think it's like you said, you know, sometimes you have these ideas in your head, but you can't just like put an issue with a title and like a loose description because there's all those decisions you need to make, right? Like you said, and the, that is one of the harder things about open source is like, okay, do I, you know, do all this work myself? Do I do a ton of work to try to lay it out, you know? Um, but then I'm making all these decisions, which is like part of the work, you know, and that's part of developing. It's not like. You know, sometimes I'm excited to do this stuff, right? Um, but don't always have time, uh, in every, every sense of the word, right? And so having somebody that you, you think can make some of those decisions, you know, I mean, that's like, that's like a few rungs up the ladder in my, in my mind, you know, thinking as my teen or, you know, somebody who, I would trust to do something like that is like pretty close to, the top of the ladder, I think, you know, uh, and like the situations can be different for different things. Right. but yeah, I think the, the aspect of like, Hey, I would like reaching out and saying, I would really like to, you know, to help in some way. Like, what can I do? Like, that is so cool. Right. Cause especially if you're a person who has built a little bit of trust capital in a project, right. Uh, you know, um, You can, like, as a maintainer, probably, like, just wander around thinking, Oh man, I wish I could have some help on this issue, you know, or I wish I could have some help on this project. And there might be a whole bunch of people that are like, would love to help, but you, you haven't asked because like, that's kind of, it can be hard, you know, to ask like an open ended, uh, I need help, you know, kind of thing. And the people who would like to help haven't, you know, specifically like reached out and been like, Hey, I would love to help on this project and get more involved, you know? So I think that's another like great step is, especially if they don't have it laid out like, um, like Astro did, um, that you can say, I think, I think this would be perfectly fine. It is like, I made a couple of contributions. I would love to get more involved in this project. Like what can I do to get more involved and like, just asking, you know? Um, I think that's a great call.

Bekah: 20:33

There's a couple of things here, too. I, conversely, if you're going to ask to work on an issue, make sure you understand the project, because I've also had people who have asked to work on, you know, more complicated issues, and then it, it becomes pretty clear that they, they don't know how to use the project. Um, and, and, That's going to make it a more drawn out process for the maintainers and for themselves. So just make sure that you understand before asking to be assigned an issue. Um, but I want to just go back one more minute to the same contributor because, um, she's also been working with Nick Taylor, uh, who's one of our members at Virtual Coffee, but on my team as well. in our app repository. So, uh, we have documentation, which I largely maintain. She's working on two issues for me there, and she reached out to him and asked to work on accessibility issues. And so Nick broke down a list, or I think it was Nick, um, of a bunch of things that needed to be done, and they talked through them, and he asked like, hey, do you kind of want to run point on this issue? Because there's like, 10 sub issues in there or more and she she said yeah like I would love to run Point on this and so she's kind of taking on some of the issues But then allowing other people to work on them as well And so I feel like if we look at the contributor ladder, she's a great example from that You know, initial docs to harder docs to accessibility, but also like kind of managing other contributors and making the contributions herself, uh, across multiple repositories. And so I think like, you know, it's, it's def, we've definitely seen the progression with her.

Dan: 22:13

Yeah, that's great. And like that sort of, I was just going to mention like GitHub specifically has that, they have these, you know, roles, right. And they don't always like. map exactly to what people are doing. Right. But there's just the default, you know, read only like visitor role. And, uh, uh, and then the next one up is like triage. Right. And so what that is, is it, it gives a person access to assign issues and, um, you know, labels manage things like that. Um, let's see what they, they can also manage issues and pull requests. And so like the, this is a level I think, That sounds a lot like that, right? Where you, you give somebody that you trust some permission to, help other contributors. That's like, that's great. Like that, that's like a, a very ideal situation for maintainer as well, because that's a ton of the work is if you have a lot of contributors is dealing with it, making issues, uh, assigning issues, checking the pull requests, all of that stuff, right? Um, that's all like time consuming work. And, um, Finding somebody that is willing to do that as well is amazing. So that's really cool.

Bekah: 23:22

And I think, like, if we would look forward and continue to use her as an example, like, where would she go next in the contributor ladder? Well, she's working on these accessibility issues. And one of the things that, at Open Source, we move very quickly. So, there's not a lot of, like, feature work, and even, like, big, uh, bug issues that we assign to external contributors, because, like, We're on a timeline where we have to move quickly. Um, but if we were to assign something like that to an external contributor, she would definitely be one of the people that we would go to and even reach out to and say like, Hey, would you be interested in working on this? Because we know that she wants to make progress and grow, and she also has this proven track record of being able to handle different things and reach out and ask good questions.

Dan: 24:07

Yeah, I mean, that's, that's another, you know, aspect of all of this stuff, um, is there's lots of companies like that, that have paid people that work on their open source projects, but then have outside contributors and, you know, becoming a trusted contributor. That has so many good, you know, um, like benefits, right? Of, I mean, maybe if you guys were going to hire somebody, you might think about her first, right? Uh, you know, and, uh, or if she applied and her name came up, you would all be like, yes, you know, right? Cause you know her, you know, you know, you don't even, you don't need to like have her do a co test or whatever. You, you already like know what she has done, um, for you. I'm sure she's done other things too, but you know what I mean? It's like, uh, And there's lots and lots of companies that do that, right? Um, so it's a cool thing,

Bekah: 24:57

I am, I knew this woman who was, she really wanted this job, uh, and she knew that she would never pass their coding challenge because it was notoriously very, very difficult, but it had nothing to do with the actual work they were doing. And so her approach was to contribute consistently to their open source project and what she did, and she, and because of that, she was able to get the job and they bypassed that test. She didn't have to take it. That's not gonna happen

Dan: 25:27

That's incredible,

Bekah: 25:28

but like, you know, it's exactly what you're saying that, you know, sometimes you build that relationship, you show people can trust you, you show that you can produce quality work, and then you do, like, I guess for a lot of people that's like ultimately the top of the contributor ladder getting hired somewhere, but um, that, that's not, you know, that doesn't happen everywhere, but I, I just think that that's like a great example of making that

Dan: 25:54

Absolutely. And it also, um, displays your communication skills, uh, which is like something that I feel like we've talked about a few times, but doesn't, it sometimes gets overlooked. One of the benefits of having a track record like this is not just the coding work or the, um, the actual contributions, but your ability to communicate. Um, With other human beings, which is, uh, you know, fortunately, or unfortunately, a very important part of, uh, working together with other human beings. So you need to be able to communicate, uh, so it's, there's, again, you know, we just, every time we talk about open source, we come up with more, like, reasons to do it, you know, um, and that's just the latest one, I suppose.

Bekah: 26:33

Yeah. Well, I think that we covered a lot of ground here. We have climbed that ladder and to the top. So we thank everyone for sticking around and listening and we'll catch you next time.

Dan: 26:44

Thanks, everyone. Thank you so much for listening to this episode of the Virtual Coffee Podcast. This episode was produced by Dan Ott and Bekah Hawrot Weigel, if you have questions or comments, you can hit us up on Twitter @VirtualCoffeeIO or email us at podcast@virtualcoffee.io. You can find the show notes, sign up for the newsletter, buy some VC merch, and check out all of our other resources on our website, virtualcoffee.io. If you're interested in sponsoring Virtual Coffee, you can find out more information on our website at virtualcoffee.io/sponsorship. Please subscribe to our podcast and be sure to leave us a review. Thanks for listening and we'll see you next week.

The Virtual Coffee Podcast is produced by Dan Ott and Bekah Hawrot Weigel and edited by Dan Ott.