Stuff everyone knows and forgets anyway

From The_Open_Source_Way

Revision as of 00:27, 1 February 2010 by Quaid (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Use this chapter to remind yourself and everyone else.

Contents

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

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:

  1. Everything must be discussed on the list.
  2. 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

Personal tools