# If you build it ... : Thoughts on community growth

*Purpose*: Community will not magically show up around your open source project. You have to work for it. Here are some of the intentional steps that you can take to curate a user and developer community.

## Invite

You may believe that because your project is open source, under an OSI approved license, and on GitHub, that people will just know that they are welcome to participate. But people like to be asked, explicitly, to participate. Most first-time developers assume that there’s an “in crowd”, and that they’re not part of it. Making a first contribution - even commenting on a proposed feature - can be intimidating.

Ask for contributions. Be specific about what kind of contributions are welcome. Be sure to include non-code contributions, such as design, documentation, promotional activities, events, bug reports, feature requests, end-user support, and so on.

## Document

Don’t assume that people know how to contribute to your project. Clearly document where the source lives, and how people should approach the project for the best chance of success. Link to the source, and the various communication channels, from the main navigation of your website. Don’t make anyone go hunting.

## Include

Have a public forum for all discussion. Mailing lists are traditionally the way to do this, but any place where conversations are public, and permanently archived, is fine.

Have all conversations in public, whenever possible.

If conversations about project direction do happen in private - as they inevitably will, take these back to the public forum for the community to see. This ensures that the entire community has the opportunity to comment on, or participate in, decisions about the future of the project, rather than perceiving that the real decisions are being made in secret.

Decisions that happen in private are a statement that the community isn’t a first-class citizen in the decision process. This, in turn, tells potential new community members that they are not ever going to be decision makers in this community.

Discussions of personnel (ie, who to add to the project, or interpersonal conflicts) are the exception to this, and should be kept off of the public forum. As your community grows, consider creating a private discussion space where project “insiders” can have these important, but sensitive, conversations.

## Welcome

Every time someone new shows up, whether on a mailing list, Slack channel, bug report, or pull request, welcome them. Do this individually, by name. This doesn’t have to be anything elaborate. Just a quick note to say you noticed they dropped by.

Find out why they’re there - how they are using the project, and in what ways they are happy and unhappy about the current state of the project. Find out what they bring to the project, and see how they want to get involved.

Yes, this is time consuming. However, it is an investment in the future of your project. And, eventually, you’ll be able to delegate this task to one of the people that joins your community as a result of the personal attention.

## Respond

Respond to every user interaction, or potential contributor interaction.

Questions on the user forum should be answered promptly. If you don’t have an answer, say so. Don’t just leave it hanging.

Leaving a pull request without any kind of response for more than a week or so sends two messages. One, it tells that contributor that their contribution was beneath your notice. Two, it tells all future contributors not to waste their time. This does not mean that you need to accept all contributions. Rather, that you should acknowledge the contribution, and set a reasonable expectation around when you will review, accept, or reject it.

## Thank

When a contribution of any kind is accepted, acknowledge it publicly. Do this in your newsletter, social media, or release notes. Acknowledge the contributor by name, and be sure that they notice. If you’re using GitHub, this can be automated, so there’s no excuse not to do this.

## Delegate

When a contributor shows interest in some aspect of the project - whether it is a part of the code, or the documentation, or welcoming new contributors - offer them that role. Then, be present to support them if they need help, but otherwise let them take that task and run with it.

## Trust

Trust the new community members to act in the best interests of the project, even when they don’t do things exactly as you would have done. Innovation comes from allowing a wide variety of people to lead in different ways. Sustainability comes from allowing more people to take ownership of the project, and, they, in turn, becoming responsible for all of the above steps.