Final Project
Collaboration Tools for Software Engineering and Academic Teams
Groups of four identify a specific, real collaboration pain point experienced by software engineering or academic teams and build a working tool that meaningfully reduces that friction. The tool must support interaction between at least two people. AI may be used where it genuinely adds value; its use must be justified, not assumed.
Project Theme and Criteria
Full details on the project theme, example problem areas, what the tool must do, and what counts as evaluation evidence are on the Project Theme and Criteria page.
What Is Graded
The project grades five things, in roughly equal importance:
- Problem specificity and evidence — did you identify a real, specific collaboration problem with evidence from real users?
- Collaboration process quality — does your DECISIONS.md reflect genuine team decision-making? Does your PR history show real review conversations?
- AI integration judgment — if you used AI, did you justify it, document it, and test it?
- Evaluation honesty — did you test with real users outside your team? Do you acknowledge what did not work?
- Documentation usefulness — could a new engineer understand and run this project from your README, DECISIONS.md, and CLAUDE.md alone?
Team Structure
Teams of 4 students. No fixed roles. The team self-organises around three structures: shared code ownership via branch protection, a rotating code steward, and a shared decision log.
Code Steward
The code steward is the designated PR reviewer for a period. During their period, the code steward is the only person who approves and merges PRs to main. Every team member must serve as code steward at least twice across the project. Teams self-determine when rotations happen.
DECISIONS.md
A file in the repository root recording every significant decision: what was chosen, why, what alternative was rejected, and who led the decision. Maintained from Week 3 onward via the PR template. Not a journal — a professional decision record.
Phases and Checkpoints
| Phase | Weeks | Primary focus | Checkpoint | Weight |
|---|---|---|---|---|
| Phase 1 — Discovery | 3–8 | Problem framing, user research, initial prototype, evaluation plan | CP1 due Wk 6 (async) | 5% |
| Phase 2 — Building | 9–12 | Walking skeleton, prototype build, test suite, peer review | CP2 due Wk 12 | 15% |
| Phase 3 — Synthesising | 13–15 | Refinement, evaluation evidence, final report, presentation prep | CP3 due Wk 15 | 12% |
Checkpoint Pages
- Team Formation — due Week 3 (see Upcoming Deadlines for the exact date)
- Checkpoint 1 (CP1) — Phase 1 — Discovery, due Week 6 (async)
- Checkpoint 2 (CP2) — Phase 2 — Building, due Week 12
- Checkpoint 3 (CP3) — Phase 3 — Synthesising, due Week 15
- Final Deliverables — due After Week 16 class (Dec 21)
Three Mandatory Collaboration Sessions
- Walking skeleton (Week 9, ~90 min outside class): all four students produce the thinnest possible end-to-end version that actually runs. Everyone touches the code.
- Merge day (Week 11, ~60 min outside class): resolve all outstanding PRs, handle merge conflicts, verify the main branch is stable before CP2.
- Demo rehearsal (Week 15, ~45 min outside class): every team member runs the demo without help. If any member cannot, the documentation is not good enough.
Minimum Verifiable Collaboration Outcomes
Verified at checkpoints via GitHub contributor graph, PR history, and DECISIONS.md.
By CP2 — per student
- At least 2 merged PRs with substantive code (not documentation or configuration only)
- At least 2 PR approvals as code steward, each with at least one substantive comment
- Designated as code steward at least once in DECISIONS.md
By CP3 — per student
- At least 1 additional merged PR with substantive code
- At least 1 PR that completed a full revision cycle: changes requested → updated → approved
- Designated as code steward at least twice total
Final Presentation (Week 16)
Lightning talk (90 seconds, strict): one sentence each on the problem, the tool, and the evidence it works. All 25 groups present sequentially.
Poster and demo session (40 minutes): groups man stations simultaneously. All members engage with visitors. Running demo, poster, and evaluation evidence must be visible.
Final deliverables (demo video + peer evaluation): due asynchronously after class — see the Final Deliverables page for the full breakdown and deadlines.