This plan relies on BookStack for the feature of surfacing the same (linked) content in multiple places; we can't easily replicate that with Dokuwiki.

Printed content and online content are different use cases, and the documents need different features.

Printed content needs features to support a paginated environment:

• Page numbers
• Running heads
• Table(s) of contents
• Glossary

…and an overall document design that supports readers of a physical document.

(For a fully robust solution, we'd also want an index for large collections, but that's very hard to do.)

Online content needs to support a multi-faceted, random access environment:

• Strong, informational headings
• Table(s) of contents
• Full text search
• Robust references

In both cases, we need a strong, tested organization so that readers can find what they need, quickly.

Put external-facing content on the public website:

• Policies
• Events
• Class Handouts (students may not be members)
• Tool List

(The class handouts are PDFs, updated as needed, etc.)

If this proves too annoying, we could try a public-facing bookstack shelf…

Put internal-facing content on an internal, member-only bookstack instance.

Shelves are for audiences:

• General Members
• Shop Techs
• Tech leads
• Maintenance Group
• Instructors
• Event planners
• Board
• Staff

Note that all of these shelves contain information for a particular audience.

While the internal web is not public, material on these shelves is owned by Protohaven, under an appropriate license (CC BY-NC-SA)

A separate, special shelf will hold information by members:

• What We're Working On

Each member gets a book they can use as they see fit. Members can use this area for various purposes:

• A place to keep notes on personal shop projects (“What was I working on?”).
• A space to collaborate with other members (“Hey, can you take a look at this?”).
• Somewhere to practice a draft (this way, members won't have to go through revision cycles of a document in place: this means less pressure on the author, and less chance a reader absorbs incorrect or incomplete information).

All content created by members in the What We're Working On shelf is owned by the respective authors, and Protohaven makes no claim of rights over that material.

If members use this section to produce drafts of work for other sections, the ownership moves to Protohaven when the content is moved to the appropriate shelf.

Books can appear on multiple shelves. We will use the book abstraction for areas of content that may be of interest to one or more of the above audiences:

• Policies (everybody)
  • Code of Conduct
  • General Shop Rules
  • Storage
  • Etc.
• Tool Usage Guides (general members, shop techs, tech leads, instructors)
  • Individual tool usage guides (see below)
  • Chapter per tool
  • These guides include both student and member content
• Tool Basic Maintenance Guides (shop techs, tech leads)
  • Individual tool basic maintenance guides (supporting Asana)
  • Pointers to usage guides
  • Chapter per tool
• Tool Advanced Maintenance Notes (maintenance group)
  • Advanced maintenance guides, schedules, notes
  • Pointers to usage guides
  • Pointers to basic maintenance guides
  • Chapter per tool
• Software Guides (general members, shop techs, tech leads, instructors)
  • Individual software guides (see below)
• Shop Areas (general members, shop techs, tech leads, instructors)
  • Ongoing and archived projects for that shop area.
  • Area-specific information that isn't tool/software related
• Instructor Materials (instructors)
  • Annotations on Class Notes
  • Lesson Plans
  • Clearance Checklists
• Event Planning (event planners)
  • Event History
  • Setup Checklists
• Meta Documentation (general members, shop techs, tech leads, instructors, event planners)
  • How to create new documentation (paginated and online)
  • How to edit documentation (paginated and online)
  • Templates and how to use them (paginated and online)
  • Information Architecture notes (organization, vocabulary)
  • Planning

We leverage BookStack's permissions system to align access to content with need (an example policy: instructors and tech leads get access to the clearance checklists; general members do not).

Make an edit to a book in one place, and the change shows up in all of them.

With this organization, we can provide each audience type with content specific to them (hopefully reducing cognitive load), and users can also delve into other shelves as needed (as long as they have permissions to do so)

The information flow of the usage guides goes something like this (fancy diagram forthcoming):

1. Usage guides are produced as PDFs from sources checked in to version control.
2. PDFs are published to BookStack, printed to update shop floor binders, and reproduced in class handouts (as needed).
3. Updates and corrections are collected from the binders (dedicated pages for handwritten notes) and BookStack (comments on the guide page).
4. Updates and corrections are worked into the PDF sources, cleared, and checked in.
5. Go to step 1.

We take a layered approach with the tool usage guides.

The single source of truth for the tool usage guides are the printed material.

For each tool, the tool usage guide has two parts: the simple version and the extended version.

The simple version is intended for learners and is used as an inclusion in the class notes handouts. The Class Notes handouts can be printed (and instructors should probably have one printed out to show students at the start of class). Most students will likely download the PDF from the public-facing website.

The extended version adds extra notes that may overload a learner, but are important to keep in the guide for shop users. Extended versions are combined into documents that can be printed and kept as physical copies on the shop floor, collecting hand-written notes. Extended versions can also be stored in BookStack, where members can make comments and annotations. These hand-written notes, comments, and annotations can periodically be collected and added to the extra notes in the extended version, which can then be redistributed to the binders, etc.

The workflow for software guides is the same as for tool usage guides above.

Lists (tools, etc.) are loaded form a single source (air table, or google sheets, or…)