New Contributor? Jump In!
Coming together is a beginning; keeping together is progress; working together is success. – Henry Ford
As Ford said many years ago, “working together is success”. In the two years I’ve been heavily involved with open source software, I’ve been lucky enough to see lots of success. Unfortunately, I’ve seen even more stalled beginnings and stunted progress, and I’ve been wanting to try to do something about it. So earlier this week I tweeted an idea I’ve had for a couple of months now:
There should be a standardized OSS proj issue label that means “this is low hanging fruit perfect for new contributors”
— Nik Molnar (@nikmd23) May 8, 2013
The idea for a standardized issue label for open source projects came from the two pieces of feedback I consistently hear from would-be contributors:
I’m not sure where to start with contributing to project X.
I’ll try to pick off a bug on the backlog as soon as I’ve acquainted myself enough with the codebase to provide value.
Of course, what really ends up happening is that the would-be contributor gets bogged down in ramp up and orientation activities and seldom hits their stride in actually providing value back to the project. More often than not, we don’t get to work together. We don’t succeed.
The Pitch
Even though there are general guidelines for getting started with open source projects (such as submitting a detailed bug report, enhancing the documentation or answering a question on Stackoverflow), and GitHub specifically supports contributor guidelines on all projects, I still find developers having problems diving into new OSS projects. The challenge is, fixing bugs usually requires intimate knowledge of the project’s code base and expected behavior, and implementing an entirely new feature may require more time and effort than the contributor has to give.
Thus, enter the “jump in” issue tag/label. The “jump In” label is meant to help developers new to a given open source project provide value back to the project quickly and to help them get acquainted with the community and code base.
Jump in items would typically:
- Take no longer than a few nights worth of work to implement.
- Be relatively standalone, not requiring tight integration with other in development backlog items.
- Be well described with pointers to help the implementer.
They are not:
- Items that the “core team” does not want to implement themselves.
- Items that are specifically set aside for junior/novice developers.
- Used as a hazing activity for “rookies”.
- Designed to be fizzbuzz tests.
There was quite a conversation around what the actual label to use would be. Kelly Sommers had a great suggestion with “New? Try This!” which ultimately was decided against due to its use of punctuation and the compatibility problems those characters could cause with some tooling. Many others suggested various labels, from the funny to the insensitive, and even pointed out two instances of “prior art”.
Scriptcs leverages a “you take it” label to identify items that make sense for new contributors. I found “you take it” to be a bit unwelcoming and passive/aggressive. I personally read it as “We the core team don’t want to do this, so you take it”. I know the guys behind that project don’t mean it that way – but lacking any context that it how I perceived it.
The other instance was KDE, which has been using a “Junior Jobs” label for almost 10 years. I found that to be completely inspiring. Several similar labels were suggested for this effort during the online brainstorming session, but were dismissed due to their connotation of work suitable for junior/inexperienced developers. While I’d love to adopt a preexisting “standard”, my fear of the junior designation conflicts with my desire to make all developers feel welcome to our community; so I’ve decided to go a different way.
So is “jump In” perfect? Most assuredly not, but it is a great starting place. It is action oriented, self descriptive, and had plenty of fans on Twitter. Of course the more its usage spreads across OSS projects the easier it will be for new contributors to show up and understand where they can and should jump in.
We’ve already got a jump in list going for Glimpse and we’ll be updating our CONTRIBUTING.MD to point to it, as well as our documentation, as great ways for newcomers to get involved.
The Call To Action
Label a few issues for your OSS project and link to the list here in the comments.
See a project you’d like to help out with but aren’t sure how? Ask the maintainers if they could provide a jump in list.
I’d love to see this spread into wide adoption, and for OSS projects of all sizes to find success in working with contributors and never again experience stalled beginnings or stunted progress.
