Ah, a brand new year. Time to reflect on the past and make resolutions for the future.

At 18F, we’ve been thinking a lot lately about our role within the open source community.

We believe that an open source government is a faster, more efficient government — and we’re deeply committed to working in public and giving back to the larger open source community. In 2015, we released an open source style guide, created dozens of repos, wrote agile contract documents that require open source by the vendor, worked with federal agencies to help release more open source projects, and made it clear that code isn’t the only thing we open source — our guides are also open.

We’d like to concentrate even more on efforts like these in 2016 and continue to strengthen our relationship with the open source community. Maximizing community involvement and reuse is part of our open source policy, and some of our projects have external involvement and reuse, but we could do better at supporting more of this.

By the end of the year, we plan to increase the number of non-employee contributors to our projects, including: contributors with little previous experience with open source, and contributors to documentation, bug filing, and other non-coding work. If we make working on our projects satisfying and useful for newcomers with varied skills, that work will help these projects welcome experienced contributors and developers as well.

To do this, we resolve to:

  • Develop a set of metrics to determine what progress looks like, and how to define and measure that progress.

  • Improve our documentation. We plan to make both existing and new documentation more informative and user-centric, to help people get started working on our projects. As part of this, we want to make sure people know that identifying and reporting documentation issues (and other problems) are substantial ways to help with an open source project. Non-code contributions are valuable, and we can be more explicit about how to contribute after finding a bug or error.

Screen shot of a Slack conversation about adding language to encourage contributions to documentation.

  • Communicate our needs by figuring out better ways to ask for help. We want to be more explicit and vocal about expressing our needs and publicly identifying ways people can help out. It’s important to us that the public can easily contribute to our projects, but it’s not an essential part of getting our work done, so we need to figure out how to fit supporting this into our routines. We don’t routinely test our installation instructions for usability, for instance — but we could specifically ask for external help with that task.

  • To that end, we might use our newsletter as a way to explicitly ask for help. For example, we could include three specific open issues in each newsletter that the public could jump in on.

  • Make it easy to contribute and use the libraries and tools we’ve made. We build a lot of tools that could be really useful for people who work at a variety of organizations. We can surface those tools, write about them more, and identify the parts of our work that are generic. Decoupling them from the applications we developed them for will make it easier for others to reuse them. (h/t Eric Mill)

  • Learn from previous contributors. We’d like to reach out to previous contributors to see what they liked and didn’t like. If they contributed once and never returned, we’d like to find out why. Are there ways we can invite them back? (h/t Maya Benari)

  • Make it worthwhile to contribute. Unpaid work on government projects is public service, requiring time, effort, and skill, and we want to respect that. How can we help people find tasks that help them accomplish their goals, such as practicing a skill or doing something they’re proud of? How can we improve the timeliness of our responses while also getting our core work done? What are meaningful ways to thank people for their work, without creating a lot of overhead and while adhering to government regulations concerning endorsements?

  • Run internal trainings on topics like “Basic open source community management,” “How to handle a well-meaning but not helpful contribution in a friendly and positive way,” and “The philosophical principles and cultural history of free and open source software.” (If we do this, we’ll share our notes publicly.)

  • We want to better advise our new hires on open source community etiquette. For example, you should always explain why you’re closing an issue or pull request — and we shouldn’t expect new hires to know that on their first day. (h/t Leah Bannon)

  • Address user needs. Here’s a specific user need: “I have a lot of experience with open source, and I heard about 18F. Can you explain how I can help? How is 18F different from what I’m used to? What does 18F need most from me? What would it most welcome?” We plan to answer these questions in a future blog post and add it to our style guide. (Other ideas for blog posts: “You’re new to open source: start here.” And then another one: “You’re beyond new to open source: where to start.”)

  • Treat this as an agile, iterative project and report back on what’s working and what we can improve. We’ll be updating you throughout the year on this blog, in our newsletter, and on Twitter.

If you have any suggestions, please let us know in this GitHub issue. We’ll be using it to gather resolutions, track our progress, and respond to feedback. And if your New Year’s resolution is to become more involved with an open source project or the greater community, let us know. We’d love to help you get started.