Open-source contributions
Make four contributions across two repositories, worth 30 marks in total. In each repository, start with a small onboarding fix, then make a substantive change. Move to the second repository after contribution 2. You practise entering unfamiliar codebases, verifying changes, and following their contribution rules (LO4, LO5, LO7, LO9).
| Contribution | Due | Repository | Scope | Marks |
|---|---|---|---|---|
| 1 | Week 4 | First | Small, complete onboarding fix | 5 |
| 2 | Week 8 | First | Substantive change | 10 |
| 3 | Week 9 | Second | Small, complete onboarding fix | 5 |
| 4 | Week 12 | Second | Substantive change | 10 |
Deadlines are Sunday at 23:59 in the due week. A small fix might repair a defect, test or documentation example. A substantive change solves a larger problem with a bounded scope and verifiable acceptance cases. Read the repository's rules before proposing work.
Find a repository and submit your preferences
In week 2, rank your preferences on the volunteer form. The teaching team assigns the first repository and arranges the move to a different repository after contribution 2. At most five students work on a repository at one time.
The list prioritizes public open-source projects maintained or used by partners, with other active projects added. Every listed repository needs an OSI-approved licence, contribution guidelines, an AI-use policy that permits the planned work, and no CLA that assigns copyright. You may propose another repository for approval against these conditions. Do not start counted work there before approval.
The teaching team checks these conditions, records whether there is a partner maintainer contact, and publishes the list and allocation instructions. Contacts are not invented: the list records only people who have actually agreed to act as contacts.
| Where to find or send things | Publication or action |
|---|---|
| Approved repositories and contribution-guide links | The teaching team publishes the approved public repository list before Week 2. |
| Partner maintainer contact for each repository, or no contact | The teaching team confirms each partner maintainer contact, or records that there is none, before Week 2. |
| Week 2 preferences and volunteering | The teaching team publishes the volunteer form and allocation channel before Week 2 preferences are due. |
| A repository or issue you propose; a scope change | The teaching team publishes the approval channel before students propose a repository, issue or scope change. |
| Four submissions and requests for TA acceptance review | The teaching team publishes the submission channel and TA review-request route before the first contribution deadline. |
| Pseudonymous account or course-hosted equivalent | The teaching team publishes the private identity and equivalent-route channel before the first contribution is submitted. |
Do not make a marked contribution to a repository owned by your own residency employer. Tell the teaching team privately if an allocation would cross that boundary so it can assign a different repository.
Make and verify each change
- Read and discuss. Read the licence, contribution guide, AI rules and relevant issue. Follow the project's process for agreeing the scope before starting unwanted work.
- Reproduce. Record the starting revision and a check that fails for the issue you intend to fix. For documentation, use an executable example or a repeatable check of the documented behaviour. Agree an appropriate check with a TA if necessary.
- Generate and inspect. Use the permitted assistance to make a small change. Inspect the diff and affected callers yourself; do not submit unexamined generated output.
- Verify. Run the check again and the relevant existing tests. Preserve the result that fails before the change and passes after it, with revisions and commands.
- Submit and respond. Follow the upstream PR, sign-off and disclosure process. Respond to review, verify revisions, and record what you changed or why the evidence supports retaining a decision.
For each contribution submit the issue and PR links, the submitted revision, the before and after verification results, and a brief explanation answering these four questions:
- What changed?
- Why was that change needed?
- Which inputs or conditions could break it?
- What did you personally verify?
Add one AI-use note to the existing work record, reused by ID, or state that no AI was used. Submit the project's required artifacts and these evidence links through the course submission channel; no general conversation export or separate disclosure file is required.
Completion and quality
For a repository with a partner contact, a merged PR satisfies the completion condition. If the repository has no contact, or the maintainer has not replied within seven days, a TA instead makes an acceptance review against that project's contribution guidelines. Request that review with the PR, its contribution-guide link, and the dated request or discussion showing the lack of reply. Respond to the TA's findings as you would to upstream review. Your mark does not depend on the maintainer replying.
Completion does not remove the quality requirement. Low-quality AI-generated output earns zero marks, as judged by the maintainer or TA. Each contribution needs the failing and passing verification pair and your own answers above. Neither a merge alone nor a polished explanation replaces that evidence. If the issue becomes infeasible or its rules change, tell the teaching team before continuing and agree a new scope.
Boundaries and rights
- Public upstream only: external contributions go only to public repositories. Residency, employer and partner-internal code never enters the course or a model.
- Follow the project's AI rules: disclose assistance as it requires. If it disallows your planned use, change the workflow or repository; do not conceal AI use.
- Identity: use a pseudonym where the project permits it. The teaching team keeps the account-to-student mapping privately. Check what names and email addresses a sign-off or agreement would expose before signing.
- Copyright: you are never required to sign a CLA that assigns copyright. A CLA granting a non-exclusive licence is your choice after reading it.
- Equivalent route: if you do not want to publish publicly or sign a CLA or DCO, you may choose the course-hosted equivalent without giving a reason. Tell the teaching team before publishing or signing. It supplies non-public practice repositories for the same four contributions, small then substantial in each of two repositories, with a TA acceptance review, the same rubric and the same maximum marks.
- Keep private material private: do not send participant material, credentials, teacher files or another student's unpublished work to a model or upstream. Follow the project's private reporting process for a security problem and tell the teaching team; course attack payloads and seeded defects never go upstream.
These contributions are separate from the term project. The syllabus defines their marks and rules.