nik codes

New Contributor? Jump In!

Pluralsight If you like my blog, you’ll love my Pluralsight courses:
Tracking Real World Web Performance
WebPageTest Deep Dive

Update: Keith Dahlby has created, a centralized listing of open source projects that subscribe to the principles outlined in this post. (Note: Some use a different tag.) Be sure to check it out and submit your project to the list.

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:

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:

  1. I’m not sure where to start with contributing to project X.
  2. 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.

– By

Single Post Navigation

22 thoughts on “New Contributor? Jump In!

  1. Love the idea of trying to be inviting. In terms of using tagging, there’s always the possibility of tags being misinterpreted, but if “jump in” works use it.

    In the case of “you take it”, it definitely does not mean we don’t want it. It’s entirely the opposite and overall the reaction has been very positive.

    It might help to read this issue here which clarifies:

    “YOU TAKE IT – These are items that we just don’t have the bandwidth to take but are important and well we’d like YOU to take them. One place we’ll use this is for investigations / prototyping, like figuring out a possible debugging story which @dschenkelman has just done. Generally these would be features that are add ons rather than core but not necessarily. Regardless if it is labled “YOU TAKE IT” then you take it!”

    The philosophy behind it, was “we really want this, and we’d like you to help”. The “Take” was meant to be empowering, “you run with this!’

    • nikmd23 on said:

      That’s awesome Glenn! I know you guys totally have the best of intentions (you and your team members are some of my OSS heros), and I’m glad to hear that it is working well for you.

      I was very careful/deliberate about the label I chose since I was pitching it to become some sort of a widespread standard, but I think the REAL lesson here is that offering a guided path to those who want to help your project is a great idea.

      Keep up the great work!

  2. One barrier to entry I commonly experience is the fear of “breaking something”. In addition to the label, how about giving new contributors a bit of a safety net: First make sure instructions for running tests are very clear, then maybe write a failing test for a new contributor to use as a lighthouse for fixing issues or implementing new features.

    • Have a skype convo with them and help them one on one. You’ll be surprised that they’ll write the docs for you.

    • nikmd23 on said:

      Good points as always Trev.

      While I really do like the idea of providing a broken test in principle, in practice I’d find that to be difficult. I’m going to experiment with it on the next issue that comes through Glimpse that is eligible.

      Your point about helping contributors to feel safe is well taken – and I know there is plenty more that can be done on my projects in that regard.

  3. It can be really daunting contributing to open source. Something as simple as opening an issue, searching twitter and evangelizing goes a long long way. It’s definitely a good idea to add as much information as possible to a newly opened github issue. Essentially communicating “here is where *I* would start in implementing this feature/fixing this bug”. Just pointing some one in the right direction really helps. And don’t be picky about main repo access. If someone submits a good pull request, make them a main contributor. Build that trust.

    • nikmd23 on said:

      Great point Amir!

      When I mentioned the “general guidelines”, these were the kinds of items I was thinking about – but I’ve updated the post to address those directly.


  4. We’ve been using an UpForGrabs tag that roughly matches what you’re talking about here. Our basic guideline has been to put UpForGrabs at the start of the title of any work items we thought would be good for a contributor not on the core team.

    We’ve had feedback from at least one of our contributors saying that he really appreciated it, since he was able to filter the work items to the area he was interested in. Then pick the first UpForGrabs he found.

  5. Echoing what Amir was saying, the best way to engage folks is to engage them 🙂 Meaning don’t just drop tags on items, get out there and proactively invite people to contribute. This can include 1 on 1 convos via skype, IM, emails, etc.

  6. Nik, I think its great that you are doing this call to action! The most important thing is not the tag name (ie whatever works is good!), but the actively engaging with your community to get them involved.

    • I think the list of what the label is and isn’t is the really valuable part of this, and the part that should become more standard. So that in every open source project there is some label that meets the guidelines here.

      In particular avoiding using the label for things that the core team doesn’t want to implement themselves, this is an easy trap to fall into.

  7. Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1355

  8. E Sentosa on said:

    This could become a good system to firewall projects from noobs, incompetents and fiddlers.

    I propose that contributors to OSS projects must be certified according to skill. Something akin to the Microsoft Certified Developer. There would be several levels of certification with only the expert level allowed to make important changes to the project’s code.

    If we advanced developers are to be honest with ourselves, we don’t like code morons messing about with our code bases. This is a great way to keep them out.

    • nikmd23 on said:

      The intent of this is NOT to create a catalog of “prove yourself” challenges.

      Plus, there are already well understood and defined models for moving up the ranks like meritocracy that many OSS projects use.

  9. If you aren’t familiar with OpenHatch, I think you’re in for a deightful surprise:

    At Mozilla, I pioneered the concept of “mentored bugs” ( is a quick talk I gave on the subject), and have created several tools which highlight them for new contributors.

  10. Very nice! Bringing together developers is not only a good idea, it makes working more efficient.

  11. Pingback: Avoid Premature Standardization

  12. Pingback: OSS from the trenches - 7 Tips for Maintainers & Contributors

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: