<!-- 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. --> # Tracking Plan Changes — Annotated Gantt Charts and Project Logs *The two instruments C10-3 is marked from, and the meta-log that turns them into a judgement. Read it before class write 3.* > [!NOTE] > **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. ```mermaid flowchart LR G["Annotated Gantt<br/>baseline vs actual"] --> M E1["Log entry<br/>date · what changed · why<br/>impact · who decided · evidence"] --> M E2["Log entry"] --> M E3["Log entry"] --> M 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"] ``` *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.* ## What is this? By reviewing **how and why your plan changed**, you gain evidence of adaptability and critical decision-making—not just task tracking. **Purpose:** Document project modifications with reflective analysis for C10-3 assessment. --- ## 🎯 Choose Your Tracking Method ### Option 1: Traditional Approach - **📊 1. Annotated Gantt Chart** - 📝 2. Project Log File ### Option 2: GitHub Approach - 📊 1. GitHub Projects (Gantt view) - 📝 2. GitHub Issues (tracking) --- ## 📊 Annotated Gantt Chart Guide ### What to Show: - 🔹 **Original timeline** (from Unit 3) vs **actual timeline** - 🔹 **Task modifications**: Added, removed, or changed tasks - 🔹 **Duration changes**: Tasks that took longer/shorter than planned - 🔹 **Milestone shifts**: Deadlines that moved - 🔹 **Resource adjustments**: When you needed help or changed priorities ### How to Annotate: #### Traditional Method (GanttProject/Excel): ``` Annotation Examples: • "Extended coding by 3 days - alpha testing revealed more bugs" • "Added validation task - requirements changed after client feedback" • "Moved documentation earlier - needed for beta testing prep" • "Reduced UI design time - focused on functionality first" ``` #### GitHub Projects Method: - Use **milestone descriptions** to explain changes - Add **timeline comments** on project board - Use **labels** to categorise change types (scope, technical, timeline) - **Project notes** explain major modifications --- ## 📝 Project Logs Guide ### What to Track: - 🔹 **Date and time** of each change - 🔹 **What changed** (task, deadline, scope, resources) - 🔹 **Why it changed** (testing results, technical issues, feedback) - 🔹 **Impact** (how it affected other tasks) - 🔹 **Decision maker** (you, teacher feedback, user input) ### Log Categories: - **Scope changes**: New/removed features - *Did this add value or cause delay?* - **Timeline adjustments**: Extended/compressed tasks - *Did this make the project finish earlier/later?* - **Technical issues**: Bug fixes, tool problems - *Did this improve solution quality?* - **Resource changes**: Help needed, priority shifts - *Did this make development more efficient?* - **User feedback**: Changes from testing - *Did this better meet user needs?* - **AI assistance**: When AI tools helped/hindered development progress - *Did this speed up or complicate development?* ### 💭 Add Reflection Checkpoints: After major milestones (alpha testing, beta testing, major feature completion), write **1-2 reflective sentences**: - *"After alpha testing, I realized my original timeline was too optimistic for validation work"* - *"Beta feedback showed users needed simpler navigation - good thing I built this modularly"* ### 📸 Include Evidence Annotations: For 2-3 key log entries, add supporting evidence: - **Screenshot**: Before/after interface changes - **Code snippet**: Key bug fix or improvement - **Timeline visual**: Gantt chart section showing the change - **Caption**: *"This validation fix prevented major user errors"* ### Option 1: Traditional Log File #### Simple Log Template: ``` WEEK 4 REVIEW (Post-Alpha Testing): DATE: 2025-08-12 CHANGE: Extended coding phase by 2 days REASON: Alpha testing found validation errors IMPACT: Beta testing delayed by 1 day, but solution quality improved DECISION: Worth the delay to fix critical bugs EVIDENCE: [Link to testing results, commit #a3b2c1] REFLECTION: Original timeline was too optimistic for validation work WEEK 6 REVIEW (Post-Beta Testing): DATE: 2025-08-18 CHANGE: Added user tutorial feature REASON: Beta testers confused by interface IMPACT: Extra 3 days development, but much better usability scores DECISION: Essential for user adoption EVIDENCE: [Screenshots of old vs new interface] REFLECTION: Should have planned for user guidance from the start ``` --- ### Option 2: GitHub Issues Method #### Issue Structure: ``` Title: [TIMELINE] Extended coding phase Labels: timeline-change, technical-issue Milestone: Week 5 Development Description: **What Changed:** Coding phase extended by 2 days **Reason:** Alpha testing revealed validation errors **Impact:** Beta testing timeline pushed back **Status:** Resolved - bugs fixed, back on track **Evidence:** - Link to testing results - Commit hash of bug fixes - Updated project timeline ``` #### GitHub Projects Benefits: - **Visual project board** with timeline and status tracking - **Issue linking** to commits and evidence - **Real-world project management** practice --- ## ⚠️ Don't Forget the Meta Log: **Final log entry (C10-3-9)**: Evaluate all modifications you made to your initial project plan. **Meta-Reflection Questions:** - What **pattern** of changes occurred? (Mostly scope creep? Technical challenges? Good adjustments?) - Were changes **reactive** (fixing problems) or **proactive** (improving quality)? - Did modifications **improve** or **harm** project success? - What does this tell you about your **original planning**? This meta-analysis becomes crucial evidence for C10-4 effectiveness assessment. --- ## 📋 Documentation Checklist **For C10-3 Assessment, Include:** - 🔲 **Original plan** (baseline for comparison) - 🔲 **All modifications** documented with dates - 🔲 **Reasons for changes** clearly explained - 🔲 **Impact analysis** (how changes affected other tasks) - 🔲 **Change categories** (scope, timeline, technical, resources) - 🔲 **Resolution status** (how issues were resolved) --- **✨ Pro-tips:** **Document as you go** - Don't try to recreate logs at the end **Be specific** - "Testing revealed bugs" vs "Alpha testing found 3 validation errors in user input" **Show impact** - Explain how each change affected the bigger picture **Use timestamps** - Real dates and times show authentic tracking **Link evidence** - Connect logs to actual project artifacts (commits, tests, etc.) **🎯 Remember:** C10-4 will use this tracking data to assess your plan's effectiveness, so **detailed logs = better C10-4 reflection**! --- ## Check Your Understanding **1.** Which band does this log entry reach, and what would lift it one rung? *"Week 4: extended coding by 2 days."* >| ### Answer >| 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. **2.** Why does the guide insist on real dates and timestamps rather than tidy round numbers? >| ### Answer >| 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. **3.** What separates the meta-log from the entries above it? >| ### Answer >| 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.