Sometimes it feels like a battle to gain contributors to our open source software. You'll find plenty of posts on DEV's #contributorswanted tag. We have discussions on "converting users to contributors".
We tout the benefits of Free and Open Source software, but it's hard to reap those benefits when the only ones working on it are the original core developers, and maybe some paid employees.
The trouble is, there are contributors out there who want (or wanted) to contribute to your project, but didn't because of some roadblocks in the process.
Removing those roadblocks will enable you to find, and keep, new contributors on your project.
1: Beware wontfix
Bug reporting is one of the most common ways people first get involved in contributing to your project. How you handle that bug report will make all the difference in whether they stick around.
Here are a few phrases and tags to absolutely eschew from your issue tracking workflow:
wontfix
This is the single worst status you can ever assign to a bug. Even the name "wontfix" is unwelcoming, as it implies that the bug that bothers someone enough for them to report it is of no importance to your team. It's effectively the same as saying "we don't care about you as a user".
This doesn't mean you must act on all bugs, but you can change how you act on them:
- No time or interest? Set it to wishlist priority, and let someone else pick it up.
- Already fixed? Mark as duplicate of another task.
- Is the issue absolutely not feasible for your project? Mark
Closed: Rejected(instead ofwontfix) with an explaination. - Can't duplicate? (See next section.)
Just delete wontfix from your issue tracker now. Please.
Closed: Can't Reproduce
Just because you, your team, and/or your regular contributors cannot reproduce a bug does not mean it's not there! Many showstopper bugs began life as a "can't reproduce" issue that was dismissed by core developers, only for it to manifest in truly terrifying ways months or years later.
If you can't reproduce a bug, leave it open. I recommend creating an Open: Mysterious tag for this purpose. Yes, that may leave a few truly invalid bugs open, but it's better that than to overlook a real bug.
"Problem In Chair, Not In Computer" (PICNIC)
Blaming the user is not okay. Yes, you will have issues that have to be marked as Closed: Rejected because the problem was entirely unrelated to your code, but you don't want to overlook some critical ways to improve:
- Does the UX design need to be improved?
- Does the documentation need to be clarified?
- Does the program need to handle unexpected input better?
If a user can make your program do dumb things, the problem is still, in fact, your program.
2. : Use Closed: Resolved with Caution
You have to have Closed: Resolved in your workflow, no doubt! However, these two considerations are important:
Have a
Closed: Patchedstatus for all those cases where a workaround or hack was used to fix the problem, or where the resolution of the issue is uncertain. This makes it easier to find brittle fixes later.Create a clear pathway for a user to reopen an issue if it becomes "unresolved" again. This is also important for resolving erroneous
Closed: Duplicatetags.
3: Document Your Workflow
When a user wants to contribute to your program for the first time, they will need to know how. Every project's workflow is different, and even the most experienced DevOps ninja may not know how you do things.
Create a single, canonical source for your workflow documentation, be it a part of your project documentation, a page on your website, or a wiki section. Ensure your entire team can edit it, so it stays up to date, as out-of-date workflow documentation is as bad as no documentation.
This documentation should include all relevant instructions and policies for:
- How to report a bug.
- How to request a feature.
- How to setup the necessary development environment.
- How to build the development version of the code.
- How to run tests.
- How to contribute code.
- How to update documentation.
- How to contact core developers.
Then, make the workflow documentation easily discoverable by new and would-be contributors.
This documentation often requires a significant initial time investment, but the returns are well worth it.
4: Mark "Help Wanted" Tasks
Your project should have an up-to-date issue tracker, complete with priorities, assignments, and parent/sub task associations. This is just common sense for your core team's productivity, so I'll assume you have this in place already. (If you don't, go fix that.)
To help encourage open source contributors to join in development, I recommend adding the following tags to your issue tracker, and encouraging their gratuitous use by core developers:
- Help Wanted: Presently unassigned, someone could work on this.
- Low-Hanging Fruit: A good early task for a new contributor.
- Challenging: A difficult problem that a skilled contributor may enjoy taking on.
5: Don't Let Merge Requests Go "Stale"
When a contributor submits a pull request, merge request, Differential Revision, or whatever you call a code contribution, take action! The worst thing you can do is let it sit for months on end, awaiting your review: such inaction makes the contributor feel invisible, unwelcome, and unappreciated. They're likely to leave forever and never return.
6: Say "Thank You"!
Above all, when someone does contribute, make your appreciation known! Just a simple, genuine "thank you" in your responding comment can make all the difference.
This even applies to invalid bugs and rejected merge requests: at least thank the user for taking the time. This makes them feel like their efforts are appreciated, even if their work isn't usable, and they'll be far more likely to learn more and contribute in the future. You never know: their next bug report may be valid, or their next merge request may actually solve that bug that's been plaguing your team for months.
Beyond that, if someone does make an important or meaningful contribution, you should make a bit of grateful noise about it! A celebration emoji, a brief "Thanks Person McContributor!" in the changelog next to their bugfix, a brief Tweet of gratitude...these all make your contributor feel appreciated, and increases the likelihood they'll stay and contribute more.
Summary
Once you've implemented all of these, that's still only the beginning. If you listen to your contributors, you'll be sure to find many more things that can be improved in your open source workflow.
One final note: Be bold in removing barriers for contributors. Unfortunately, you will sometimes have developers who don't want those barriers removed, sometimes because of personal inconvenience, and sometimes because it makes your project feel less like an Exclusive Genius Club. While you should always factor in the well-being and needs of your core developers, don't let anyone dissuade you from making your project more welcoming to open source contributors. Community is what makes open source work!
Top comments (4)
Nicely put, many of my issues have been marked with "wontfix" or "cant reproduce" way too often. For me, the "wontfix" label felt like a "we don't care about you" on more than one occasion, and made me consider searching for alternative software.
In the automotive industry, 'PICNIC' is generally "loose nut behind the wheel"....
As someone who has never had ANY contributors whatsoever to various open source projects I have out there... this is useful. Thanks!
Good job!