OWL Document Control Policy

Owner: Accountable = Director of Orgazational Strategy & Learning (DOSL). Responsible = Director of Finance & Operations (DFO), with support and input from all Directors Audience: All OWL staff, partners, and stakeholders

Purpose

This procedure defines how Open Way Learning creates, stores, updates, and retires its organizational documents so that everyone knows what is official, where to find it, and how to keep it current.

The goals of this procedure are to:

• Provide a clear “single source of truth” for OWL’s internal systems and decision-making frameworks

• Reduce duplication and confusion about where documents live and which version is current

• Support collaboration and reuse of high-quality resources across projects and partners

• Maintain transparency, consistency, and accountability in how we manage information

This procedures meets these goals by defining a dual-platform system for OWL’s document control and file management:

• GitBook (backed by GitHub) holds OWL’s canonical, version-controlled documentation – our core policies, procedures, templates, and frameworks that describe how we operate.

• Google Drive holds the day-to-day working files – drafts, partner-specific materials, slide decks, reference resources, and media generated through our work.

Note: GitBook is paired with GitHub behind the scenes so that changes to official documents are fully version-controlled and easy to track over time. See Why GitHub/GitBook? for more background.

Operating Discipline

As a small, agile nonprofit, we cannot afford a jumbled mess of everyone “doing their own thing.” Our ability to serve partners well depends on a shared commitment to do what we say we do.

It is a non-negotiable expectation that all OWL team members:

• Follow the policies, procedures, and folder structures described in this document

• Use the designated locations (GitBook and Google Drive) for storing and updating work

• Raise questions or concerns when something in this system does not fit a real situation

Flexibility and creative, independent thought are essential to OWL’s innovation and continuous-improvement mindset. This policy is not meant to shut that down. Instead, it provides a clear way to channel that creativity:

• When a procedure is unclear, missing, or no longer fits, team members are expected to initiate the revision process, not work around it or ignore it.

• Proposed changes are surfaced through the open-source mechanisms described in this policy so that Stewards (see below) and relevant teammates can adjust the “source of truth” for everyone.

In other words: we either follow the current rule or work together to change the rule – no exceptions. Quietly bypassing our agreed-upon structures is not acceptable and undermines our ability to act as a coherent, trustworthy organization.

Steward Accountability

Each major area of our documentation has a designated Steward.

For the purposes of this policy, a Steward is defined as an OWL Director (or designated lead) who owns the clarity, structure, and accuracy of documents in their area or responsibility, even when others may help with drafting or filing.

Stewards may delegate day-to-day tasks, but they are ultimately accountable for keeping "official" content aligned with OWL's values, guardrails, and open-source mindset.

System Overview: GitBook vs. Google Drive

To reduce guesswork, OWL uses a simple rule:

GitBook is the "operating system." Google Drive is the "workbench."

In other words, GitBook holds our official, reusable, version-controlled, and cross-organizational content for "how OWL works." Google Drive holds the contextual or confidential day-to-day working documents used for designing, delivering, and learning from our services with specific clients and partners.

The following is the guidance you need to decide where a document belongs:

A document belongs in GitBook when:

• It explains how OWL operates as an organization (policies, procedures, roles, guardrails, decision-making frameworks, etc.).

• It is a template or tool intended to be reused with multiple partners, schools, or regions (e.g. maturity models, facilitation protocols, proposal templates).

• It is a cross-context resource and managed by a document steward (someone who is responsible for keeping it current).

• It does not contain personal identity information, confidential HR information, compensation data, or proprietary pricing.

In short, GitBook is where someone goes to answer the question "What is OWL's official way of doing this?"

A document belongs in Google Drive when:

• It is a draft or actively being developed or revised by an individual or small group.

• It is specific to a partner, project, or event (SOWs, trip plans, PDSA logs, workshop slide decks, notes, contracts).

• It contains sensitive or confidential information (HR, compensation, tax/finance detail, personal identity information, vendor contracts, internal budgets).

• It is a reference resource from another organization, or “inspiration” we are adapting.

• It is raw or semi-processed data (e.g. survey exports, observation notes, transcripts, spreadsheets).

In short, Google Drive is where someone goes to answer the question “What are we working on right now and with whom?”

Special cases: GitBook + Google Drive together

Some resources have both a stable "source of truth" and a flexible working version. In these cases:

• The official version (policy or template) lives in GitBook.

• The editable copy used for a specific partner or event lives in the relevant Drive folder (e.g., that partner’s folder/Facilitation & Service Resources).

• The GitBook page should reference or link to the recommended Drive locations for editable copies.

• The Drive copy should reference or link back to the official GitBook version and clearly indicate that GitBook is the original source code.

See Appendix 1: Folder Map & Stewardship Overview for a detailed map of how this plays out across OWL's Google Drive and GitBook structures.

Roles and Responsibilities

Role	Responsibility
Director of Organizational Strategy & Learning (DOSL)	System owner for OWL’s documentation ecosystem. Leads the overall design and evolution of how OWL creates, stores, updates, and retires documents across GitBook and Google Drive. Maintains this Document Control Procedure, ensures it stays aligned with OWL’s Collective Leadership & Decision Making framework, and confirms that major tool/process changes follow the agreed “one A” RACI pattern. Serves as the Accountable (“A”) role for decisions about adopting or changing documentation-related SOPs and tools, while delegating day-to-day tasks to the DFO and other Stewards as appropriate.
Director of Finance & Operations (DFO)	Run-and-maintain lead for core systems, hygiene, and training. Administers the platforms that support document control (e.g., Shared Drives, GitBook/GitHub access, permissions) and ensures they are configured to match this procedure. Holds primary Responsibility (“R”) for implementing documentation-related SOP updates (e.g., folder structures, access, naming conventions) that the Director team adopts. Initiates and coordinates the quarterly Google Drive cleanup cycle, including setting up temporary cleanup folders, triaging files (Archive / Move to GitBook / Keep in Drive), and nudging Stewards to make final filing decisions. Leads or delegates staff training on naming conventions, folder structures, and basic document hygiene so that day-to-day practices stay aligned with this policy. Monitors operational risks tied to documentation (e.g., compliance, retention, access) and raises issues per the Decision Ladder and #decision_log protocols.
Director of Program Impact & Visibility (DPIV)	Field-facing steward of documentation use and impact. Ensures that client- and program-facing work uses the documented systems (Drive, GitBook, Productive, Slack) in ways that support trust, evidence, and storytelling. Helps align partner artifacts, Bright Spots, and Proof Points with the structures in this procedure so that learning and impact are findable and reusable. Acts as a key “Consulted” role for documentation changes that affect service delivery, external communications, or impact reporting.
Document Stewards (Directors)	Content gatekeepers for their domains. Each Steward owns the clarity, coherence, and currency of a defined slice of OWL’s documentation (e.g. Finance & Operations, Outreach & Programming, Strategy & Innovation, Development & Partners, Templates & Resources). Stewards review and approve proposed updates to official GitBook content in their area, ensure Drive folders for that area match Appendix 1, and initiate updates when policies, tools, or practices shift. Stewards may delegate drafting, formatting, or filing tasks, but remain accountable for the quality and alignment of their section.
Tech Leads (GitHub-Savvy Staff)	GitBook/GitHub implementation support. At the request of a Steward, translate approved content changes into GitHub: updating Markdown files, cleaning up headings and links, adjusting SUMMARY.md navigation, and confirming that changes appear correctly in GitBook. Tech Leads do not decide policy content; they implement the technical side of an already agreed change and flag any structural issues they see. In general, the Steward and Tech Lead are not the same person for a given change.
All OWL Team Members	Everyday users and signalers. Follow the folder structures, naming conventions, and platform rules described in this procedure. Store work in the correct locations (GitBook vs Drive), avoid side-channel storage, and participate in cleanup cycles when asked. When something is unclear, missing, or no longer fits reality, team members are expected to raise the issue, propose improvements, or submit suggested edits instead of working around the system or creating parallel structures.

Document Contribution & Publication Workflow

This section explains how to create, update, and use documents in OWL's dual-platform system. There are three primary paths:

• Workflow 1: Create a new official OWL document (goes to GitBook)

• Workflow 2: Suggest changes to an existing GitBook document

• Workflow 3: Create or use working documents that stay in Google Drive

For any new or revised documents that are core to OWL's function as a nonprofit, you must use one of these workflows. Changes made this way are automatically version-controlled—we always know what changed, when, and by whom. This eliminates "mystery versions" and keeps updates transparent and auditable.

1. Proposing and Publishing a New Official Document (GitBook)

Use this when you are creating a new internal policy, template, or resource that should become part of OWL’s official, reusable “source code” in GitBook.

1. Draft in Drive. Start in Google Drive, in the correct folder for the topic (see Appendix 1). Use a clear draft title, e.g., DRAFT – Hiring Rubric – v1.

2. Get early feedback. Share the draft with colleagues and the relevant Steward for that content to ensure their comments are part of the new draft. Make clear whether you're asking for light edits or a major rewrite and, if relevant, a desired timeline.

3. Review and decide. The Steward reviews the draft to decide whether it aligns with OWL’s values and guardrails, is generic enough to be an OWL-wide resource, and meets minimum standards for clarity, quality, and format. Based on that review the Steward may:

   • Approve it for GitBook publication

   • Request revisions

   • Decide it should remain a Drive-only resource (e.g. too context-specific or still experimental)

4. Publish to GitBook. Once approved:

   • The title is cleaned up (remove "DRAFT" and version tags).

   • The document is converted to Markdown (.md) and added to the appropriate GitHub folder.

   • A Tech Lead can handle Markdown formatting, links, and SUMMARY.md updates as needed (see Appendix 5 for technical details).

5. Verify and link. The Steward and/or Tech Lead confirms the page looks correct in GitBook (title, formatting, links, sidebar). Note that a view-only reference copy is saved or updated in the appropriate Drive location (in the "On GitHub" folder), clearly labeled and linked back to the official GitBook page.

2. Suggesting Revisions to an Existing GitBook Document

Any OWL team member is encouraged to propose updates to official documents. Use this workflow when an existing GitBook page needs clarification, correction, or a content update.

1. Identify what needs to change. Note the title, GitBook section, and the specific paragraph(s) or section(s) you want to update.

2. Make your suggested changes to the document in question. At minimum, be sure to include what exactly you recommend changing, why it matters, and the proposed wording and format. You will do this by using one of the following three methods:

   • Small changes: On the respective GitBook page, highlight the text and use "Comment" to suggest changes.

   • For larger edits or rewrites: Use GitBook's change request process to initiate a change. Create the change you wish to see, then add the appropriate section Steward as a reviewer on your change request.

3. Steward review & collaboration. The Steward reviews the suggestion and may invite others into the conversation, especially for significant changes (For bigger decisions, the Steward follows OWL's Collective Leadership and Decision Making RACI procedure so that input and accountability are clear). At the end of the appropriate review process, the Steward and proposer will agree on a reasonable timeline for finalizing the update.

4. Implement the change. Once the Steward has approved the revision, they (or the Tech Lead) apply the changes by merging the change request.

5. Confirm. The Steward confirms the page is updated correctly in the handbook and that any relevant Drive links point to the updated source.

6. Announce. The Steward should inform the organization of the change. As of February 2025, GitBook is connected to OWL's Slack system, and all handbook updates are automatically announced in the #gitbook_handbook_changes channel.

Etiquette note In open source communities, it's considered something of a faux pa to merge one's own requests (i.e., to merge without first getting a second opinion from someone else). So even if someone has the ability to merge a change without consulting others, they should get the changes reviewed first.

3. Managing Working Documents in Google Drive

Use this method for any documents that stay in Drive as collaborative, client-facing, or context-specific resources.

1. Start in the right place.

   • Choose the correct folder using Appendix 1 (e.g. 02_External Partners & Clients if the new or revised document is specific to a workshop for a current client).

   • Use a clear, standardized name per the Naming Convention in Appendix 2 (e.g. RESOURCE – SEL Journaling Protocol – MS or SLIDE DECK – Terre Haute District PD – Feb 2024)

2. Collaborate with intention. Documents in Drive are meant to be collaborative and pragmatic, so avoid solo revisions unless absolutely necessary. Also use comments, suggestions, and revision history rather than making lots of separate copies for every unique use case. If you’re unsure whether to create a new version or update an existing one, check the revision history or ask the folder’s Steward.

3. Search before you store. Before creating or uploading something new, do a Drive search using keywords, skim the relevant folders for similar resources, and connect with a folder Steward to be sure you are building on existing work rather than duplicating it. This keeps the OWL Drive usable and reduces clutter.

4. Flag "promotion" candidates. If a Drive-based resource is being reused across multiple partners or clearly represents an emerging best practice for OWL, then collaborate with the relevant Steward so they can help decide whether it should be refined and published as an official GitBook document (per Workflow 1 above).

5. Keep the folder structure broad, not deep. Industry best practice for Google folder management is to keep 3–4 levels (max) of folder nesting. As such, when creating new subfolders, pause to check whether an existing folder already fits. This avoids important documents being buried down a rabbit hole.

6. Use folder READMEs and links. Each shared folder should include a short README document that briefly explains the folder’s purpose and key information:

   • What belongs there

   • Who the Steward is

   • Any special notes (e.g., “Copies of GitBook templates live here as editable versions”)

When a Drive document references an official GitBook policy or template, include a direct link and identify it clearly as the official version (e.g., "Refer to the official OWL Travel Policy in GitBook").

Quarterly Cleanup Procedure

To keep OWL's shared Google Drive usable instead of overwhelming, we run a Quarterly Cleanup. The goal with this cleanup is simple: Nothing important gets lost. Nothing unimportant clutters the way. This disciplined pruning routine helps us reduce clutter, make search results more useful, and keep “current vs. old” crystal clear.

When the cleanup happens. The DFO initiates the cleanup four times a year: February, May, August, and November. The focus each quarter is a manageable slice of Drive, not a full audit.

What we clean. Each cleanup prioritizes:

1. The shared 04_To File folder (our “inbox” for uncategorized docs)

2. Project folders from recently completed initiatives

3. Resource banks that haven’t been reviewed in 6+ months

4. Any folder flagged by a Steward or raised in team meetings as especially messy or confusing

The cleanup decision process. Each item that is reviewed will land in one of four locations:

1. Filed into a long-term home

2. Archived for history

3. Flagged for GitBook publication

4. Clearly not needed so it can be deleted

Cleanup Details

• Step 1 – Create the cleanup queue: At the start of each cycle, the DFO creates a temporary folder in Drive: !Drive Cleanup Queue – [Month Year]. Within that folder, three triage folders are created (note that these are temporary staging areas, not permanent homes):

  • [ARCHIVE] – Files that are no longer active but may be useful for historical reference

  • [TO MOVE TO GITHUB] – Finalized, high-quality resources that meet OWL standards and may become official GitBook documents

  • [ACTIVE – TO FILE] – Documents still in use that need to be renamed and moved to their correct long-term folders.

• Step 2 – Load the queue: Team members and Stewards move uncertain, outdated, or misc files from 04_To File and other messy areas into the !Drive Cleanup Queue – [Month Year] folder the DFO created.

• Step 3 – Triage: Reviewers (DFO + Stewards or designees) sort files into:

  • [ARCHIVE] – keep for history, but not active work

  • [TO MOVE TO GITHUB] – ready for Steward review and potential GitBook publication (see Workflow 1 & 2 above)

  • [ACTIVE – TO FILE] – keep active, but with better naming and correct placement.

• Step 4 – Final filing: Before the end of the quarter, folder stewards will make final decisions on items in each triage folder. As applicable, files are renamed (per Appendix 2) and moved into their long-term homes in Drive or published to GitBook/GitHub. Any unresolved files or unclear ownership are flagged for discussion in a scrum meeting or 1:1 follow-ups.

• Step of Last Resort: Any documents that sit in 04_To File or a cleanup staging folder for more than 3 months must be moved to a proper folder or deleted. No file should live in limbo forever!

Appendix 1: Folder Map & Stewardship Overview

This appendix essentially serves as the high-level "README" document for OWL’s document and folder ecosystem. It shows how OWL's Google Drive and GitBook are structured, what each major folder or section is for, and which role is responsible (Steward) for keeping it current and accurate.

The folder map below is only useful if we follow it. Every OWL team member is expected to store and update documents according to this structure or, when it no longer fits, to start the process to improve it. Stewards may delegate the work of filing, editing, and cleanup, but they remain accountable for ensuring that their area stays clear, coherent, and current.

GitBook Section Map & Stewardship

OWL’s GitBook platform serves as OWL’s public-facing operating system (also called our “Employee Handbook”) and provides a coherent, public “source code” for how OWL operates. In short, it houses the core documents that describe why we exist, how we work, and the values and guardrails that shape our decisions, both internally and with our client, partners, and other stakeholders:

• Canonical policies and guardrails – e.g., travel policy, Productive Playbook, governance documents, HR/Handbook content, and collective leadership procedures.

• Core playbooks and position statements – how we scope and deliver work, measure impact, and explain our stance on experiential learning, CBE, open design/open source, and related levers.

• Reusable templates and tools – protocols, models, and other open-source resources intended for adaptation and remixing by OWL and our partners.

These documents are living, version-controlled references, not static PDFs. They are updated through the document control workflow described in this procedure, with section Owners (Stewards) responsible for ensuring that “official” content remains clear, accurate, and aligned with OWL’s mission and values.

Stewardship, Purpose, & Drive Connections

• About OWL: Foundational overview of who OWL is and how we work: our purpose, culture, approach, and the core values and principles that shape our mission-driven, open-source practice. This section orients staff, partners, and stakeholders to OWL’s “why / what / how” at a high level.

  • Steward: Director of Organizational Strategy & Learning (DOSL), with input from all Directors.

  • Drive linkage: Primarily 01_Internal_Business-Ops → 01_Strategy-Innovation (mission, strategy) and 06_Sharpening the Saw (culture, learning, equity and identity resources).

• Governance: Formal structures, bylaws, board policies, code of ethics, and other governance tools that define how OWL operates as a 501(c)(3) nonprofit. These resources clarify the legal, ethical, and organizational foundations of OWL’s board oversight and distributed, mission-aligned leadership culture.

  • Steward: Director of Organizational Strategy & Learning (DOSL), in partnership with the Board Chair.

  • Drive linkage: 01_Internal_Business-Ops → 01_Strategy-Innovation → 01_Board_of_Directors-Governance and 02_OWL_Legal.

• Finance - Operations: Core policies, guardrails, and tools that keep OWL’s financial and operational systems aligned, compliant, and sustainable (e.g., travel policy, Productive Playbook, financial guardrails, everyday ops SOPs). This is the “how we keep the lights on and stay cash-smart” section.

  • Steward: Director of Finance & Operations (DFO).

  • Drive linkage: 01_Internal_Business-Ops → 02_Finance & Operations.

• Administration - HR: Employee Handbook content and key personnel policies: compensation, benefits, vacation, hiring, onboarding/offboarding, evaluation, and role clarity. This section centers on culture, accountability, and staff wellbeing from an HR/administration lens.

  • Steward: Director of Finance & Operations (DFO).

  • Drive linkage: 01_Internal_Business-Ops → 02_Finance & Operations → 03_HR, Benefits & Personnel.

• Outreach & Programming: How OWL shows up to partners and learners: client engagement rhythms, service design, scoping and stewardship of work, programming expectations, and how we connect that work to stories, artifacts, metrics, and evidence. This includes the Client Engagement Playbook and our approach to rethinking measures of success with partners.

  • Steward: Director of Program Impact & Visibility (DPIV).

  • Drive linkage: 01_Internal_Business-Ops → 03_Outreach & Programming and 02_External Partners & Clients (for partner-specific implementations of these patterns).

• Strategy - Innovation: Core procedures and position statements that anchor OWL’s learning and improvement stance, including Collective Leadership & Decision Making, the Document Control Policy, and position statements (Experiential Learning, CBE, Open Design/Open Source, Education Policy). This is the home for lightweight systems that help us decide, deliver, and learn coherently over time.

  • Steward: Director of Organizational Strategy & Learning (D-OSL).

  • Drive linkage: 01_Internal_Business-Ops → 01_Strategy-Innovation and 03_Facilitation & Service Resources (for associated tools and models used in practice).

• Development - Partners: How OWL builds and sustains funding and external partnerships: grants and fundraising strategy, donor/funder relationships, partnership agreements, the OWL Contractor Manual, and expectations for Fellows and other non-employee collaborators. This section keeps development and partnership work aligned with our mission, guardrails, and open-source ethos.

  • Steward: Director of Program Impact & Visibility (DPIV) – with input from the DFO and any Development lead or Board designee.

  • Drive linkage: 01_Internal_Business-Ops → 04_Development and relevant partner folders under 02_External Partners & Clients.

• Templates & Resources: Canonical, open-source versions of reusable templates and tools that support multiple areas of OWL’s work (e.g., SMART Aim templates, facilitation protocols, PBL/ExL tools, reflection routines, models, and other supports meant for adaptation and remixing by OWL and partners).

  • Steward: Director of Organizational Strategy & Learning (D-OSL), with co-Stewards by domain (e.g., DPIV for client tools, DFO for finance tools).

  • Drive linkage: 03_Facilitation & Service Resources (for editable copies and examples) and relevant 02_External Partners & Clients subfolders where customized versions are used with specific partners.

Unless otherwise noted, content in GitBook is licensed under CC BY-NC 4.0, reflecting OWL’s commitment to open-source practice: others are encouraged to use and remix our work non-commercially with attribution.

Google Drive Top-Level Structure & Stewardship

Root Shared Drive: Open Way Learning

Top-level folders:

1. 01_Internal_Business-Ops

2. 02_External Partners & Clients

3. 03_Facilitation & Service Resources

4. 04_To File

Each folder contains a “README” (Folder Overview) maintained by its Steward.

• 01_Internal_Business-Ops: How OWL runs internally – strategy, governance, finance, HR, operations, outreach, development, staff learning, and data.

  • Primary Steward: Director of Finance & Operations (DFO)

  • Co-Stewards: Relevant Directors for their sub-areas.

  Key subfolders (second level):

  • 01_Strategy-Innovation: Board governance, legal foundations, strategic plans, metrics frameworks, cross-cutting policies and procedures.

    • Steward: Director of Organizational Strategy & Learning (DOSL / successor)

    • Typical contents (third level):

      • 01_Board_of_Directors-Governance – bylaws, board minutes, board tools.

      • 02_OWL_Legal – incorporation docs, EIN, legal correspondence.

      • 03_OWL_Strategic_Plans – current and archived strategic plans, annual priorities.

      • 04_Strategic Measures & KPIs – high-level strategic metric frameworks (not raw data).

      • 05_Policies-Procedures – internal SOPs, decision-making frameworks, org-wide guardrails.

      • 06_Archive Strategy & Innovation Resources – legacy docs, prior versions.

  • 02_Finance & Operations: Money management, compliance, HR records, logistics, and internal systems.

    • Steward: Director of Finance & Operations (DFO)

    • Typical contents:

      • 00_To File – staging area for unfiled finance/ops docs (triaged quarterly).

      • 01_Strategic Finance & Compliance – budgets, audits, 990s, fiscal policies.

      • 02_Tactical Bookkeeping & Accounting – invoices, receipts, bank/credit statements.

      • 03_HR, Benefits & Personnel – personnel files, contracts, benefits docs, HR tools (restricted access).

      • 04_Operations, Travel & Logistics – travel policies, reimbursement tools, operational checklists, vendor info.

      • 05_Administrative Archives & Other – closed years, retired systems.

  • 03_Outreach & Programming: How OWL designs, communicates, and coordinates offerings with the outside world. Planning and messaging, not data storage. Note: Actual impact data and evaluation artifacts do not live here; they belong in 06_Data, Learning & Impact.

    • Steward: Director of Program Impact & Visibility (DPIV)

    • Typical contents:

      • 01_Internal Service Planning & Delivery – menus of offerings, sample scopes, series designs, internal planning docs.

      • 02_Partnership Development & CRM – partner meeting notes, outreach trackers (non-confidential, non-CRM system of record).

      • 03_Communications & Messaging – language banks, evergreen messaging, FAQs.

      • 04_Marketing, Media & Promotion – brand kit, website content drafts, newsletters, social media planning.

      • 05_Events & Public Engagement – convening design, conference proposals, public presentations.

    • 07_Archive Outreach & Programming – retired campaigns, past events.

  • 04_Development: Grants, fundraising campaigns, donor relations, and development strategy.

    • Steward: DFO (with support from other Directors)

    • Typical contents:

      • 00_To File – staging area for drafts and misc development docs.

      • 01_Grants - Pipeline & Compliance – active & upcoming grants, reporting calendars, compliance docs.

      • 02_Fundraising & Non-Grant Development – individual giving, corporate sponsorships, events, annual appeals.

      • 03_Archived Development Resources – closed grants, past campaigns, prior proposals.

  • 05_Data, Learning & Impact*:* Evidence of what’s working: metrics, evaluation artifacts, learning syntheses, and research base.

    • Steward: Director of Organizational Strategy & Learning (DOSL), with the Director of Program Impact & Visibility (DPIV) as lead for program- and project-level data.

    • Typical contents:

      • 01_Org-Wide Metrics & Learning – high-level dashboards, board-facing metrics summaries, cross-initiative learning.

      • 02_Program & Project Data – WNCRP data, CAPS metrics, district survey exports, PDSA logs (organized by initiative).

      • 03_Impact Reports & Proof Points – evaluation reports, case studies with data, briefs.

      • 04_Research & Evidence Base – literature reviews, external research summaries supporting OWL’s approaches.

  • 06_Sharpening the Saw: Internal learning, wellness, and reference library for the OWL team.

    • Steward: Director of Organizational Strategy & Learning (DOSL)

    • Typical contents:

      • 01_Staff Wellness & Check-Ins – wellness tools, internal check-in routines.

      • 02_Internal Team PD & Retreats – agendas, materials, and notes from internal PD and retreats.

      • 03_Equity & Identity Resources – core equity resources and frameworks.

      • 04_Reading & Reference Library – topic-organized reference materials, course readings, external PD artifacts, “OWL’s Library & Other Hard Copies.”

      • 05_OWL Statements – public statements and position papers.

• 02_External Partners & Clients: All partner-specific work and history. If it’s tied to a particular district, school, funder, or partner organization, it lives here.

  • Steward: Director of Program Impact & Visibility (DPIV) Key sub-folders:

    • 01_Active & Ongoing Clients & Partners – one folder per active partner (district, school, funder, org). Within each partner folder, typical third-level subfolders include:

      • 01_Active Scopes, Contracts & Agreements – The most current, fully executed SOWs, contracts, POs, MOUs, the latest Estimator/budget export, and any active amendments. This is the single source of truth for what OWL is authorized to do and be paid for.

      • 02_Planning & Agendas – Series plans, trip plans, agendas, logistics, and any running “Client Outcomes & Milestones” trackers or running notes (with key docs linked at the top).

      • 03_Deliverables & Artifacts – Slide decks, handouts, tools used with that partner in various workshops, design sprints, coaching sessions, or other engagements.

      • 04_Data & Learning – Partner-specific PDSA notes, survey summaries (mirrored or summarized in 06_Data, Learning & Impact as needed).

      • 05_Archive – Past years or fully completed work for that partner, including superseded scopes, old Estimator versions, and retired planning docs.

    • 02_Emerging or Potential Clients & Partners – notes, early design docs, and exploratory planning.

    • 03_Occasional or Stale Clients & Partners – dormant relationships that may be reactivated.

    • 04_Archived – Past Clients, Partners, & Projects – fully closed work; history only.

• 03_Facilitation & Service Resources: Reusable tools, protocols, agendas, and models used across partners.

  • Stewards: DPIV (structure & content) with each Program Manager responsible for client-specific versions.

    Typical second-level subfolders:

    • 01_Example Workshop Agendas – generic agendas and session flows.

    • 02_Facilitation Tools, Activities, and Protocols – OWL toolkits such as:

      • 00_TOOLKIT – OWL Protocols & Workshop Management Essentials

      • 01_TOOLKIT – OWL Basics – The What, Why, & How

      • 02_TOOLKIT – Learner Centered Essentials & Culture Shift

      • 03_TOOLKIT – Design Thinking & Improvement Science

      • etc.

    • 03_Co-Design Lessons, Activities, & Protocols – classroom activities, lessons, and other resources co-designed with educators in the field.

    • 04_Virtual Workshop Planning Tools – virtual facilitation templates.

    • 05_Archived Planning Resources – retired tools and old versions.

• 04_To File: A landing zone for new or “orphan” docs. Use this folder when you genuinely don’t know where something goes. The Quarterly Cleanup procedure moves items into their proper homes or archives.

  • Steward: DOSL (process) with all Stewards contributing.

Appendix 2: Decision Criteria (What Belongs Where?)

Question to Ask	If YES →	If NO →
Is this the final, approved version of an OWL-wide policy, protocol, or resource intended for team-wide or public reference?	GitBook	Google Drive
Will it be reused across schools, clients, or team members?	GitBook	Google Drive
Does it require version control or formal stewardship?	GitBook	Google Drive
Is it still a draft, tailored to a specific project, or actively evolving?	Google Drive	GitBook
Does it contain personally identifiable information (PII), compensation or HR records, contract terms, or proprietary pricing data?	Google Drive (restricted access)*	GitBook

OWL is committed to open-source transparency, but not at the expense of personal privacy or proprietary integrity. All sensitive documents, such as personnel files, salary information, vendor contracts, and private partner agreements, must remain in restricted-access folders in Google Drive and should never be uploaded to GitHub or GitBook.

Appendix 3: File/Folder Naming Convention

Consistent file naming helps everyone at OWL quickly locate resources without needing to open multiple documents. A clear, structured title provides instant context, improves searchability across Google Drive (especially in shared team folders), and reduces confusion. A strong file name should answer three key questions:

What is it?

Who is it for?

When or where was it used?

OWL's naming convention, described below, is designed to reflect this by consistently communicating the document’s type, audience, and context.

Standard Format

[TYPE] Topic – Context or Use – (Optional: Date or Version)

Type	Example File Name
Template	[TEMPLATE] Proposal Template – District Planning
Slide Deck	[SLIDE DECK] SC STEM & PBL Workshop – Fall 2024
Resource	[RESOURCE] STEM Maturity Model - V4
Archive	[ARCHIVE] Terre Haute Elementary School Field Notes 2022

Keyword Guidance for Naming

To improve searchability and prevent duplication, include the following kinds of descriptive tags in your file name when relevant:

• Grade Level → K–5, MS (Middle School), HS (High School)

• Subject Area → Math, Science, ELA, SEL, CTE

• Audience or Use → District Leaders, Facilitators, Students

• Resource Type → Slide Deck, Worksheet, Protocol, Agenda

• Date or Version → Jan 2024, v2.1, SY2023–24

Example Titles Using Best Practices

• [RESOURCE] MS Science – Water Quality Lab – v1

• [SLIDE DECK] HS Math PD – Inquiry Practices – Jan 2024

• [TEMPLATE] ELA Student Reflection – Grade 9

These examples make it easier for colleagues to locate documents via Drive search—even if they weren’t involved in creating them.

Whenever possible, match the file name to a consistent format used across OWL documents. This not only improves Drive search results but also enables team members to sort by filename to quickly group related resources. If a document has gone through multiple drafts or iterations, include the version number or date in the title rather than duplicating the file. Avoid storing more than one active version of the same document in the same folder. If needed, use comments or suggestion mode to update in place.

What to Avoid

Avoid vague or personal file names that give no searchable context, such as:

• "Workshop Notes"

• "New Template"

• "Session Slides – Ben"

• "Copy of Final Draft"

These require users to open the file to determine its relevance, which slows collaboration and increases the risk of using outdated materials.

Rule of Thumb: When naming or saving a file, ask: “If someone else needed to find this six months from now, what keywords would help them locate it quickly?”

Folder Naming Convention

Just like individual file names, folder names should be clear, descriptive, and consistently formatted. Avoid vague titles like “Misc,” “New Folder,” or personal names (e.g. “George’s Stuff”). Each folder name should reflect its contents and purpose, ideally using similar conventions to OWL file names, such as including audience, subject area, or date range when relevant. For example:

• PBL Workshop Slide Decks – 2023–24

• STEM Resources – MS Science

• Archived Partner Files – SY2021–22

• District Planning Templates

When in doubt, use neutral, searchable terms and check whether a similar folder already exists before creating a new one.

Appendix 4: Frequently Asked Questions

Why a handbook?

In distributed, open organizations like OWL, the organization itself is itself a project like all others—and the handbook is what people use to work on that project. It's the place things go when they become part of the organizational infrastructure or fabric, where people go to change and improve OWL itself, and where collective knowledge gets retained and transmitted so people spend less time re-learning their jobs and more time performing them.

Why GitHub/GitBook?

While Google Drive is useful for real-time collaboration, OWL uses GitHub + GitBook to manage finalized documentation because it offers a much clearer and more reliable way to track changes over time. In Google Drive, version history only shows who made edits and when, but not exactly what was changed. GitHub, by contrast, shows the specific lines of text that were added, deleted, or edited in each update. This makes it easy to see how a document has evolved, who contributed what, and why changes were made, helping prevent confusion or duplication when multiple people are working on important documents.

We also use GitHub in combination with GitBook because together they offer a clean, accessible interface for most team members (GitBook), while supporting powerful behind-the-scenes version control and editing features for those with more technical skills (GitHub). Content is stored in a simple, open format called Markdown (.md), which is easy to read even in raw form, works across any platform, and can be quickly converted into polished webpages, PDFs, or other formats. For most team members, interacting with GitBook is as simple as reading or suggesting edits to a web-based handbook. For tech-savvy contributors, Markdown files can be edited directly in GitHub to ensure everything stays organized, up to date, and properly formatted. Refer to Appendix 5 if you wish to make contributions directly in GitHub rather than via GitBook.

In short, this combination of GitHub and GitBook helps OWL accomplish an important goal: maintain transparent, auditable, collaborative documentation of its key processes, policies, and procedures—and do so in a public-by-default manner aligned with OWL's open ethos.

Do we record SOPs in the handbook?

Yes. Storing standard operating procedures are the GitBook handbook's raison d'être. These are precisely the kinds of canonical, organizationally applicable documents that the system is designed to house and assist in modifying.

How often are changes expected?

Handbook updates should not become a "once per quarter thing," or "something we do at the offsite." The GitBook handbook should be something that grows and morphs in line with the organization as it matures every day.

At OWL, we expect incremental changes often (in line with the "release early, release often" spirit of open source development). Since the handbook is the manifestation of our organizational architecture, it should change every time that architecture changes—every time a new decision results in a policy revision, or a process gets refined, or a template changes, and so on.

We aim to cultivate the attitude that "the work isn't done until it's written down." This might be difficult for people to abide by, because it often makes everyday work take longer: You not only have to Develop the Thing but also Document the Thing. (Put another way: A task doesn't take one hour to complete and 30 minutes to document; documentation is part of the task itself, so completing the entire task takes 90 minutes.) This can initially feel like a drag on productivity because it adds additional completion time to every work task.

But documentation pays dividends in saved time for others and the organization as a whole, as it continues to grow and accrue context that gets cemented in the handbook.

Every change to the handbook is an investment in the growth of the organization and a gift to the people who aren't working there yet.

How do we safely revert a mistake?

Using GitBook:

1. Click the page you'd like to revert

2. Click the context (three dots) button

3. Click Version history

4. Select the version of the document to which you'd like to revert

5. Click the context (three dots) button

6. Click Revert to this revision

GitBook then rolls back the change and syncs the necessary changes with GitHub

In Git-based workflows, time only moves forward. So while you are "rolling back" a change, in the project history that rollback is actually logged as a separate change after the one you revert. That means it is actually possible to rollback the rollback!

How do we know we're using the handbook well?

We'll know OWL is making best use of our handbook when we observe bias for action amongst team members. That means they are:

• Not just saying "I really think we should change this" and "Who's job is it to update this?", but instead taking initiative by documenting the changes they want to see, proposing those changes in a change request, and tagging department heads for review.

• Always responding with a link—that is, when answering someone's question that sounds like "What do we do about…," their responses sound something like "Our process is this, and it's documented here: [link to handbook section and sub-section]."

• Concluding meetings and discussions with some form of the question "Where and how are we documenting this decision in the handbook?"

• Proactively proposing fixes for unclear language, spelling mistakes, and broken links on handbook pages as they're using the handbook.

Appendix 5: Direct GitHub Editing

This section is optional for GitHub-savvy contributors and Tech Leads.

Most OWL team members will never need to touch GitHub directly. The default paths for updating official documentation are:

• Suggesting edits in Google Docs for drafts and working content, or

• Commenting or suggesting changes in GitBook for published content.

Direct editing of Markdown (.md) files in GitHub is optional and generally limited to:

• Tech Leads

• Document Stewards who are already comfortable with Git/GitHub

Use direct GitHub editing only when:

• You are updating Markdown files in the OWL docs repository (e.g., README.md, SUMMARY.md, or section .md files), and

• You understand how branches and pull requests work, or you are working under the guidance of a Tech Lead

Expectations for direct GitHub edits

When working directly in GitHub, contributors are expected to:

• Follow the branch → commit → pull request pattern (no direct pushes to main).

• Keep Markdown structure and navigation consistent (headings, links, and SUMMARY.md when needed).

• Tag the relevant Document Steward in any pull request so changes are reviewed, not silently merged.

• Confirm that GitBook sync displays the updated content correctly once merged.

References

• GitHub Docs: Pull Requests

• GitBook Documentation

• Markdown Guide