Community Toolbox
Notes from Culture & Empire, Peter Hitjens
Without a clear mission, an on-line community won't grow. A group of friends who start a project may agree what they want to do, yet anyone new coming on board has to guess what they had in mind. People will guess wrong, and will change their minds over time. This leads to confusion, disagreement, and disappointment as people find that their hard work was wasted because the rest of the group headed off in a different direction.
TIP: A good mission starts with "sane" and steps into "you cannot be serious!".
TIP: Change your mission as your community matures. At first, you will want to attract idealists and pioneers, then the leading edge, and then early adopters, the mass market, and finally, the late adopters. Each of these groups wants different things. Understand that, and tune your mission to suit.
To formulate a good mission, think in terms of the single main problem our project/community is solving.
To-Do:
- Think about why are we building this community for open-source? Which problem are we going to address to formulate a solution (which is us, StreetByters, and our seed project to test if it is a real problem).
- After stating the mission. Define "success". This can help in keeping the focus over the years. It also makes it easy to measure our success.
Once we have agreed on our mission, we need to test this against the real world.
We have to make a minimal yet plausible answer to the problem we identified, call this "seed". With the seed, we have two main goals:
- 1.Start to collect idealists and pioneers into a community. (Which we have done partly)
- 2.Prove or disprove our mission.
Projects fail for many reasons. A major cause of failure is that the original idea or mission wasn't as amazing as people felt. Failure is fine, even excellent, unless it costs years of your life. Making a seed and showing it to a few people isn't enough because most people won't be really critical. They feel it's hurtful.
If people like it and feel challenged by it, get involved little by little. We want to be working on our seed in public view, and talking about your new project, from the very start. This means people can make suggestions, and feel involved, from day one.
Never turn away anyone who wants to contribute. Pull people in, even if their contributions are poor or incorrect. The community is more important than the product.
TIP: If people are not joining in our seed, don't continue working on it. Instead, discover what's stopping them from joining and fix that. Start again from scratch if necessary. Don't prematurely kill seeds; it can take time for people to appreciate what you are trying to do.
To-Do:
- Build a "seed" product in public view and encourage others to get involved from thestart. If people do get involved, encourage them rapidly. If they don't, treat that as a sign yourmission may be wrong. Use the seed product to build the community.
- Ask people to invest even a few hours of their time in making it better, and if they don't say "yes," you know how they really feel.
- Determine a "collaboration platform" to work with people who agreed to help. (i.e. Github)
Transparency is very important to get rapid criticism of ideas and work in progress. If a few people in a team go off and work on something together for some time -- a few days seems harmless, a few weeks is not -- then what they make can be presented to the group as a fait accompli. When one person does that, the group can just shrug it off. When two or more people do that, it becomes much harder to back off from bad ideas. Secrecy and incompetence seem bound together. Groups that work in secret do not achieve wisdom.
To-Do:
- Think about a transparent decision taking mechanism.
A group needs a lot of agreements for working together. Perhaps the most important one for any creative community is remixability. The following question will arise: "What is the copyright license on this work, and how does that affect the community?"
Broadly, there are three types of agreement for copyright:
- 1.A "locked down" license that does not allow remixing. This is the old way of working, and still the dominant model in for-profit work.
- 2.A "free to take" license that allows one-way remixing. (Like MIT)
- 3.A "share-alike" license that enforces two-way remixing. (Like GPL)
To-Do:
- Decide licensing type. Think about pros and cons.
Good protocols let strangers collaborate without up-front agreement. They resolve destructive conflict, and turn it into valuable competition. The insight that lets anarchists join wise crowds as happily as anyone is that the crowd can develop its own rules. Typically, these rules govern remixing, identity, ranking, and so on. No matter what their form, good rules are simple, clear, explicitly written down, and agreed upon by all.
TIP: Write your rules very carefully, starting with choosing a license for content, and measure how much they help people. Change them over time as you need to.
To-Do:
- Write an rule-book. Some rules must be established very early (such as licenses for contributions). Others can be developed when needed (such as processes for resolving conflicts). Complex, pointless, or unwritten rules are toxic to groups. They create space for argument, confuse people, and make it expensive to join or leave a group.
Without authority, rules have no strength. The community founders and main contributors are its de facto authority. If they abuse this position, they lose contributors and the project dies or gets forked under different rules. Authority needs to be scalable (that is, work with any size of group) and transferable as the group grows and changes over time.
While we need authority to build a flat playing field (NO HIERARCHY), many groups use authority as a way of controlling members, keeping them in the group, and making them conform.
TIP: Promote the most active contributors into positions of authority, and do this rapidly. You have a short window for promoting new contributors before they disappear to other projects.
We have to be a part of our community, and we must follow our own rules. If we find yourself breaking, or wanting to break, our own rules, they are faulty and need fixing.
Membership must be a badge to collect, not an identity.
TIP: To measure how tribal a group is, just start a competing project. If the response is negative and emotional, the group is tribal. A sane group will applaud its new competitors. :)
To-Do:
- Think and discuss about how are we going to introduce ourselves to people. (Personally and with the name of Community)
Some people like to be told what to do. The best contributors and teams choose their own tasks. A successful community recognizes problems and organizes itself to solve them. Further, it does that faster and more accurately than any top-down management structure. This means the community should accept contributions in any area, without limit.
Top-down task assignment is an anti-pattern with many weaknesses. It makes it impossible for individuals to act when they recognize new problems. It creates fiefdoms where work and the necessary resources belong to specific people. It creates long communication chains that can't react rapidly. It requires layers of managers just to connect decision-makers with those doing the work.
TIP: Write rules to raise the quality of work and to explicitly allow anyone to work on anything they find interesting.
TIP: Choose the people you work with, and let them choose the people they work with. Power structures are like liquid cement; they harden and stop people from moving around as they need to. Any structure defends itself.
A diverse group has conflicting opinions, and a healthy group has to embrace and digest these conflicts. Critics, iconoclasts, vandals, spies, and trolls keep a group on its toes. They can be a catalyst for others to stay involved.
TIP: When there is an interesting problem, try to get multiple teams competing to solve it. Competition is great fun and can produce better answers than monopolized problems. You can even explicitly create competitions with prizes for the best solutions.
It's all very well to try to turn conflict into competition. However, we also need to provide teams with a way to know how well they are doing. Tools, like GitHub, show us precisely how many people are watching or have "starred" or "forked" a particular project (revealing different levels of interest and commitment).
If a group is geographically concentrated, it becomes homogenized, where all members get pretty much the same inputs and triggers. Close proximity also lets a minority dominate the mindset of the group and reject contrary ideas.
It can be hard to move away from the old discuss-then-execute model of working together. Certainly it's easier if we are building groups from scratch (which is our case) than if we are trying to change existing groups.
TIP: Do we need meetings to get work done as a group? This is a sign that we have deeper problems in how we work together. We are excluding people who are not physically close by.
TIP: Make it absolutely simple for logged-in users to create new projects. If they're in a shared space, we may need tools to purge junk and abandoned projects.
To-Do:
- As community grows around seed project, provide tools to create new projects that suits our conventions and structure easily from scratch.
As a community grows larger, it can become harder to navigate. If we make a single, ever-growing project, this becomes more and more complex over time, consisting mainly of special cases. Think of a medieval castle.
Complexity turns people away because it's so difficult to learn. The solution is to use very regular structures that we can learn once and then predict many times. Not any structure will do. We seem bad at learning structures deeper than three or four levels. However, we're happy to explore very wide structures with thousands or millions of boxes if those boxes correspond to separate units of work, or projects. Think of a city.
TIP: Design your community as a searchable city of projects, where anyone can start a new project, projects represent perhaps a dozen people's work, and all have familiar structure, as much as possible.
Think of our community as a video game with levels that become increasingly difficult, and have bigger and bigger payoffs. People will play "up to their level." If we can do this right, we attract the most people. If you do this wrong, we'll bore experts by making it too easy, or we'll turn off others by making it too hard to get started.
TIP: Use classic training tools -- presentations, videos, answers to frequently asked questions (FAQs), tutorials -- to get people started. It helps if you are part of the community so you can see what kinds of questions people ask when they start.
It's tempting to try to provoke people into joining a group by being aggressive. After all, many people enjoy a good heated argument, especially when they feel they're right. Some groups thrive on being quite hostile and negative towards other groups, particularly if there is some history involved. The tone we set as founders will last a long time. If we promote our community by attacking competitors, we will attract people of a certain mindset, and the culture will spread. Sooner or later, the negativity will turn inwards and can be very damaging for the community.
A positive culture is more tolerant and reduces emotions and arguments. It also makes it easier to experiment, make mistakes, and self-criticize, and all these help a community think through difficult problems.
TIP: When you talk about people, products, or organizations, be polite and stay balanced. When you promote your product or community, talk about the problems you solve, not how you are better than your competitors.
TIP: Welcome everyone, and only intervene when there are irredeemable troublemakers. It's a small minority that really can't find a place in an open, diverse community. You can ask such people to leave and, if necessary, ban them.
We make a racing car faster by removing weight, not by adding power. We can make our community lighter, faster, and more agile by being dogmatically minimalist about the work we do. Though it sounds lazy, it's often harder to not do something that seems fun than to just go ahead and do it.
The general rule is do the absolute minimum that probably works. Then invest more only as people start to use our work and complain. Never invest more than the absolute minimum we need to get a "bite" from users. This applies to our seed product as well as every change we make. User feedback -- more than our own vision -- is the best guide for where to make further investments.
TIP: Perfection precludes participation. Releasing buggy, half-finished work is an excellent way to provoke people into contributing. Though it can be hard for big egos to accept, flaws are usually more attractive to contributors than perfection, which attracts users.
Last modified 2yr ago