_posts/2016-01-08-18f-new-years-resolution-be-even-more-open.md
---
title: "18F's New Year's resolution: Be even more open"
date: 2016-01-07
authors:
- melody
- britta-gustafson
tags:
- open source
- how we work
excerpt: "We've been thinking a lot lately about our role within the open source community, and it's our 2016 resolution 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."
description: "We've been thinking a lot lately about our role within the open source community, and it's our 2016 resolution 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."
image: /assets/blog/open-source/documentation.jpg
hero: false
---
Ah, a brand new year. Time to [reflect on the
past](https://18f.gsa.gov/2015/12/23/looking-back-2015-our-own-words/)
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](https://18f.gsa.gov/2015/12/09/an-open-source-government-is-a-faster-more-efficient-government/)
— and we're deeply committed to [working in
public](https://18f.gsa.gov/2014/07/31/working-in-public-from-day-1/)
and [giving
back](https://18f.gsa.gov/2015/06/03/giving-back-to-open-source/) to
the larger open source community. In 2015, we released an [open source
style
guide](https://18f.gsa.gov/2015/07/29/style-guide-for-open-source-documentation/),
created [dozens of repos](https://github.com/18F), 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
](https://pages.18f.gov/guides/)[guides](https://pages.18f.gov/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](https://github.com/18F/open-source-policy/blob/master/policy.md#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](https://github.com/18F/18f.gsa.gov/issues/1445):
- **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
**m**<span id="kix.ciz0zkic4beu" class="anchor"></span>**ake 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.
- **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](https://18f.gsa.gov/#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**](https://18f.gsa.gov/team/eric/))
- **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**](https://18f.gsa.gov/team/maya/))
- **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**](https://18f.gsa.gov/team/leah/))
- **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](https://18f.gsa.gov/#newsletter), and on
[Twitter](https://twitter.com/18F/).
If you have any suggestions, please [let us
know in this GitHub
issue](https://github.com/18F/18f.gsa.gov/issues/1445). 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.