Introduction

The Openline playbook is a public artifact that defines why we exist and how we work. Born out of the open source community, open source principles influence how we build consensus and document our outcomes. Open is a principle that extends far beyond our name.

With the playbook, we attempt to:

• recruit people who share our values and goals
• onboard new employees in a seamless and transparent manner
• allow potential partners, customers, and communities to better understand who we are and how we will conduct our business
• hold ourselves accountable to clear, transparent principles

As a distributed organization, the better our communication, the better our eventual outcome. Open, transparent communication is a pre-requisite to everything we do. As such, the Openline playbook is the central repository for how we run the company.

Anyone can submit a pull request to suggest updates or improvements to the playbook.

Guiding principles

• The playbook can be viewed by anyone. Transparent communication is at the core of everything we do. We build in public, and as such, how we build is also a public artifact. Everything in the playbook is searchable and easy to navigate.
• The playbook is the source of truth for how we work. All information in the playbook is to be kept accurate and up-to-date.
• The playbook can be edited by anyone. All teammates and community members can submit updates or improvement to the playbook. No matter your technical background, it's easy to learn how to improve the playbook.
• The playbook is maintained by all Openline team members. We work as a team. We all share the responsibility for ensuring everything in the playbook is current and up-to-date. If you see something that requires an edit, make the change then and there.

How to use the playbook

• Business is dynamic and ever changing. As such, everything in the playbook should be considered as "best practices" to be adapted to your specific situation rather than an iron clad policy. If something is iron clad, it will be stated in a way that you won't be able to miss it.
• All processes must be documented in the playbook. If it's not in the playbook, it doesn't exist.
• The playbook documents what we do RIGHT NOW. It does not describe what we hope to do in the future, or what we did in the past.
• Wherever possible, answer questions with a link to the playbook. Don't spend time writing out answers that are already written down.
• If someone sends you a link to the playbook, they are doing so because it has the best answer to your question.
• If what you're looking for isn't answered in the playbook, find the answer and document it in the playbook. It's highly likely that someone else will have the same question, and by taking the time to share your knowledge, you'll save everyone time and effort.
  • If you're not the right person to document the answer, clearly pass along the responsibility to the appropriate person and ensure the document is created in a timely manner.
• Resist the temptation to improve a playbook article at the same time you create it. Always write out things as you know them to be today and submit it first, then you can come back and improve the document as you learn more. By separating these two steps, we always share as much information as we have at the present moment.
• Announce important changes in the appropriate slack channel(s). Ensure everyone who needs to be made aware of the change is made aware.

Why do we use Github and not {my favorite wiki} or {my favorite docs tool}

The playbook consist of Markdown files (.md or .mdx) that live in a Github repository. As the playbook is our source of truth on how we run the business, it must always be kept up to date across the business. In this regard, using Github offers several benefits over wiki's and other collaboration tools (like Google Docs):

1. Many playbook changes require updating references and mentions across multiple pages. In wikis and Google Docs, there is no easy way to propose a group of changes to multiple sections or pages, which means people making and reviewing edits can easily miss other places that need to be updated. This format allows grouped multi-page changes and collaboration. This is more complicated than wikis or Google Docs, but we commit to help every teammate learn how to edit this playbook.

2. Many playbook changes are collaborative and need to be reviewed, revised, and commented on by other teammates. Github makes this possible with comments and code reviews. Wikis don’t make this easy or possible, and Google Docs has very limited review and no revision capabilities.