Understand your community’s scope

A wooden fence at the edge of a horse pasture shrouded in fog.

Emily Omier recently wrote a post with the provocative title “Do you really want more inclusive communities?” In it, she argues that there’s value in excluding people for whom the project is not a good fit. Not every project is for everyone, and that’s okay. When done right, exclusion is a win for everyone.

We have struggled with sometimes in Fedora. Of course we want Fedora Linux to be for everyone! But also, we’re focused on advancing the state of Linux distros. This means things like long-term support and 32-bit x86 architecture aren’t a good fit for our community’s work. This work is important, but that doesn’t mean it fits our community.

Fedora is not alone here by any means. I often talk to project maintainers who say things like “I had a pull request that was perfectly fine, but it took the project in a direction we didn’t want to go.” It’s appropriate to close those pull requests, but it makes life less fun for everyone. You can avoid the unpleasantness by communicating in advance.

In order to communicate what sorts of contributions are welcome, you must first understand the scope of the community’s work. You can always add new features to software, the question is should you? Understanding your community’s scope helps you answer that question. Of course, after you understand it, you have to make sure there’s a shared understanding.

Once the core team agrees on the scope of the project, make sure it’s clear in the project documentation. While it’s good to reject contributions that are out of line with your goals, it’s better that the contribution never gets written. As Emily said, “make it easy for people to self-select in or out.” If they know the contribution they had in mind is out of scope, they’ll either go contribute elsewhere, or they’ll find an in-scope contribution to make. Both of these are good outcomes.

Although you want to be friendly and inclusive, it’s important to accept that your project is not for everyone. It’s hard to say “we want to be for everyone” and continue on to “who is also interested in this work.”

This post’s featured photo by Jan Canty on Unsplash.

Ben formerly led open source messaging at Docker and was the Fedora Program Manager. He is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.