Stuff everyone knows and forgets anyway
From The_Open_Source_Way
(→Four new virtues to live by) |
(→Four new virtues to live by) |
||
| Line 66: | Line 66: | ||
<!-- Example --> | <!-- Example --> | ||
| - | + | ''Example needed'' | |
== Turn annoying newbies in to instant contributors with the power of To Document == | == Turn annoying newbies in to instant contributors with the power of To Document == | ||
Revision as of 09:22, 8 March 2010
Use this chapter to remind yourself and everyone else.
Embrace failure
Fail spectacularly, and don't forget to take notes.
There is a lot of crowd wisdom at work here. It's basic physics, too -- if you charge ahead and fall on your face, you at least made headway. Like feeling your way around in the dark, each touch, bump, and stub of the toe teaches you more about the environment.
When you drive your processes and technology to the brink of failure, repeatedly, you get very comfortable somewhere most people don't even want to go. You also get to set a new standard for what is comfortable for your community, giving you new room to expand even further.
Example needed
Communities require care and feeding to get started ...
Imagine if you grow a garden and are very ambitious. The first year you overplant and are unwilling to thin out the seedlings. You end up with overcrowded, unhealthy plants.
Implementation needed
By giving good and regular care, your communities ...
Example needed
... And communities need to be left to grow and evolve
Principle needed
Implementation needed
Example needed
Remember what you learned in Kindergarten
- Play nice
- Share
- Don't run with scissors
Seriously, you would be surprised at how many of the most basic rules are broken that our parents and teachers thought they taught us many years ago.
Implementation needed
Example needed
Four new virtues to live by
These four virtues were described by Brian Fitzpatrick and Ben Collins-Sussman in their seminal talk on avoiding poisonous people in communities.
- Politeness
- Respect
- Trust
- Humility
These virtues are implemented in every part of the community. Public and private discussions, all communication channels from in person to IRC, and sometimes even in the nature of the project itself.
Example needed
Turn annoying newbies in to instant contributors with the power of To Document
Make your community culture be to document answers when asking for help. The documenting should be done by the asker.
People offering help should require that the help be documented.
When the asker is a new member of the community (newbie), this is a great way to turn them from an annoyance in to an instant contributor.
Example needed
Take extra extra extra care to have all discussions in the open
Principle needed
Implementation needed
Example needed
Radically visible meetings at all times
Any private interactions, from the hallway to email/irc to phone calls, are a risk to the project. At the minimum, you must be mindful of reporting back the results of direct conversation.
However, this isn't really good enough. A summary of a meeting never shows the reasoned discussion, effectively cutting the community out of the decision making process.
Implementation needed
There is a reason mailing lists and open chat networks are the baseline for all communication in successful open source projects.
Example needed
No decision point is too small to pre-announce to a mailing list
While we can grow trust in the community about technical or other decisions, there are common problem circumstances we can avoid:
- The corporate sponsor and staff are always more suspect, so need to take extra care to share the decision making process
- We cannot guess what is important to contributors, nor why. Presuming they don't care about a decision is a bad idea.
Implementation needed
The method is to take all decisions to the open forums, until people start complaining that a particular class of decisions can happen in another way/place. This is called, "Building trust by proof through annoying transparency."
Example needed
How to let a mailing list run itself
A mailing list is the core of any active community that gets things done. It is the equivalent to having everyone in the same office all the time. The functionality has not been duplicated, replicated, or replaced with any other technology in more than twenty years. News service is arguably better, but mailing lists are ubiquitous.
It's not hard to run a mailing list, in fact the best ones really run themselves. In order to get it to that state:
- Everything must be discussed on the list.
- If you break rule 1, you must make sure that whatever the discussion was, the details and results are published on the list
- This happens often, so it is incumbent that decisions come back to the list from IRC, phone calls, f2f meetings
Take even more care to do all design and decisions in the open
Principle needed
Implementation needed
Example needed
Use version control for your content as well as code - everyone watches the changes
Being able to roll back work encourages people to be bold and innovative. One of the currencies of project work is simply making a change to a codebase or a document as an explanation itself. Changes are self-evident in the commit itself. This is why all changes must be accompanied with a comment or summary that explains the reasons behind the change.
Equally important is that all project members watch these changes. Responding to the changes on a mailing list, bug report, or wiki discussion page keeps the discussion associated with the node of origin.
Example needed
For example, major design decisions need to ...
Choose open tools that can be extended
Don't choose tools just because your small team knows them the best. Be careful of choosing something because you are in a hurry and need something quickly.
When it comes to tools, talk with trusted community leaders about what you should use. Even if you choose something out of step with other community members, you will at least know why you did and be prepared to mitigate risk.
It is risky to choose closed tools that a community cannot easily scale itself.
Implementation needed
Example needed
Make sure everyone has an equal and clear method for access to write-commit to open tools
With version control under code and content, you can open access to more people. For example, don't require people to go through a lengthy process or to "prove" themselves with X number of patches. Give people access to whatever they need to make a difference, even if they don't use the access.
Wikipedia is a prime example here. They use the power of the community size to police bad content changes, rather than limiting the community size behind rules of what it takes to write content changes.
More people want to do good for your project than want to do bad. Don't punish the do-gooders because of the potential evil someone might do.
Tie this together with open content
Principle needed
Don't forget to document code, processes, methods, reasons, etc.
Implementation needed
Example needed
Focus on healthy and open community interaction
Principle needed
Implementation needed
Example needed
Make governance as clear as possible
Principle needed
Implementation needed
Example needed
Use your lawyers well while avoiding too much legalese
Principle needed
Implementation needed
Example needed
Do not let poisonous people bog down the community
Principle needed
Implementation needed
Example needed
Communicators need to communicate - do not let liaisons go silent
Principle needed
Implementation needed
Example needed
Disable poisonous communication
Principle needed
Implementation needed
Example needed
Seek consensus - use voting as a last resort
Most decisions in an open community are not decided by a vote. As in a well-working democracy, decisions are handled by the experts and knowledgeable people who are in charge at the will of the people around them.
Voting is best left for deciding who is in charge and the occasional very contentious issue. Don't you wish it weren't contentious? Wish you could go back and make a consensus?
Example needed
Reassign your benevolent dictators while evolving toward a consensus-based democracy
http://producingoss.com/en/consensus-democracy.html
Principle needed
Implementation needed
Example needed
Do not forget to release early and release often
Principle needed
Implementation needed
Example needed
Release early and release often is for more than just code
Every idea deserves the light of day as early as possible.
A common mistake is to wait to release a document, process, marketing plan, etc. until it is "just right". People who otherwise fully understand how not to do this in code forget when it comes to other parts of a project.
Apply this rule:
- If a piece of information is confidential, keep it private;
- Otherwise, get it out in the public soonest ...
... using techniques such as these ...
- Bounce the idea off the mailing list(s)
- Make a wiki page
- Add to another wiki page]
- File a ticket in a tracking system
- Make a non-coding prototype
- Wireform web page in a wysiwyg editor
- Inkscape or GIMP mock-up/collage
- Bar napkin and pen, scanned or photographed
Example needed
Evolve with the growth of your audience and contributors
It's easy to say, "We designed this for such-and-such a reason for this particular audience." It's not so easy to be the only creator and maintainer, though. If you want to grow beyond just you and your niche group, you have to be willing to accept the influx of new ideas and directions that comes with open collaboration.
Implementation needed
Example needed
