Retrospective, Documentation & Offseason Loop¶

Small teams live or die on knowledge transfer. When 2 seniors graduate and take their heads full of tribal knowledge with them, the team resets to zero. This document exists to prevent that.

Documentation is not paperwork. It is how next year's rookies avoid this year's mistakes.

Ongoing (during season)¶

Build Blog¶

Public — team website or a Chief Delphi thread. Weekly posts, written by rotating student authors.

Each post covers: - What we worked on this week. - What worked, what didn't. - Photos of prototypes, CAD, robot. - Data if we have it (cycle times, weights, driver hours).

Why: - Forces reflection. Writing about your week reveals what you did not actually understand. - Recruiting tool for next year's rookies and sponsors. - Gives back to the community — 254, 1678, 3476, 6328 all do this.

Engineering Notebook (per student)¶

Each student keeps a physical or digital notebook: - Their design decisions. - Sketches, calculations. - Failures and fixes.

Reviewed briefly at gate reviews — proves the student actually did the thinking. Bonus for awards submissions.

Failure Log¶

Team-wide, one file. templates/failure_log.md.

Every mechanical, electrical, or software failure gets a row:

Discussed at daily stand-up if new. Fixes tracked to closure.

Log Review Sessions¶

After every practice + match: download match log, open AdvantageScope with drive team, walk through anomalies. See 05_software.md.

Event-Level¶

Post-Match Debrief (5 min after each match)¶

Drive team + coach: - What worked? - What broke? - What do we adjust for next match?

Written on a whiteboard in the pit. Rotates to failure log if it becomes a pattern.

Post-Event Retro (30 min after event ends)¶

Whole traveling team: - Numeric results (rank, wins, RP). - Top 3 things that went well. - Top 3 things to fix before next event. - New items for failure log. - Assignments for between-event fixes.

No between-event redesigns. Fixes only.

End of Season¶

Full Retrospective (whole team, ~2 hours)¶

Structure:

Numeric review — final rank, awards, driver hours logged, gate pass/fail history.
Timeline review — what slipped, why.
Priority List review — did we build what strategy said? If not, why?
Failure log review — top 5 recurring failures. Are they design flaws (fix next year) or process flaws (fix now)?
Process review — which gates worked, which felt like theater, which we skipped.
What to keep, what to change — decisions logged.

Output: Season Retro doc committed to repo. Read at kickoff of next season.

Subsystem Documentation (student-authored)¶

Each subsystem owner writes 1–2 pages: - What the subsystem does. - Motor selection + gear ratio + why. - Mechanical drawings + parts list. - Wiring + sensor list. - Software architecture notes. - Known failure modes. - What we would do differently.

Committed to repo. Rookies read these before next kickoff.

CAD Archive¶

Full Onshape workspace exported / versioned. Renamed clearly by season and subsystem.

Code Archive¶

Season code repo frozen. Tag season-YYYY-final. Kept for reference.

Offseason Loop¶

August–October: Skill Building¶

Rookies learn Onshape via tutorials.
Programmers work through WPILib + AdvantageKit examples.
Machinists get shop-tool checkouts.
Old subsystems disassembled + inspected. Great teaching moments.

October–November: Preseason Project¶

Optional preseason build (offseason event, custom project, or design study of past game). Keeps students engaged and builds skills without game-year pressure.

December: Kickoff Prep¶

Priority-List template reviewed.
Scoring-sim spreadsheet cleaned and made reusable.
Repo template updated with lessons from this season.
Kanban board wiped and ready.
Team roster confirmed, subteam leads named.

January: Kickoff.¶

What NOT to Do¶

Do not skip the retro. It is boring and everyone wants to move on. It is the single most valuable meeting of the year.
Do not archive knowledge in Google Drive purgatory. Write in the repo, in Markdown, next to the code and CAD it describes.
Do not let the same senior write every doc. Rotate authorship so knowledge distributes.
Do not lose the build blog when the website changes. Export copies to the repo.

Templates¶

templates/failure_log.md — team failure log.
templates/gate_review.md — gate meeting record.
templates/ecr.md — engineering change request post-lock.
templates/part_release.md — part release checklist.
templates/fmea.md — failure mode + effects analysis (optional, for high-risk subsystems).
templates/event_checklist.md — competition pack list.