Definitions

Definitions

The path

1. Choose. Prefer a project you use, so you can reproduce real problems.
2. Read the contributing guide, the code of conduct, the licence and open issues; search for duplicates.
3. Reproduce the problem locally and save the failing case.
4. Claim the issue with a short plan if the project asks.
5. Change one concern, add a test, keep the diff small.
6. Describe the change: issue link, why, what, how tested.
7. Respond to review without defensiveness; push fixes as asked.
8. Follow up on regressions and take the next small issue.

Results

1. The minimal fix is about half the size of the bloated one and is the only one with evidence.
2. Passing your own tests proves little if you edited them; run the reviewer's tests against your change.
3. A rename is a behaviour change for every importer.
4. The checker's blind spots are the interesting part: breaking changes and irrelevant tests need a human.
5. Heuristic rules produce false alarms; treat flags as questions.

Design rules

• One concern per pull request; split formatting, renames and features.
• Add a test that fails before and passes after, and say so in the description.
• Link the issue and state why the change is needed.
• Keep the diff free of debug output, unrelated edits and secrets.
• Follow the project's style and tooling (formatter, linter, commit format, sign-off).
• Write an imperative commit subject under about 72 characters, with a body for the why.
• Document new public behaviour where the project documents things.
• Disclose AI assistance when the project asks, and review every line yourself.
• Be patient and polite; review can take days.

Interview questions, with the follow-ups

Common mistakes

• A giant pull request that mixes a fix, a refactor and a reformat.
• No test, or a test that does not fail on the old code.
• Editing the old tests to make your change pass.
• Opening a pull request without reading the contributing guide.
• Leaving debug output or generated files in the diff.
• Ignoring review comments or arguing about style.
• Submitting code you do not understand, including AI-written code.
• Claiming credit for the project in an interview.

What the example does not do

• One toy repository: three hand-made branches, not a sample of real pull requests.
• Heuristic thresholds: the 400-line, 25 percent and 3-area limits are mine, and my formatting rule has a minimum hunk size and a similarity threshold I chose.
• No semantic check: the tool cannot tell a breaking change, a missing edge case or an irrelevant test.
• No social side: discussion, tone and maintainer preferences are not modelled.
• Optional real experiment (I did not run this): find a documentation or test issue in a project you use, make the change, and record how long review took and what the maintainers asked for.

For the curious Review cost is the currency

A minimal fix with a regression test changed 22 lines in 2 files; a bloated version of the same fix changed 51 lines in 3 files because it also reformatted a module, renamed a function and left a debug print. My checker flagged the churn and the leftover print, but one flag was a false alarm and it could not see the breaking rename. The repository is a tiny fictional one, so the absolute numbers prove nothing, only the ratio of fix to noise.

What you must be able to say (one page)

• A good first contribution is small, tested and linked to an issue. My path: choose a project you already use; read its README, contributing guide, code of conduct and licence; reproduce the problem; say you are working on it; make one change with a test that fails before and passes after; describe what, why and how you tested; respond to review quickly; then follow up. This path is my own summary of common practice.
• Review cost is the currency. In my real-git exercise on a toy library, a minimal fix with a regression test changed 22 lines in 2 files (12 in the source file). A "bloated" version of the same fix changed 51 lines in 3 files because it also reformatted a module (34 of the lines), renamed a function and left a debug print. The reviewer has to read all of it. The toy repository is tiny, so absolute numbers prove nothing; the point is the ratio of fix to noise.
• Show that your test catches the bug. Real pytest runs in the exercise: the original suite passed (3 tests) on the buggy code; the new tests failed on main (2 failed) and passed on the fixed branch (5 passed). A fix with no test passed the good branch's tests too (5 passed), so it was correct but unproven; a maintainer cannot tell without writing the test themselves.
• Renames and reformatting are separate pull requests. The bloated branch's rename of pick made the good branch's tests fail to import it (1 error). It passed its own suite (3 tests) only because it had edited the old tests to follow the rename, and none of them covered the bug.
• A checker finds what reviewers ask about, not whether you are right. My heuristic checker flagged the minimal fix: none; the no-test fix: no_tests; the bloated change: formatting_churn, debug_leftover and undocumented_api. Two limits: the third flag was a false alarm (a rename is not a new function), and the checker could not see the breaking rename or that the touched tests did not cover the bug. My first version of the formatting rule also missed the churn entirely (it demanded exact equality, and one rename in the same hunk broke it) until I used token similarity.
• Pick a project by evidence of use and activity. Usage evidence tells you where a project's value (and its pain) is. Check recent releases, the ratio of open to closed issues and how quickly maintainers answer.
• Know the licence and the rules. "Open source" is contentious for models: some argue a model is open only if its training data is public, so check what a model's licence allows. There are also copyright disputes over training data. A contributing guide may also require a sign-off line on each commit or a contributor agreement, and may have a policy on AI-assisted contributions. I did not verify any specific project's rules in this session; read the project's own files.
• Be explicit about AI assistance. If you used an AI tool, understand every line you submit, run the tests yourself and follow the project's stated policy. Maintainers' time is the scarce resource.
• Interview value: a merged change shows you can read unfamiliar code, work within standards and take review. State precisely what you changed and what you learned; do not claim ownership of the project.
• Honest limits: the exercise is a fictional toy library; the checker's thresholds are my own; I did not contribute to a real project in this module.