Open-source contributions rubric
This page describes the earlier fourteen-week layout and is being rewritten; where it differs, the syllabus applies.
This rubric is the marking contract for the open-source contributions. They are worth 30
points in two samples: C1, the warm-up contribution, is worth 8 and C2, the substantial
contribution, is worth 22. The project kit's open-source contributions guide,
capstone/kit/open-source-contributions.en.md, explains how to choose a project, do the work
and submit it.
Both samples are marked on the same evidence as your other open work, the explanation check, verification evidence and one AI-use note, and on your upstream collaboration. Three rules apply to every row:
- Merge and replies do not count. Marks never depend on whether the pull request is merged, or, for a pull request opened on time (see Late opening), on whether a maintainer replies or reviews it.
- The course-hosted route is marked the same way. On that route, "upstream" means the course practice repository and the TA who reviews it as a maintainer would. The rubric, the dates and the maximum mark are the same.
- Model use is optional. Work done without a model, or on the replay route, uses the same rows and reaches the same maximum mark.
Purpose
This document defines the evidence and point boundaries the teaching team uses for C1 and C2.
Records
Each sample has one work record. It links the issue and pull request (or the course-hosted equivalent), the head commit at opening, one line for each later push, the launcher outputs before and after your change, your summary of the review comments and what you changed in response, your explain-gate answers and your AI-use note. Link each claim to one evidence ID. One evidence ID supports one criterion; repeating a citation never earns extra points. The TA records the evidence IDs, the head commit marked and each criterion score on the score sheet.
Review
A second calibrated reviewer checks the evidence mapping, arithmetic and boundary rules before the contributions score is released. The TA who reviews your pull request as a maintainer, on the course-hosted route or by the review date below, never marks that sample. Appeals follow the assessment and appeals process.
How to use the tables
Award the points in a row only when the listed evidence is present, attributable to you and verified. Each sample is marked on the last head you pushed before its deadline. Only your own commits count; commits that maintainers or others push to your branch do not. Scores are whole or half points, and each row lists every score it allows: full credit, the partial-credit values in its partial column (from lowest to highest), or zero. A score is not a prediction of effort and never depends on code volume, commit count, the project's popularity or whether an assistant produced text.
Dates for opening and review
"End of week N" means Friday 23:59 course time. Every day count is in calendar days. The dates apply to every pull request in the sample: C1, and each C2 pull request.
| Sample | Open ready for review by | Review date | Deadline |
|---|---|---|---|
| C1 | End of week 5 | Monday of week 6 | End of week 6 |
| C2 | End of week 11 | Monday of week 12 | End of week 13 (Friday 23:59 course time) |
- Opening. Open each pull request ready for review by its opening date. Ready for review means it contains the change being marked. Note the head commit at opening in your work record. A pull request whose opening head does not contain the change counts as opened late.
- Review date. The review date is 3 days after the opening date. A pull request with no human maintainer review by then gets a TA review, posted by the review date in your course submission and never in the public project; the TA never contacts the project's maintainers. Only a human maintainer's or the TA's review counts. Comments from bots, CI or other contributors may be answered, but they never stop the TA review or lower a mark.
- Cutoff. Revision after review is judged on the comments received by the review date. Comments that arrive later may be answered and never lower this kind. For a pull request opened on time, a later human maintainer or TA review that is fully answered raises weak to sound. If the TA review is late, your review date and deadline move by the same number of days, but never past the C2 deadline.
- Later pushes. You may push anything after opening: review responses, rebases, CI and format fixes, a sign-off, or fixes for problems you find yourself. The sample is marked on the final head. Give one line per later push in your work record, saying what it changed and why. A follow-up pull request that a maintainer asks for counts as a review response.
- Late opening. A pull request opened late is marked the same way but gets no TA review. If no human maintainer review arrives by the review date, revision after review is missing. Comments that arrive after the review date do not raise it.
- Course-hosted route. The same dates apply, and the TA is the maintainer.
If your issue disappears
If your issue is fixed by someone else first, or stops being feasible (for example, the project changes its licence or AI rules, or its tests no longer fit the launcher's limits), tell the instructor. You choose, without penalty: the instructor approves a substitute issue with dates that restore the working time you lost, or you keep the work and it is marked against the part of the agreed scope that was still achievable. A pull request rejected on direction, timing or project policy has no effect on the mark.
Explanation check answers
The explanation check has four questions: what changed, why, which inputs are most likely to fail and what you verified yourself. An answer is sound when it is concrete, matches the marked diff and claims as verified only what the evidence shows. For C2 in two pull requests, a question counts as sound only when its answer is sound in both pull requests' records. If any answer claims a verification that the evidence contradicts, the whole row scores 0, whatever the other answers show.
Upstream collaboration evidence
The collaboration row looks at three kinds of evidence. Each kind is sound, weak or missing:
| Kind | Sound | Weak | Missing |
|---|---|---|---|
| Issue discussion | Before you started, you said on the issue, or where the project's guide asks, what you planned, and you updated the discussion when the plan changed. | The discussion exists but came only after the work was done, or does not say what you planned. | No discussion. |
| Revision after review | Every review comment received by the review date is answered, either with a change verified by a new launcher run or with a reasoned reply that gives evidence for why your change stands. A review with nothing to answer counts as sound. For a pull request opened on time, a later human maintainer or TA review that is fully answered raises weak to sound; for a pull request opened late, comments after the review date do not raise this kind. | Some comments received by the review date are answered, or answers lack the new launcher run or the evidence. | No comment received by the review date is answered, or no review arrived by the review date. |
| Contribution rules | The pull request meets every requirement of the project's contribution guide that applies, such as its template, commit message format and rules for disclosing AI use. | One requirement other than AI disclosure is not met. | Two or more requirements are not met, or AI use is not disclosed where the project requires disclosure. |
This kind leaves out requirements already scored in another row, such as the tests the project asks for, which the C1 complete-fix row and the C2 verification row score. A contributor licence agreement (CLA) or a sign-off is never scored. If a project requires one you will not sign, choose another project or take the course-hosted route.
Score each kind sound 2, weak 1 and missing 0, and add the three to a collaboration total from 0 to 6. C2 scores that total. C1 converts it:
| Collaboration total | 0–1 | 2 | 3–4 | 5 | 6 |
|---|---|---|---|---|---|
| C1 points | 0 | 0.5 | 1 | 1.5 | 2 |
C1 — warm-up contribution (8 points)
C1 is one small, complete fix to a defect, a test or documentation, due at the end of week 6.
| Criterion | Points | Full credit | Partial credit | Zero |
|---|---|---|---|---|
| Complete fix within the C1 scope | 2 | The pull request resolves the issue it names with one small fix, carries the tests or checks the project asks for, and contains no unrelated changes. | 1: the fix resolves the issue, but a test or check the project asks for is missing, or the change includes unrelated edits. | 0: no pull request at the marked head, or the change does not address the issue it names. |
| Verification evidence | 2 | The launcher output of the project's relevant tests or checks before and after the change is linked at the marked head, with failing-first evidence: when the change touches code, a test fails for the reported reason before the change and passes after it; when the contribution adds a test for code that already works, the test fails on a deliberately broken version of that code, which you then revert; when the contribution is documentation only, the project's documentation build or link check runs before and after the change, or you link the rendered diff of the corrected page. | 1: before-and-after runs exist, but the failing-first evidence is missing, or one run cannot be tied to the marked head. | 0: no runnable verification evidence, or the evidence is falsified. |
| Explanation check | 1.5 | All four answers are sound. | 0.5: two sound answers. 1: three sound answers. | 0: one sound answer or none, or a contradicted verification claim. |
| Upstream collaboration | 2 | Total 6: all three kinds are sound. | 0.5: total 2. 1: total 3–4. 1.5: total 5. | 0: collaboration total 0–1. |
| AI-use note | 0.5 | One AI-use note for the work, reused by its ID, names the tool and purpose, or states that no AI was used. | No partial credit: a note that omits the tool or the purpose scores 0. | 0: no AI-use note. |
C2 — substantial contribution (22 points)
C2 is one approved feature or non-trivial fix, in one or two pull requests, due at the end of week 13 (Friday 23:59 course time). Both pull requests are marked together as one sample. The C2 proposal is not scored separately: the scope and acceptance cases the instructor approves before week 7 are what the rows below are marked against, including any later change the instructor approves.
| Criterion | Points | Full credit | Partial credit | Zero |
|---|---|---|---|---|
| Complete change within the approved scope | 5 | The approved feature or fix reaches its acceptance cases across normal, boundary and failure inputs, within the approved scope, with callers and data handling preserved. | 1: a failing acceptance test or reproduction for the change exists at the marked head. 2: the main path is partly demonstrable. 3: the main path and one verification class work. 4: all but one required path or explanation is verified. | 0: no failing acceptance test, reproduction or demonstrable change at the marked head, whether or not the proposal was approved. An approval or proposal without this evidence earns 0. |
| Verification evidence | 6 | Launcher outputs of the project's relevant tests before and after the change are linked at the marked head. Tests fail for the reported reason before the change and pass after it, each approved acceptance case is checked, and every change pushed after review is verified with a new launcher run. | 2: before-and-after runs exist, but the tests that fail first or the acceptance-case checks are missing. 4: all evidence classes are present, but one acceptance case or one pushed change lacks a launcher run. | 0: no runnable verification evidence, or the evidence is falsified. |
| Explanation check | 4 | All four answers are sound. | 1: one sound answer. 2: two sound answers. 3: three sound answers. | 0: no sound answer, or a contradicted verification claim. |
| Upstream collaboration | 6 | Total 6: all three kinds are sound. | The collaboration total from 1 to 5. | 0: collaboration total 0. |
| AI-use note | 1 | One AI-use note for the work, reused by its ID, names the tool and purpose, or states that no AI was used. | 0.5: the note is present but omits the tool or the purpose. | 0: no AI-use note. |
Evidence and boundaries
Contributions go only to public repositories or the course-hosted practice repository. Code from a residency, an employer or a partner company's internal systems never supplies evidence. Participant material, keys and credentials never appear in the evidence. Oral-defense marks, code lines, commit counts, rankings, awards, the project's popularity and a maintainer's reply or opinion never supply contribution points.
The teaching team records the contributions mark after reviewing the submitted evidence. Keep an unresolved or contradictory item pending; do not turn missing future work into zero by assumption.