Home A - Z
Page Index

An Otter Wiki

Blame

5c1696 lisa 2026-08-29 16:39:27
Add sd/C10: hub + guides for the in-class model Seven curated learning pages plus the C10 home hub, generated by the shared port script (new c10 config): the C100-* cluster, the tick sheet, the solutions booklet and the assessment paperwork stay out of the wiki. Each page gains a skill title, a lead naming the rubric band it serves, one earned mermaid visual and a Check Your Understanding fold. The git-log examples are anonymised (prior-cohort names, hostnames and repo URL removed). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RxqgYbTNNYrPNuko6xfbKs
1 
<!-- Generated from applied-computing-au vic/unit3-4/sat/C10-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
2
# Tracking Plan Changes — Annotated Gantt Charts and Project Logs
3
4
*The two instruments C10-3 is marked from, and the meta-log that turns them into a judgement. Read it before class write 3.*
5
6
> [!NOTE]
7
> **The bands this serves.** C10-3, 3–4: *annotations outline the modifications*. 5–6: *annotations describe them*. 7–8: *adjustments or logs/journals document and explain them*. 9–10: *evaluates the modifications*. Each rung adds something — an annotation that only says *what* changed cannot reach 7–8, and no amount of logging reaches 9–10 without a verdict.
8
9
```mermaid
10
flowchart LR
11
G["Annotated Gantt<br/>baseline vs actual"] --> M
12
E1["Log entry<br/>date · what changed · why<br/>impact · who decided · evidence"] --> M
13
E2["Log entry"] --> M
14
E3["Log entry"] --> M
15
M["The meta log — your final entry<br/>What pattern of changes?<br/>Reactive or proactive?<br/>Did they help or harm?"] --> C4["C10-4<br/>plan effectiveness"]
16
```
17
18
*Everything funnels into one entry. The individual logs are evidence; the meta-log is the judgement, and it is also what C10-4 draws on.*
19
20
## What is this?
21
By reviewing **how and why your plan changed**, you gain evidence of adaptability and critical decision-making—not just task tracking.
22
23
**Purpose:** Document project modifications with reflective analysis for C10-3 assessment.
24
25
---
26
27
## 🎯 Choose Your Tracking Method
28
29
### Option 1: Traditional Approach
30
31
- **📊 1. Annotated Gantt Chart**
32
- 📝 2. Project Log File
33
34
### Option 2: GitHub Approach
35
36
- 📊 1. GitHub Projects (Gantt view)
37
- 📝 2. GitHub Issues (tracking)
38
39
---
40
41
## 📊 Annotated Gantt Chart Guide
42
43
### What to Show:
44
45
- 🔹 **Original timeline** (from Unit 3) vs **actual timeline**
46
- 🔹 **Task modifications**: Added, removed, or changed tasks
47
- 🔹 **Duration changes**: Tasks that took longer/shorter than planned
48
- 🔹 **Milestone shifts**: Deadlines that moved
49
- 🔹 **Resource adjustments**: When you needed help or changed priorities
50
51
### How to Annotate:
52
53
#### Traditional Method (GanttProject/Excel):
54
```
55
Annotation Examples:
56
• "Extended coding by 3 days - alpha testing revealed more bugs"
57
• "Added validation task - requirements changed after client feedback" • "Moved documentation earlier - needed for beta testing prep"
58
• "Reduced UI design time - focused on functionality first"
59
```
60
61
#### GitHub Projects Method:
62
- Use **milestone descriptions** to explain changes
63
- Add **timeline comments** on project board
64
- Use **labels** to categorise change types (scope, technical, timeline)
65
- **Project notes** explain major modifications
66
67
---
68
69
## 📝 Project Logs Guide
70
71
### What to Track:
72
- 🔹 **Date and time** of each change
73
- 🔹 **What changed** (task, deadline, scope, resources)
74
- 🔹 **Why it changed** (testing results, technical issues, feedback)
75
- 🔹 **Impact** (how it affected other tasks)
76
- 🔹 **Decision maker** (you, teacher feedback, user input)
77
78
### Log Categories:
79
80
- **Scope changes**: New/removed features - *Did this add value or cause delay?*
81
- **Timeline adjustments**: Extended/compressed tasks - *Did this make the project finish earlier/later?* - **Technical issues**: Bug fixes, tool problems - *Did this improve solution quality?*
82
- **Resource changes**: Help needed, priority shifts - *Did this make development more efficient?*
83
- **User feedback**: Changes from testing - *Did this better meet user needs?*
84
- **AI assistance**: When AI tools helped/hindered development progress - *Did this speed up or complicate development?*
85
86
### 💭 Add Reflection Checkpoints:
87
88
After major milestones (alpha testing, beta testing, major feature completion), write **1-2 reflective sentences**:
89
90
- *"After alpha testing, I realized my original timeline was too optimistic for validation work"*
91
- *"Beta feedback showed users needed simpler navigation - good thing I built this modularly"*
92
93
### 📸 Include Evidence Annotations:
94
95
For 2-3 key log entries, add supporting evidence:
96
97
- **Screenshot**: Before/after interface changes
98
- **Code snippet**: Key bug fix or improvement
99
- **Timeline visual**: Gantt chart section showing the change
100
- **Caption**: *"This validation fix prevented major user errors"*
101
102
### Option 1: Traditional Log File
103
104
#### Simple Log Template:
105
```
106
WEEK 4 REVIEW (Post-Alpha Testing):
107
DATE: 2025-08-12
108
CHANGE: Extended coding phase by 2 days
109
REASON: Alpha testing found validation errors
110
IMPACT: Beta testing delayed by 1 day, but solution quality improved
111
DECISION: Worth the delay to fix critical bugs
112
EVIDENCE: [Link to testing results, commit #a3b2c1]
113
REFLECTION: Original timeline was too optimistic for validation work
114
115
WEEK 6 REVIEW (Post-Beta Testing):
116
DATE: 2025-08-18 CHANGE: Added user tutorial feature
117
REASON: Beta testers confused by interface
118
IMPACT: Extra 3 days development, but much better usability scores
119
DECISION: Essential for user adoption
120
EVIDENCE: [Screenshots of old vs new interface]
121
REFLECTION: Should have planned for user guidance from the start
122
```
123
124
125
126
127
---
128
129
### Option 2: GitHub Issues Method
130
131
#### Issue Structure:
132
```
133
Title: [TIMELINE] Extended coding phase
134
Labels: timeline-change, technical-issue
135
Milestone: Week 5 Development
136
137
Description:
138
**What Changed:** Coding phase extended by 2 days
139
**Reason:** Alpha testing revealed validation errors
140
**Impact:** Beta testing timeline pushed back
141
**Status:** Resolved - bugs fixed, back on track
142
143
**Evidence:** - Link to testing results
144
- Commit hash of bug fixes
145
- Updated project timeline
146
```
147
148
#### GitHub Projects Benefits:
149
- **Visual project board** with timeline and status tracking
150
- **Issue linking** to commits and evidence
151
- **Real-world project management** practice
152
153
---
154
155
## ⚠️ Don't Forget the Meta Log:
156
157
**Final log entry (C10-3-9)**: Evaluate all modifications you made to your initial project plan.
158
159
**Meta-Reflection Questions:**
160
161
- What **pattern** of changes occurred? (Mostly scope creep? Technical challenges? Good adjustments?)
162
- Were changes **reactive** (fixing problems) or **proactive** (improving quality)?
163
- Did modifications **improve** or **harm** project success?
164
- What does this tell you about your **original planning**?
165
166
This meta-analysis becomes crucial evidence for C10-4 effectiveness assessment.
167
168
---
169
170
## 📋 Documentation Checklist
171
172
**For C10-3 Assessment, Include:**
173
174
- 🔲 **Original plan** (baseline for comparison)
175
- 🔲 **All modifications** documented with dates
176
- 🔲 **Reasons for changes** clearly explained
177
- 🔲 **Impact analysis** (how changes affected other tasks)
178
- 🔲 **Change categories** (scope, timeline, technical, resources)
179
- 🔲 **Resolution status** (how issues were resolved)
180
181
---
182
183
**✨ Pro-tips:**
184
185
**Document as you go** - Don't try to recreate logs at the end
186
**Be specific** - "Testing revealed bugs" vs "Alpha testing found 3 validation errors in user input"
187
**Show impact** - Explain how each change affected the bigger picture
188
**Use timestamps** - Real dates and times show authentic tracking
189
**Link evidence** - Connect logs to actual project artifacts (commits, tests, etc.)
190
191
**🎯 Remember:**
192
193
C10-4 will use this tracking data to assess your plan's effectiveness, so **detailed logs = better C10-4 reflection**!
194
195
---
196
197
## Check Your Understanding
198
199
**1.** Which band does this log entry reach, and what would lift it one rung?
200
*"Week 4: extended coding by 2 days."*
201
202
>| ### Answer
203
>| Band 3–4 — it outlines the modification and nothing else. Adding *why* and its *impact* ("alpha testing found three input-validation errors; beta testing slipped a day but the build was stable") moves it into explanation, which is the 7–8 territory.
204
205
**2.** Why does the guide insist on real dates and timestamps rather than tidy round numbers?
206
207
>| ### Answer
208
>| Because the record has to be authentic, and your teacher reads commit dates from the server. A log reconstructed at the end contradicts the commit history it claims to describe.
209
210
**3.** What separates the meta-log from the entries above it?
211
212
>| ### Answer
213
>| The entries record; the meta-log judges. It looks across all the changes for a pattern — mostly scope creep? mostly technical? reactive or proactive? — and says whether the modifications helped or harmed the project.