Planning
Keep useful records throughout the season and plan fifteen content pages.
Collect photos, test results, and short notes as the goes on. When it is time to write, you will have examples to choose from instead of trying to remember everything at once.
Session records
After a build session or activity, note the date, what you wanted to do, what happened, and what you learned. Keep the photos, drawings, attendance sheets, or test results with that note.
Photograph an old before taking it apart. Write down a 's advice while you still remember it, along with the student work it helped. After a workshop, record who attended and any follow-up you agreed to.
Use your team's usual shared folders. A simple table can help you find things later:
| Date | Work | What changed or happened | Records | Who will write about it |
|---|---|---|---|---|
| Session date | Mechanism or project | Decision or result | Photo, test sheet, drawing, or activity log | Student's name |
First draft
Start with one problem the team has worked through. Explain what you wanted, what went wrong, what you changed, and how the next test went. Add a labelled photo or diagram beside the explanation.
Give the page to a teammate who was not involved. Can they explain why you changed the design? If they can only name the new parts, spend more space on the decision.
You can write about training and outreach while the is still being built. Those pages do not need to wait for the end of the season.
Choose a story before choosing a page
Write a short planning note for each candidate topic:
| Field | What to put there |
|---|---|
| Reader's question | The decision, learning, or result the page should explain |
| Main point | One sentence supported by your current records |
| Best illustration | The photo, comparison, diagram, or result that makes the point understandable |
| Missing information | A test condition, date, result, or explanation someone still needs to collect |
| Owner | The student who understands the work and can check the draft |
Choose stories with a clear decision or outcome first. A complicated mechanism may need little space if the choice is simple; a small change may deserve a whole page if the investigation explains an important lesson.
Page plan
You have one cover and up to fifteen content pages. This is one possible plan; change it to suit your team's work, and do not feel obliged to fill every page.
| Content page | Main topic |
|---|---|
| 1 | Team introduction, season highlights, and page references |
| 2 | What members learned and how they used it |
| 3 | , recruitment, leadership handover, and progress |
| 4 | partnerships and advice the team applied |
| 5 | Outreach goals and project plans |
| 6 | Outreach results, recruitment, and follow-up |
| 7 | Game strategy and design priorities |
| 8 | Whole-robot overview |
| 9 | Mechanical ideas and the design you chose |
| 10 | An important design change and its tests |
| 11 | A calculation that helped you make a decision |
| 12 | , controls, and |
| 13 | Control testing and recovery when something goes wrong |
| 14 | Maintenance and whole-robot testing |
| 15 | Another useful investigation or lesson from the season |
One mechanism study can cover calculations, testing, and several design changes together. Keep the explanation together rather than splitting it across distant pages to match an award list.
Compare two page plans
The books use different levels of detail to help readers move through a season:
| Example | How the material is organised | What you can adapt |
|---|---|---|
| Rebel Robotics, content pages 1 and 8–10 | An opening overview points toward a robot overview and a longer design journey | Give readers a short entry point, then keep the related engineering explanation together |
| Super 7, content pages 5–6 and 12–13 | An outreach timeline leads into project details; a mechanism comparison leads into a closer investigation | Use an overview to cover breadth and spend more space on the examples with something specific to explain |
You can use both approaches in one document. A timeline may cover several outreach activities, while one recurring project gets a detailed explanation. A whole-robot picture may establish context before a mechanism comparison. Allocate space from the work you have, rather than copying another team's page count or treating the sample plan above as a requirement.
Choosing material
Keep the details that help someone understand your work. Another photo of the same demo may add little; a note showing that participants later joined adds a result the photo cannot show.
Leave raw logs, complete code, meeting notes, and extra photos in the team's working folders. Use the for the explanation and the records a reader needs to follow it.
When a page feels crowded, ask what question each item answers. Move background detail to another part of the explanation or remove it if it adds no useful information. Keep the observation that explains a decision and the result that supports the conclusion.
Ownership and revisions
Give each topic a student writer. Once contributors have checked their own pages, have one editor read the whole document for consistent terms, dates, units, and layout.
Keep track of which robot version each page describes. After an event, update old results and explain what you changed. Save a dated PDF of every submission so you can match feedback to the right draft.
Before handing the plan to a layout editor, resolve each missing-information entry: collect the record, narrow the statement to what is known, or label the work as planned. A blank result field is a research task, not an invitation to invent a plausible number.