P:Documentation/Naming Conventions

From Open Source Ecology
Jump to: navigation, search

Intro

Name things in the wiki so people can find it. For example:

  • Newcomers - see how things relate to each other
  • Contributors - know how to add new topics to existing ones
  • Upkeep - manage complexity by prioritizing upkeep of some parts of the wiki over others and manage team energy

The documentation system is as follows:


There are 7 general "Categories" that everything fits into:

  • Community - the people who make Open Source Ecology AND any work that develops this community
  • Management - the process for how you do things
  • Marketing - how to explain what we do (strategy, positioning)
  • Traction - how we reach people and get them to buy/do (execution)
  • Product - things we build
  • Finance - how we have enough money to keep going
  • Praxis - the philosophy and practice of OSE ideals

We specify "Major Pages" for each Category:

  • Community (supporters, entrepreneurs, researchers, onboarding)
  • Management (disciplined entrepreneurship, holacracy, meetings, metrics)
  • Finance (budget)
  • product (anything in the Global Village Construction Set)
  • Traction (physical advertising, direct sales)
  • Marketing (any materials or guidelines that support traction)
  • Praxis (OSE Spec)

When we name create new "Topics," name the Topic based on how it relates to a Major Page:

  • P: this is a process. Is it something that people do? This includes surveys, onboarding, and presentations.
  • O: this is an object. Is it a thing or something that a process uses or produces?
  • Nmap: this is a narrative that maps interactions between processes AND objects. Is it a complex idea or a statement on "what could be?" (like the GVCS)
  • Nfolk: this is a narrative for people and orgs. Is this about some person or org?
  • Nview: this is a narrative that captures reflections on things that exist. Is it an opinion or recommendation?

To create the full topic name, use these grammatical conventions:

  • [Category Type Abbreviation]:[Major Page]/[Topic Page]::[Status or State of the Topic] X [Like a Date] X [Place] X [Or Particular Perspective]

Here's some examples:


The idea is to use naming conventions based on BEMIT, a CSS naming convention.

As applied to this wiki, I recommend these naming conventions:

  • 5 types of topics:
  • process
  • object
  • narrative-folk
  • narrative-map
  • narrative-view
  • abbreviate these types so that the first word is just a letter: P, O, Nfolk, Nmap, Nview
  • 3 types of relationships within naming conventions: parent&child, topicXtopic, and topic=>modifier
  • Titlecase topics, such as: "P:Documentation Standards" or "Nmap:Global Village Construction Set"
  • Pre-pend topics with the topic type, such as "P:Documentation Standards" or "Nmap:Global Village Construction Set" (follows existing File:xyz.pdf convention)
  • Nest child topics using the url / convention, such as "O:3D Printer/Frame"
  • String neighboring topics using the X convention, such as "Nmap:Disciplined Entrepreneurship X Priorities X Critical Path X Traction"
  • Always nest views as a child of a topic, such as "Nview:Disciplined Entrepreneurship X Priorities X Critical Path X Traction/Pro-inquiry"
  • Only ever include 1 topic type, which always refers to the most nested child topic, so compare these two: "Nview:Disciplined Entrepreneurship X Priorities X Critical Path X Traction/Pro-inquiry" and "Nmap:Disciplined Entrepreneurship X Priorities X Critical Path X Traction"
  • Add modifiers using double-colons, such as "O:3D Printer/Frame::PVC Pipe"
  • For objects with multiple modifiers, use the topic X topic convention, such as "O:3D Printer/Frame::PVC Pipe X 18.10" and "O:3D Printer/Frame::PVC Pipe X 18.11"
  • When given the option between making something a modifier or a child, lean towards making it a modifier, such as "O:3D Printer/Frame::PVC Pipe X Off-the-shelf" and "O:3D Printer/Frame::PVC Pipe X 3D Printed" In this case. it's still a type of frame and it's better to nest as little as possible.

Additionally, I recommend these content conventions:

  • For any topic with children, provide a glossary of children on that topic page
  • For any topic with modifiers, provide a glossary of modifiers on that topic page
  • For any topic with parents, provide a glossary of parents and "grandparents" on that topic page
  • For any topic that exists on a Nmap or Nview, provide a glossary of related narratives on that topic page
  • Automate the creation of these glossaries if possible. If needed, add it as a child that is a Nmap itself, like "3D Printer/Nmap: Glossary

Priorities

To put this in action, I recommend first to start creating any new information using these conventions, then re-categorizing any information needed to onboard folks sufficiently to becoming true fans.

I think this includes creating the following pages:

  • Nmap: Core Processes
  • Nmap: Active Objects: 2018
  • P: Onboarding/Email Sequence: 2018

After that, re-name and connect the relevant pages of anything that's connected to Onboarding, Core Processes, and Active Objects.

When we reach 10 active contributors or more to the wiki, create a chrome pluggin to manage new page creation and significantly reduce overhead.

References

How To

Examples