Skip to content

We're part Common Guide

The Common Guide seeks to provide a common base for fast evolving human and planet-centric organisations.

Key Objectives

  • Important new practices, spread quickly and easily, to those seeking to apply them.
  • Help positive new initiatives establish more quickly, from a quality base.
  • Facilitate collaboration between aligned organisations around fast evolving great practices.
  • Shift governance load away from individual organisations into spaces where multiple groups can assist each other
  • Progress contemporary governance practice at a speed that can keep pace with fast changing collective organsing practices
  • Make explicit new organisational tensions that are experience by almost all organisations. If you cant see it you cant go to work on it.
  • Good communication makes its easier to work with the common guide over time.

The Common Guide Way

While it is untrue that there is only one way to do things, the common guide seeks to develop a common set of standards that form a great way of organising for a large number of (especially social) initiatives.

Most small social inititives and non-profit entities are tight on resources.

When challenges arise, a lack of agreed practices (and policies) to deal with tensions, can lead to a significant cost in time and resources for any organisation. While it can be expedient to develop policies that lock things down and centralise power, policies and practices that are finely tuned to encourage learning and development of an organisation are expensive to create.

The common guide seeks to ease this load. In exchange for some reduced self customisation, organisations that implement the common guide gain significantly by adopting policies and practices that have been tested and developed to handle a myriad of situations.

Principals

  • Develop best-practice policies for each type of agreement that suits many organisations of similar type.
  • New policies (and policy changes) go through a predicatable process organisations can rely on.
  • It's easy to contribute good ideas and things that work back to the network.
  • The guide is optimised to support smaller and newly established organisations first.
  • Ejecting is always possible (going your own way), but we all work hard to try and stay.

By design the guides are:

  • Easy to use, read and implement
  • Ongoing changes to the main guide can be easily integrated into individual projects.
  • Individual projects have ways to customise how they want to operate, within their own context.
  • Individual projects are encouraged to contribute back improvements that could benefit everyone.

Definitions

  • We - refers to this organisation, the one hosting this guide.
  • Cycle - refers to a two month period, usually a period of consultation around a newer policy.

How are (new) policies developed?

You are strongly encouraged to create new policies and improve existing policies.

Here's a standard workflow:

  1. Create an early draft of your new policy using your favorite collaboration tool (many like Google Docs).
  2. Run the policy by others, possibly a working group or others who may have good input.
  3. Contribute your policy to the Common Guide as a 'proposal' in Markdown format.
  4. Proposals can stay as just that for some time until there is community support for more formal adoption.
  5. With community support proposals move into 'Under consideration'. At this time it is communicated to the network along with other proposals which are 'under consideration' at that time.
  6. After one cycle without significant objections the proposal moves to 'early testing'. Organisations that have opted into the Early testing program will likley comment on the proposal at this time.
  7. After one cycle without significant objections, the proposal moves into 'for review' and all organisations are informed of which proposals are for review.
  8. After one cycle without significant objections, the proposal moves into 'Released'.

At any stage where signifiant objections arise arond a proposal that proposal can be kept at the stage that it is at or reverted to an earlier stage and reworked.

This is covered in more depth on 'Developing policies'.

Our tech stack

Policies are stored in Common Markdown format, which is a plain text format. Plain text common markdown is cheap to store and highly future proof.

Mkdocs is used to serve up Markdown files into a beautiful website.

For full documentation visit mkdocs.org.

Commands

  • mkdocs new [dir-name] - Create a new project.
  • mkdocs serve - Start the live-reloading docs server.
  • mkdocs build - Build the documentation site.
  • mkdocs -h - Print help message and exit.

Project layout

mkdocs.yml    # The configuration file.
docs/
    index.md  # The documentation homepage.
    ...       # Other markdown pages, images and other files.