In today’s open source world, there are a number of very large communities that have tangible incentives for contributing to projects. Commits that make it into the master branch of Docker can attract tips, and once you become an Active Technical Contributor for OpenStack you get a number of perks, including free entry to the next OpenStack Summit.

For smaller projects based on GitHub, it’s relatively easy to find contributions for a user, or contributors for a project. There are some limitations to this, but the mechanism is there.

But what about everything else?

What about the hours spent in every other part of the software development cycle? The analysis, design, testing, maintenance, and support? What about the marketing? What about the teaching and learning? What about the meetups and the conferences, and all the organization that goes behind making those things happen? What about all the little things: the brain storms, the ideas, the conversations?

Back in February, Leslie Hawthorn wrote a missive about acknowledging these kind of contributions, and named it Let’s All Build Hat Racks, or #LABHR. She recalls a conversation she had with Deb Nicolson where they were discussing their shared membership of the Sahana Software Foundation Advisory Council, when Deb said:

No, this is great. This gives me one of those places to hang your hat. You know, something you can list on your LinkedIn profile instead of just a project that you work on for free because you love it. But no one really knows about it or notices.

Leslie describes a list of five steps to acknowledge someone’s work:

• Write a thank you, even if it’s just bullet points
• Send it to them
• Additionally, publicly acknowledge them on something like LinkedIn
• Furthermore, use the #LABHR hashtag to publicly thank them in social media streams
• Ultra-mega bonus points for doing this for someone not like you, and the unsung heroes.

I’ve been spreading this message about by doing a series lightning talks at various different meetups for multiple communities. I’ve even had the opportunity to present full-length versions discussing the specifics of non-code contributions in detail. I’ve met some amazing people along the way who have helped me expand on my presentations as they share how they are trying to get people in their community acknowledged.

But what I’ve seen is that a lot of information about who is contributing is stuck inside the systems we use. Mailing lists, emails, and documentation can be easily found, but systems like GitHub do not show as much information as they could.

For a project that exists solely through GitHub (that is, it does all it’s bug tracking, issue comments, feature requests, development, testing, deployment, etc. via the site) it should be possible to access a comprehensive list of code contributors and non-code contributors. A project page does show a count of contributors, but for a project with more than 100 participants clicking into the Contributor graph does not present a complete list of even the code contributors. It ranks contributors based on the amount of lines of code changed, and those with smaller contribution sets can fall off the list.

Fortunately, there is a publicly accessible GitHub API that exposes contribution and participation information. Using this, I’ve created an application called octohat—named after the combination of the GitHub mascot Octocat and hat racks—that takes a GitHub project name and returns a full list of contributors, both code and non-code. A non-code contribution is defined as any action within an Issue, Pull Request, or Code Comment, including any comments and discussions around the project, and any Pull Request code that hasn’t been merged into master.

Paul Fenwick discusses the psychology of how the “Foot in the Door” technique can be used to encourage further contributions in his OSCON Keynote “Fear, Uncertainty, and Dopamine”. By acknowledging all the little things, both code and non-code contributions alike, there is a significantly increased chance of a contributor continuing to help, and in bigger ways. This is an incredibly effective way to increase a community.

By using tools like octohat, you can find who in your project is helping without committing code and you can then use this information to thank them profusely for all their hard work. And maybe they might help out more in the future.

Most Open
Month

A collection of articles highlighting first-time Opensource.com contributors.