P:Documentation/Naming Conventions

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

---

While everything falls into these categories, we only specify these major pages for each of these categories:

• community
  • supporters
  • entrepreneurs
  • researchers
  • onboarding
• management
  • disciplined entrepreneurship
  • holacracy
  • meetings
  • metrics
• finance
  • budget
• product
  • 3D Printer
• marketing
  • positioning
• traction
  • physical advertising
  • direct sales
• praxis
  • OSE Spec

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

• https://csswizardry.com/2015/08/bemit-taking-the-bem-naming-convention-a-step-further/
• https://zawiastudio.com/dashboard/docs/
• https://zawiastudio.com/dashboard/docs/getting-started/