Up until now, I’ve been talking about “community” in mostly abstract terms. Since all communities are collections of people, they all have a large set of challenges in common. It is important to keep in mind that, as communities grow past a certain size, they tend to organize themselves in one of three distinct ways. I wanted to take the time to define the terms I use because I will probably refer back to these terms in future articles.
The names I’ve given to the three ways of organizing communities are:
When taking a look at these different organizational structures, it’s important to determine:
- Who sets the ground rules?
- Who has the primary responsibility of enforcement?
- Who is granted which enforcement powers?
A simple community is what most people are talking about when they talk about an online group, message board, chat channel, or other normal-size gathering of people online. There are the community leaders (typically the people who founded the group), and there’s everyone else. In this type of organization, it’s the community leaders who both set the ground rules and are responsible for enforcing them.
If you run into a problem in a simple community, there’s only one group to bring it to: the community’s leaders.
- The vast majority of message boards
- A single IRC channel or small- to mid-sized Slack team
This style of organizing communities is typically used when there is a service that allows people to create their own content or resources underneath the umbrella of the service itself. People will gather into groups around the content, person, resource, or other project, but it is up to the person or people who created the gathering point to set rules around their community and enforce them. Meanwhile, the people who created the service itself are mainly concerned with the health of the service itself rather than any individual community on the service.
Because of this two-level system, when there is a problem it is typically a leader in an individual community that addresses it. The services of these types are generally designed to give a lot of enforcement power to the leaders of the individual communities and expect them to wield it. Only when something threatens the service itself does the central authority get involved.
GitHub is an example of a confederacy of communities. Each GitHub repository or organization is a simple community. The owners of that repo or organization have the right and responsibility to set their own policies, processes, procedures, and codes of conduct or other social norms to make things work smoothly, so long as the GitHub Terms of Service and Community Guidelines are observed. GitHub, the company, is responsible for enforcing the Terms of Service, the Community Guidelines, for mediating disputes that cross the boundaries between communities, and for keeping the service itself healthy and running.
If you run into a problem in a confederacy, you first are expected to report the problem to the individual community’s leaders. Only if that fails does one typically appeal to the central authority.
A federation of communities looks like a simple community at first glance because there is one central authority and then everyone else. However, when you look closely there are groups, cliques, dividing lines, or gathering points, and there are often some minimal powers granted within those areas to certain people or leaders. Facebook has Facebook groups which people can be allowed into or removed from. Twitter has verified accounts that have advanced powers that normal accounts don’t.
There are two major differences between a confederacy and a federation. In a confederacy there are sharp dividing lines between communities, and the individual communities are encouraged to set their own rules and enforce them. In a federation, the lines between groups is very blurry, and the power to set and enforce rules are almost exclusively held onto by the central service.
If you run into a problem in a federation, there’s often very little anyone can do about it other than seeking help from the central authority itself, even when dealing exclusively with a smaller group using the service.
I’ve found these distinctions very helpful in examining some incidents that I’ve heard of occurring around the greater Internet. They’ve assisted me in determining which situations are going to be more applicable or more likely to occur in the communities I’ve managed. I hope that I’ll be able to refer back to these in future articles where we dive deep into some challenges that are specific to one type of community or another.