I'm doing some marking today, and one of the labs I gave my students was to contribute a pull request to a node.js module project on GitHub. None of the students knew node.js or had used GitHub before, so I wrote extensively about it here, with detailed instructions to show them how to do it.
A month has passed, so I went back to look at what happened to these PRs. I was interested to see what actually happens in the node community when you throw total beginners at it. I wanted to understand how contributions and contributors are received, how maintainers respond, how long it takes to get a response, etc.
Here are some examples of the PRs the students did, listed by module name:
- request
- gulp-util
- dat-next
- inherits
- nodeunit
- mysql
- lodash
- node-glob
- elasticsearch-js
- angular-ui-boostrap
- angular-translate
- concat-stream
- customize-write-files
- morgan
- facebookarchive/esprima
- webpack-dev-middleware
- vscode-angular2-snippets
- node-restify
- browser-logos
- node-supervisor
- nodejs-dashboard
- queried
- angular
- node-semver
- prompt
- babylon
- vinyl-fs
- pug
- grunt
- bluebird
- gulp
I left it up to the students which projects to work on, and as you can see, lots of popular node modules have minor issues. So my first conclusion is that it is indeed possible to find lots of first contribution opportunities by focusing on package.json warnings.
Now some numbers:
- PRs merged: 32%
- PRs closed or rejected: 43%
- PRs still open 1 month later: 25%
I found this fascinating. First, I was surprised that only 1/3rd of the students could get their code landed. When I made this lab, I thought the changes were non-controversial and easy wins. Second, I was interested that so many projects just ignored PRs or let them languish. Lots of people in the node community that I hear talking loudly about welcoming newcomers and helping people get started in open source seemed to be absent when it came to responding to real PRs.
If we dig into some of the PRs, there are other interesting things to unpack. I was pleased to see a bunch of maintainers and reviewers taking the time to not only merge the code, but also respond on a human level, saying things like:
"Nice, thank you very much"
"+1, good catch!"
"Congrats on opening your first pull request on GitHub!"
An equal number of people just merged without comment. It's ridiculously easy to add a short message when you merge a PR, and people would do well to add more love to their use of GitHub. It was clear from student blog posts afterward how much a simple "thank" you could do, for example, Maya wrote a great post on her experience:
I GOT A THANK YOU!
This has dispelled one of my worries that the moment I start contributing online, I would immediately be shut down. Obviously this is the reality working and contributing to projects online.
But that first friendly interaction from a stranger whose repo I contributed to was a great welcome to the Open Source world.
I saw a lot of the opposite, though: "Our code is fine, closing". I couldn't believe the number of reviewers who got lost in pedantic arguments about whether something is right or wrong, what the point of things like keywords are, etc.
A great example of this is the repository field, which should probably be a full URL even though you can use syntax like GitHub shorthand like npm/npm. I was surprised how many maintainers completely missed the chance to engage a new contributor and take a suggested change (even if not 100% necessary), or went beyond this and took the opportunity to lecture on why the change was wrong. In my experience, needing to be right often leads to being alone. If you're going to close a PR in your project, consider inviting the contributor to work on another similar issue, or help them craft a new version of the fix that could work. Dropping them along with the PR is shortsighted.
As you would guess, I saw lots of formatting mistakes with indenting, tabs vs. spaces, etc. Most students are on Windows, haven't contributed to any open source before, and don't know you're not supposed to use tabs, need 2-spaces, 4-spaces, etc. Some reviewers were patient with this, and helped walk people through fixing things; others weren't. If you see people making indentation errors, it's almost surely a sign that you're dealing with someone new, someone who could use extra attention or mentoring. Maintainers would do well to tailor their feedback based on the presence of such mistakes, which are a great indicator of the experience level of the contributor. No one is putting tabs in their code to annoy you! It's a lack of experience.
A bunch of students ran into bots wanting CLAs signed (13% of PRs), which stopped a lot of students from going further. "Why am I being asked to sign something?" Only 1 of my students signed a CLA. It definitely ended a lot of contributions.
It wasn't all negative, though, and I was encouraged by the behaviour of a few maintainers/reviewers, and wanted to call it out. While others in the community missed the chance to be welcoming and helpful, these people seemed to get it, and I was thankful my students encountered them:
dougwilson who thanked the student for the effort and helped dig into the upstream problem of the package.json validator giving incorrect info on repository fields not being URLs. Open source is at its best when it tries to connect people to solutions beyond the boundaries of particular projects/repos.
danez for responding quickly and being thankful.
DonutEspresso for being positive, and also taking the time to let the student know that they have work to do here (humility).
Overall I think that the experience was useful for the students, because it was real. Even when it didn't work out perfectly, students got to build their skills and confidence. I think Margaryta put it well in her blog post about the experience:
"I was afraid even to try...(But after doing it) I am not afraid to make a contribution to the Open Source community."
I also think the node community could do more to prepare itself to engage with first time contributors. Open source is about code, open source is about process. But open source is also, and always about people. As experienced open source contributors, we tend to forget what it's like to begin, and get lost in the work itself, leaning on unwritten process and practices. All of us need to take more time to help new people we encounter in issues and pull requests. Small moments of kindness, helpfulness, and encouragement go a long way. We should be putting as much time (or more!) into being kind in issues/PRS as we do into fixing linting errors and increasing code coverage.