What Happens when you Contribute, revisited

I sat down to write a post about my students' experiences this term contributing to open source, and apparently I've written this before (and almost exactly a year ago to the day!) The thing about teaching is that it's cyclic, so you'll have to forgive me as I give a similar lecture here today.

I'm teaching two classes on open source development right now, two sections in an introductory course, and another two in a follow-up intermediate course. The students are just starting to get some releases submitted, and I've been going through their blogs, pull requests, videos (apparently this generation likes making videos, which is something new for me), tweets, and the like. I learn a lot from my students, and I wanted to share some of what I'm seeing.

Most of what I'm going to say is aimed at maintainers and existing open source developers; I'm talking to myself as much as anyone. Because the students go out and work on real open source bugs in all different projects, anything can and does happen. I can't easily prepare them for the responses they'll encounter when they put themselves out there on the web: I see it all.

When you work on (i.e., specialize, focus on) a few projects, and within a particular community, it's easy to get lulled into normalizing all sorts of behaviour that may or may not be the most productive way to work. However, when you participate in a lot of different projects, you start to see that there are a many different approaches, each with varying degrees of positive and negative outcomes.

I wanted to lay before you the kinds of things I've seen this month. I'm not going to link to anything or anyone in particular. Rather, I want to show you the variety of possible scenarios when someone contributes to an open source project. For the most part, these students are at a similar level (i.e., undergraduate CS) and doing similar sorts of patches: first contribution to a project of small doc/test/code fixes, ~100 or fewer lines of code.

...crickets.... It's really common for PRs to just get completely ignored. Sometimes this happens because students contribute to dead or dying projects, other times the maintainers just can't be bothered. I try to intervene before this happens, but even I can't always predict how submissions will be received (I had a big PR get rejected like this recently). Looks can be deceiving, and a lot of projects look more active than they are. I deal with this by marking the content/process of a change vs. its reception/outcome.
"LGTM, merged". A lot of times the code is correct, the expected process has been followed, and the PR is merged as is. There isn't a lot of criticism, but there also isn't a lot of fanfare. It's likely the 100th PR this maintainer has merged in recent weeks, and it's just another day at the office. This is pretty typical. I think it's OK, but it misses the chance to further engage someone new in your community. I wish GitHub did more to signal in a PR that this is someone's first work. That said, I think most maintainers know when a new person arrives on the scene. Take a minute to welcome them, say "thank you", and if you're smart, point them at follow up bugs to fix.
"I don't want this change, closing". I've seen a bunch of this recently. Students are often surprised by this, because there was a bug filed, and it looked like the change/feature was wanted. However, I'm not surprised, because most projects don't triage their bugs anymore. It's becoming increasingly difficult to look at the issues in a project and know whether or not you should tackle them. I have sympathy for both sides. I'm trying to teach students to communicate in bugs before they start working. Some do; a lot feel intimidated to expose themselves until they are sure they can fix the bug, so they start with the fix before announcing their presence. Even if you ask in a bug, a lot of projects won't respond to questions, only PRs, so it's a catch-22.
"Thanks, but we need to do this differently". Here you have a PR that "fixes" a bug, and a maintainer that wants it done another way. I would say that this is the expected result of a PR in 95% of cases--you always need review to catch things. However, at this point there are a few scenarios that can happen, not all of them desirable:

review comments in the PR lead to follow-up work by the student in order to create the desired code
the maintainer sends a PR to the student's repo/branch with some changes
the maintainer just does it on their own in a new commit, closes the student's PR

I see all of these happen regularly. Not every open source project is a collaborative project, and I spend a lot of time these days trying to steer students toward and away from certain communities. There's no point spending time on a project that doesn't want your involvement. The projects that do this well take a raw, inexperienced contributor and encourage them to grow, and in so doing, help to invest in the future health of the project: "if you can fix this bug, you can fix these bugs too..."

"This is great! While you're fixing this, can you also fix this other related bug?" This is a great way to draw contributors deeper into a project. Often it means assigning them new bugs (i.e., not adding to the current PR) and expanding their involvement in the code. I've seen this go very well a lot of times across many projects. To be honest, I don't know why more maintainers don't just assign people bugs (I do it all the time). The worst that will happen is that people will say "no," or simply ignore the request. In many cases, though, I find that people step up and enjoy the responsibility and inclusion. What you're really saying is "I think you can do this," and people need to hear that.
"Thank you for this fix! We've made you a collaborator". I'm aware that this approach won't work for every project (e.g., security issues). But I see many projects doing it, and it's a fascinating approach. When someone shows up and is both willing and able to contribute, why not make them part of your core group? This week I saw one of my students not only fix bugs in a big project, bug also get contrib rights and assigned other bugs to review. That's an incredible gesture of confidence and inclusion.
"We really appreciated your contribution, here's a thank-you". When it happens, it's nice, and I saw it happen a few times this week. It can take a few forms, for example, sending people swag. This is beyond the reach of lots of projects, since it has a real-world cost for the swag, shipping, the time of the person co-ordinating it. For projects that can't send a physical thank-you, there are other ways. For example, I see prominent people/projects in the open source world use their social media presence to draw attention to contributor work. It means a lot to have someone you respect in a project take the time to thank you publicly, or to highlight your contribution. These acts build gratitude into your community, and help to encourage people to keep going.
"Why don't we pair program on bugs sometime." A few senior people have reached out to students contributing patches and suggested they work together in real-time. In one case that meant having the student go into their office and meeting in real life. In a few other cases it meant using remote screen sharing apps and video conferencing. What an amazing thing to spend time helping to level-up a committed contributor, and what a sign of confidence for someone who is feeling like an imposter working with so many advanced developers.

Even though it doesn't always go smoothly, I'm still a big believer in having students work on real bugs. Every interaction with the open source community is a learning opportunity, even if all it does is teach you that you don't want to do it again. Thankfully, that's not usually what happens, and even after 15 years of this, I'm still seeing new things I can't predict.

If you're an open source dev or maintainer, I'd encourage you to try submitting some PRs to a project you've never worked on before. You'll be surprised at the hoops you have to go through (they always seem more sane on your own projects), how you feel waiting on a delayed response to your fix, and seeing how you're treated outside your home turf. To keep myself honest and aware of this, I try to contribute fixes to lots of new projects. It's very humbling. Thankfully, if you've lost touch with what it's like to be new, just go fix a bug in a project you don't know using a technology you've never seen before. You'll learn a lot, not least about yourself, and it might affect how you respond to people in your own projects.

Anyway, I'm sure I'll forget I've written this post again and rewrite it next year. Until then.