Deadlines
Weekly Progress Checks¶
Bus Factor – Lottery Factor
How many people could disappear before the project collapses? If the answer is “one,” your bus factor is dangerously low. Knowledge must be shared, code and docs published, so the project can survive sickness, vacations, or even someone “winning the lottery.” A team is only safe when no single absence can sink it.
Each week has concrete Expected Results Before This Week — think of these as your weekly homework.
At the beginning of the session, one or more teams are randomly selected to show what they achieved. Only work recorded in the team’s official GitLab project before the session counts. Good work earns points based on its quality and completeness; having nothing to show means some point deduction.
Why before the session?
If this week's work starts from a feature list, then that feature list needs to exist before class. Otherwise, your team cannot properly continue with the next activity.
Think like a workplace
Imagine your tutor as your boss checking the team's work before payroll: they do not expect perfection every week, but they do expect to see that work happened. GitLab is how you make that work visible.
The goal is simple: make steady progress, come prepared to continue working, and make your contribution visible.
Penalty Limits
Your team could lose no more points than it is defined in the Grading page.
Milestone Demos¶
Three milestone demos, 5 minutes per team. Treat them like board meetings: short, focused, results only.
Deadlines are real
Each milestone deliverable is due at 08:00 on Monday of the milestone week. The team demonstrates the submitted work during its regular class in the same week.
| Milestone | Deadline and Demo Week |
|---|---|
| Team building | Week 4 |
| Planning | Week 7 |
| Development | Week 13 / second to last week of the teaching period |
| Quality Assurance | Week 13 / second to last week of the teaching period |
Single source of truth
The repository is the official record of your project. Everything must live there: issues, README, and wiki pages. If it’s not in the repo, it doesn’t count. Slides, personal notes, or chat messages are useful for coordination, but they are not deliverables. Think of the repo as your team’s shared office: it’s where the work is stored, tracked, and verified. This habit is essential in real projects — without a single source of truth, knowledge gets lost, progress can’t be seen, and the team falls apart.
Late Work and Scoring¶
Each milestone has one fixed deadline and one scoring round. There are no extensions, additional deadlines, or later rescoring rounds. This prevents scoring periods from overlapping, makes the semester easier to plan for both students and tutors, and requires teams to practise realistic time management.
One deadline, one score
Only the work available in the team’s official repository at the deadline is assessed. The tutor records the score no later than two weeks after the deadline. Work completed later does not change the milestone’s score.
One poor milestone does not mean failing the course
There is no required minimum score for an individual milestone. A poor result—even for the first milestone—does not by itself mean that the student has failed the entire course.
Fix missing deliverables anyway
Teams are strongly encouraged to complete or repair missing deliverables after the deadline. Milestones usually depend on earlier work, so unresolved gaps can make later tasks harder or impossible. Use the weekly progress report to identify what still needs attention. These corrections support later work, but the original milestone will not be scored again.