Project Ops

GitHub Setup

Issue templates, labels, project-board guidance, and contributor workflow.

Repo visibility default: private.

GitHub Issues and a GitHub Project board are the contributor-facing work system. Markdown files remain the durable source of truth for curriculum, decisions, policies, and pilot notes.

Suggested Labels

Track labels:

  • track:ai-readiness
  • track:ai-literacy
  • track:makerspace
  • track:contributor-development

Lifecycle labels:

  • stage:seed
  • stage:sketch
  • stage:draft
  • stage:pilot
  • stage:revised
  • stage:ready
  • stage:field-notes

Type labels:

  • type:module
  • type:lab
  • type:handout
  • type:review
  • type:decision

Review labels:

  • review:learning-design
  • review:privacy-safety
  • review:accessibility
  • review:technical

Cross-generation labels:

  • cross-gen:yes
  • cross-gen:maybe

Suggested Project Board Columns

  • Inbox
  • Ready to Shape
  • Drafting
  • Review
  • Pilot Prep
  • Pilot / Field Notes
  • Done
  • Parked

Contributor Workflow

  1. Create or choose an Issue using the closest template. Every proposed lab begins as a type:lab Issue.
  2. Triage the proposal for overlap, primary module, track, scope, credit/payment terms, and review needs.
  3. Assign an owner and reviewer before substantial work begins, then link the Issue to its canonical labs/<slug>/ package when it is created.
  4. Move the card through the Project board as work changes state.
  5. Use a linked pull request for durable Markdown or approved static-lab-asset changes.
  6. Do not mark work complete until review criteria are met and safety/privacy questions are resolved. Missing v1 material remains a visible backlog item.

Private Repo Assumption

Keep the repo private while v0 product strategy, contributor policy, pilot materials, and commercial boundaries are still forming. Revisit public visibility only after RS decides what is safe and useful to share.

Source: github-setup.md