Blame
|
1 | # C01-1 Checkpoint Proposal: Design Brief Ready |
||||||
| 2 | ||||||||
| 3 | **Status:** Proposal (pending Jeremy's approval) |
|||||||
| 4 | **Created:** 2026-04-12 |
|||||||
| 5 | **Source:** TKT-004 — C1-1 Assessment Package |
|||||||
| 6 | ||||||||
| 7 | --- |
|||||||
| 8 | ||||||||
| 9 | ## Checkpoint A: Design Brief Ready |
|||||||
| 10 | ||||||||
| 11 | This checkpoint gates C1-1 (Design Brief Presentation). A student who completes all items is ready to join the presentation queue. A student who hasn't completed the checkpoint uses class time to finish --- naturally reducing their validation time and depth. |
|||||||
| 12 | ||||||||
| 13 | ### Student Self-Check Criteria |
|||||||
| 14 | ||||||||
| 15 | Students can check each item themselves before the lesson: |
|||||||
| 16 | ||||||||
| 17 | 1. **Problem/need/opportunity stated** --- Brief has a clear section naming a specific, concrete problem, need, or opportunity. |
|||||||
| 18 | 2. **Solution described** --- Brief explains what the software does and how it addresses the problem. A reader unfamiliar with the project could understand the idea. |
|||||||
| 19 | 3. **Users identified and described** --- Primary and secondary users are named with enough detail to picture them (not just "students" but specific types of users with context). |
|||||||
| 20 | 4. **Programming language stated with reasons** --- Language or framework is named with an explanation of why it suits the project. |
|||||||
| 21 | 5. **Feasibility and originality addressed** --- Brief includes a section on whether the project is achievable and what makes it different. |
|||||||
| 22 | 6. **Artefact ready** --- Brief committed to GitHub, printed copy in hand, cue card prepared (quarter A4, key talking points only), practiced presenting at least once timed at ~5 minutes. |
|||||||
| 23 | ||||||||
| 24 | ### Teacher Quick Check (circulating, <60 seconds per student) |
|||||||
| 25 | ||||||||
| 26 | | Check | What to look for | |
|||||||
| 27 | |-------|-----------------| |
|||||||
| 28 | | Printed brief | Physical copy on desk, covers all 5 content sections. They exist and say something specific. | |
|||||||
| 29 | | Cue card | Quarter A4 or smaller. Key words, not a script. | |
|||||||
| 30 | | Quick verbal | "In one sentence, what problem does your project solve?" Clear + specific = ready. | |
|||||||
| 31 | ||||||||
| 32 | ### Feedback Prompts (done to strong) |
|||||||
| 33 | ||||||||
| 34 | | Area | Prompt | |
|||||||
| 35 | |------|--------| |
|||||||
| 36 | | Problem too vague | "Your problem is generic. Which specific people have this problem and when?" | |
|||||||
| 37 | | Users generic | "You say 'teachers and students.' What does a teacher actually do with your app first?" | |
|||||||
| 38 | | Language thin | "You chose Python. Why Python and not something else? What does it give you?" | |
|||||||
| 39 | | Feasibility missing | "I see what you're building but not why you can build it. What's your argument?" | |
|||||||
| 40 | | Originality unclear | "If I Googled this, what would I find? What's your twist?" | |
|||||||
| 41 | | Ready for depth | "Now think about weaknesses. What could go wrong, and what would you do?" | |
|||||||
| 42 | ||||||||
| 43 | --- |
|||||||
| 44 | ||||||||
| 45 | ## Proposed Checklist Integration |
|||||||
| 46 | ||||||||
| 47 | **Where:** C01-2026 checklist, before the C1-1 assessment tasks. |
|||||||
| 48 | ||||||||
| 49 | **Suggestion:** Group learning tasks under "Checkpoint A tasks" heading so students can track their readiness. The checkpoint items above become the self-assessment criteria at the end of the learning sequence, before the presentation. |
|||||||
| 50 | ||||||||
| 51 | **Note:** The full assessment package (teacher protocol, question bank, scoring guide) is in `SD26-Teachers/sat/C01-2026/C01-1-Assessment-Package.typ`. This wiki page covers only the checkpoint criteria suitable for the student-facing checklist. |
|||||||
