in CDIO Project-Based Courses

Using Pull Requests to Make Collaboration Visible

Dr. Helga Ingimundardóttir helgaingim@hi.is

22^nd International CDIO Conference · June 24^th, 2026

I’m Helga Ingimundardóttir from the University of Iceland — this is the second of two talks this week.

• Yesterday: why we redesigned a Business Intelligence course and what the design looks like
• Today: the technical side — how pull requests function as assessment infrastructure
• Relevant if you do project-based or team courses where collaboration matters

The problem

Final deliverables hide process

Who did what, how decisions were made, and how feedback was handled is invisible in the final product

Peer interaction is difficult to audit

Retrospective reconstruction of who reviewed, commented, or contributed is unreliable

Feedback resets instead of accumulating

Each assignment starts from scratch — prior issues are not carried forward

The issue is not lack of activity — it is lack of visibility.

Project-based courses are widely used in CDIO — and we care about collaboration, reasoning, and responsiveness to feedback.

But in practice, assessment still prioritizes final artifacts — reports, code, presentations.

• The final deliverable hides most of what matters
• Peer interaction is impossible to reconstruct after the fact
• Feedback resets between tasks instead of building up

The issue is not lack of activity — it is lack of visibility.

Why pull requests

What a PR is

A structured proposal to change shared work: rationale, peer review, discussion, and explicit approval before merging

Why it matters for assessment

• reasoning becomes visible in the PR description
• contribution becomes attributable — commits and reviews are signed
• critique is captured in review comments
• responses to feedback are auditable over time

Directly transferable

Industry-standard workflow — students practice what they will immediately use after graduation

A pull request — PR — is a structured proposal to change shared work.

It includes a rationale, gets reviewed and discussed, and is explicitly approved before merging.

• Reasoning becomes visible in the PR description
• You can see who did what and when
• Critique is captured in review comments
• Responses to feedback are auditable over time

And critically — this is industry-standard practice. Students are not learning a course tool; they are learning the workflow they will use on day one.

Assessable behaviors made visible

Required practices

• focused PRs with clear intent
• at least two substantive reviews
• explicit responses to all comments
• merge only after review

Observable evidence

• authorship and co-authorship
• depth of critique (no LGTM or )
• handover quality
• documentation updates

We define specific required practices — not just “use GitHub.”

• Focused PRs with clear intent
• At least two substantive reviews — actionable feedback, not just approval
• Explicit responses to all comments
• Merge only after review

Assessment then uses observable evidence: authorship, critique depth, follow-up, handover quality.

The diagram shows a real structure: three students, feature branches, orange arrows are PRs — each merge is a reviewable, traceable event.

Scaffolded progression

across courses

Information Engineering (IE)

mandatory in Industrial Engineering

• 20–25 students, 6–7 small teams
• 2nd year undergraduate
• new repository each cycle
• focus: learning the tools

Business Intelligence (BI)

elective in Industrial Engineering & Data Science

• 10–15 students, 2 large teams
• 3rd year undergrad & 1st year masters
• single persistent repository
• focus: tooling supports advanced project work

From learning the workflow to using it as infrastructure for something more ambitious.

This is implemented across two courses with a deliberate progression.

• In Information Engineering: focus is learning the tools — small teams, repeated practice, new repositories each cycle
• In Business Intelligence: students are assumed fluent — one persistent repository across the entire semester

This is important: you don’t want students spending cognitive load on Git when they should be focused on the domain problem.

Feedback carry-forward

Business Intelligence — where GitHub becomes assessment infrastructure

Cumulative assessment

• unresolved PR comments remain active
• later work is checked against prior feedback
• capstone evaluation includes earlier issues

Effect

• continuity across assignments
• accountability — issues can’t be ignored
• coherence in the final product
• mirrors professional practice

With a single persistent repository, feedback doesn’t reset — it carries forward.

• Unresolved PR comments stay visible — later work is evaluated against them
• The capstone includes everything — students cannot simply move on
• They have to revisit and resolve — and that revision is itself assessable

Much closer to how professional work actually operates.

Indicative evidence

Rubric shared across both IE and BI

	Outstanding	Good	Developmental
GitHub usage	Branches well organized, logical names. Commits coherent and descriptive. Documentation complete.	Branches used but naming inconsistent. Commits mostly coherent. Documentation present but incomplete.	Branches absent or unclear. Commits inconsistent, little structure. Documentation unclear or missing.
Teamwork	All members actively contribute. Responsibilities distributed. Decisions shared through review.	Most members participate, contributions uneven. One or two lead while others review.	Work largely carried by one individual. Participation minimal or uneven.

Calibration

• same dimensions, increasing expectations
• signals what Capstone requires
• early grading normalized to “very good”

Observed trend

• GitHub usage improved over repeated cycles
• teamwork & participation improved more strongly

Design case, not a controlled study — but the signal is consistent.

• Early grading is deliberately lenient — students are still learning the workflow
• Over cycles: GitHub use improves, teamwork improves more strongly
• Students see the capstone rubric from week one — no surprises

What this makes visible

Transferable principles for CDIO-aligned, project-based courses.

Visible process

Collaboration, reasoning, and iteration are observable — not just the final product

Cumulative feedback

Unresolved issues stay visible — feedback accumulates instead of resetting

Individual accountability

Contributions are attributable without fragmenting teamwork

Professional workflow

Students practice industry-standard tools in routine coursework — directly transferable

Credibility

Reproducible, documented work builds trust with industry partners

Assessment architecture

This is a design choice, not a tool choice — the structure comes first

Transferable

The same logic applies to any project-based course where collaboration matters

Uncomfortable by design

Reviewing peers, documenting work, responding to feedback — unfamiliar at first

Valued after completion

Graduates say it’s where they learned the most — the hands-on experience is real

These principles apply beyond software and data courses — the domain matters less than the design.

• Better to encounter critical feedback and visible work first in a course than on the job
• The contribution is an assessment architecture — not a tool recommendation

Questions?

Dr. Helga Ingimundardóttir

helgaingim@hi.is

0000-0002-2780-3546

tungufoss

University of Iceland

• Isn’t this a lot of overhead? — Yes, initially. But it decreases quickly and assessment becomes much easier and more transparent
• What about students with no GitHub experience? — We scaffold earlier in the curriculum; in later courses we assume fluency
• Does this scale? — It can, but requires coordination around review quality; the visibility actually helps manage larger groups
• Is this just about GitHub? — No. GitHub is the enabler. The contribution is the assessment architecture
• Yesterday’s talk (Session 8A) covers the course design side — industry engagement, TBL structure, and reasoning for redesign