{"course":{"slug":"ai-careers","title":"Working in AI","url":"https://addaly.com/learn/ai-careers","level":"beginner","track":"work"},"lesson":{"slug":"open-source-as-a-door","title":"A merged pull request as evidence","url":"https://addaly.com/learn/ai-careers/open-source-as-a-door","position":38,"of":85,"minutes":9,"answer":"A merged pull request proves you can work inside someone else's codebase and take review, and the reproduction of a bug is often a more welcome contribution than the fix.","keyIdea":"A merged pull request proves you can work inside someone else's codebase and take review, and the reproduction of a bug is often a more welcome contribution than the fix."},"body":{"format":"markdown","text":"## What it actually proves\n\nA portfolio project proves you can build something alone, on your own terms, with no one disagreeing. A merged pull request into somebody else's repository proves four different things, and they are the things employers are actually unsure about:\n\n- You can read a codebase you did not write.\n- You can follow conventions you did not choose.\n- You can take review comments without defending yourself.\n- Somebody with no obligation to you judged your work good enough to keep.\n\nThat last one is the only external validation available to a person with no job history. It is worth a great deal more than a certificate and it costs nothing but weeks.\n\n## The route that works, and the one that does not\n\nThe common advice (filter a famous repository by \"good first issue\") mostly fails. Those issues are claimed within hours by hundreds of people doing the same thing, and maintainers of large projects are drowning.\n\nThe route that works starts from use:\n\n1. **Use a mid-sized tool regularly.** Something with fifty to five thousand stars, an active maintainer and real users. The libraries around your own stack: a dbt package, a data-quality tool, a small Python client for an API you use.\n2. **Hit a real problem.** You will, within weeks. The documentation is wrong, an error message is unhelpful, a function fails on a valid input, the installation instructions skip a step on Linux.\n3. **Reproduce it minimally.** Cut it to the smallest script that shows the behaviour, with versions and the exact error. **This is the contribution.** Maintainers are short of time, not ideas, and a clean reproduction is often more valuable than the fix.\n4. **Open an issue with that reproduction**, and ask whether a pull request would be welcome and how they would prefer it solved. Asking first prevents the most common heartbreak, which is a week of work rejected on design grounds.\n5. **Send a small pull request.** One change. Tests if the project has them. The project's own formatting, not yours.\n\nDocumentation counts. A pull request fixing an install guide that is wrong on Ubuntu is a genuine contribution, is usually merged fast, and is a real name in a real repository.\n\n## Etiquette, learned the cheap way\n\n- **Do not reformat files.** A diff of 400 lines where 3 are the fix will not be read.\n- **Do not refactor on the way past.** It reads as a stranger rearranging someone's kitchen.\n- **Match the surrounding style**, even where you disagree with it.\n- **Reply to review comments within a day or two.** Abandoned pull requests are the most common outcome and the most annoying one for maintainers.\n- **Accept a \"no\" gracefully.** Every maintainer remembers who argued, and it is a small world.\n- **Read `CONTRIBUTING.md` first.** Roughly half of contributors do not, and it shows immediately.\n\n## Using it in a search\n\nOne merged pull request into a tool the interviewer has heard of is worth mentioning in the first minute of a conversation. Better still, describe the review: \"the maintainer pushed back on my approach because it broke Windows paths, and the second version handled both.\" That single sentence demonstrates receiving criticism, which is the trait most interview processes are secretly probing for and the hardest to fake.\n\n## The honest limitations\n\nThree, all real.\n\n**It is slow and outside your control.** Maintainers are volunteers with jobs. A pull request can sit for three months and then be closed with \"we are going a different direction\". This is not personal and it is not rare.\n\n**Quantity is visible and worthless.** The annual contribution events produced a flood of trivial pull requests, and maintainers now treat one-line typo fixes from strangers with weariness. Two substantive contributions to one project you actually use beat forty scattered ones, and reviewers can tell the difference instantly.\n\n**It does not convert directly into jobs.** Almost nobody is hired because of a pull request. It works by making you credible in a conversation you obtained some other way, and by teaching you how professional code review feels before your first day rather than during it."},"check":{"question":"A learner wants a first open-source contribution. Which approach has the best chance of ending in a merge?","options":[{"text":"Filter a well-known machine learning framework by \"good first issue\" and claim the first unassigned one.","correct":false,"tempting":"Enters the most heavily contested queue in open source, where issues are claimed within hours and maintainer attention is scarcest."},{"text":"Fork a popular library, refactor a module they find untidy, and submit it as an improvement.","correct":false,"tempting":"Sends an unrequested large diff, which maintainers decline on principle because they inherit the maintenance of a change they did not ask for."},{"text":"Notice that a tool they use daily fails on a valid input, cut it to a minimal reproduction with versions, open an issue, and ask how the maintainer would prefer it fixed before writing code.","correct":true},{"text":"Submit typo corrections to twenty repositories to build a visible contribution history quickly.","correct":false,"tempting":"Produces volume that maintainers now actively distrust, and demonstrates none of the four things a reviewer is trying to establish."}]},"prev":{"slug":"writing-in-public","title":"Publishing, and the inbound it creates","url":"https://addaly.com/learn/ai-careers/writing-in-public"},"next":{"slug":"the-bridge-job","title":"The job next to the data","url":"https://addaly.com/learn/ai-careers/the-bridge-job"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'A merged pull request as evidence', in Working in AI. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/ai-careers/open-source-as-a-door (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"A merged pull request as evidence","courseTitle":"Working in AI","module":{"index":4,"slug":"getting-seen","title":"Getting seen: the routes that put a person in front of your work"},"answer":null,"keyIdea":"A merged pull request proves you can work inside someone else’s codebase and take review, and the reproduction of a bug is often a more welcome contribution than the fix.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"what-it-actually-proves","runs":[{"text":"What it actually proves"}]},{"t":"p","runs":[{"text":"A portfolio project proves you can build something alone, on your own terms, with no one disagreeing. A merged pull request into somebody else’s repository proves four different things, and they are the things employers are actually unsure about:"}]},{"t":"ul","items":[[{"text":"You can read a codebase you did not write."}],[{"text":"You can follow conventions you did not choose."}],[{"text":"You can take review comments without defending yourself."}],[{"text":"Somebody with no obligation to you judged your work good enough to keep."}]]},{"t":"p","runs":[{"text":"That last one is the only external validation available to a person with no job history. It is worth a great deal more than a certificate and it costs nothing but weeks."}]},{"t":"h2","id":"the-route-that-works-and-the-one-that-does-not","runs":[{"text":"The route that works, and the one that does not"}]},{"t":"p","runs":[{"text":"The common advice (filter a famous repository by “good first issue”) mostly fails. Those issues are claimed within hours by hundreds of people doing the same thing, and maintainers of large projects are drowning."}]},{"t":"p","runs":[{"text":"The route that works starts from use:"}]},{"t":"ol","start":1,"items":[[{"text":"Use a mid-sized tool regularly.","b":true},{"text":" Something with fifty to five thousand stars, an active maintainer and real users. The libraries around your own stack: a dbt package, a data-quality tool, a small Python client for an API you use."}],[{"text":"Hit a real problem.","b":true},{"text":" You will, within weeks. The documentation is wrong, an error message is unhelpful, a function fails on a valid input, the installation instructions skip a step on Linux."}],[{"text":"Reproduce it minimally.","b":true},{"text":" Cut it to the smallest script that shows the behaviour, with versions and the exact error. "},{"text":"This is the contribution.","b":true},{"text":" Maintainers are short of time, not ideas, and a clean reproduction is often more valuable than the fix."}],[{"text":"Open an issue with that reproduction","b":true},{"text":", and ask whether a pull request would be welcome and how they would prefer it solved. Asking first prevents the most common heartbreak, which is a week of work rejected on design grounds."}],[{"text":"Send a small pull request.","b":true},{"text":" One change. Tests if the project has them. The project’s own formatting, not yours."}]]},{"t":"p","runs":[{"text":"Documentation counts. A pull request fixing an install guide that is wrong on Ubuntu is a genuine contribution, is usually merged fast, and is a real name in a real repository."}]},{"t":"h2","id":"etiquette-learned-the-cheap-way","runs":[{"text":"Etiquette, learned the cheap way"}]},{"t":"ul","items":[[{"text":"Do not reformat files.","b":true},{"text":" A diff of 400 lines where 3 are the fix will not be read."}],[{"text":"Do not refactor on the way past.","b":true},{"text":" It reads as a stranger rearranging someone’s kitchen."}],[{"text":"Match the surrounding style","b":true},{"text":", even where you disagree with it."}],[{"text":"Reply to review comments within a day or two.","b":true},{"text":" Abandoned pull requests are the most common outcome and the most annoying one for maintainers."}],[{"text":"Accept a “no” gracefully.","b":true},{"text":" Every maintainer remembers who argued, and it is a small world."}],[{"text":"Read ","b":true},{"text":"CONTRIBUTING.md","b":true,"code":true},{"text":" first.","b":true},{"text":" Roughly half of contributors do not, and it shows immediately."}]]},{"t":"h2","id":"using-it-in-a-search","runs":[{"text":"Using it in a search"}]},{"t":"p","runs":[{"text":"One merged pull request into a tool the interviewer has heard of is worth mentioning in the first minute of a conversation. Better still, describe the review: “the maintainer pushed back on my approach because it broke Windows paths, and the second version handled both.” That single sentence demonstrates receiving criticism, which is the trait most interview processes are secretly probing for and the hardest to fake."}]},{"t":"h2","id":"the-honest-limitations","runs":[{"text":"The honest limitations"}],"role":"limit"},{"t":"p","runs":[{"text":"Three, all real."}]},{"t":"p","runs":[{"text":"It is slow and outside your control.","b":true},{"text":" Maintainers are volunteers with jobs. A pull request can sit for three months and then be closed with “we are going a different direction”. This is not personal and it is not rare."}]},{"t":"p","runs":[{"text":"Quantity is visible and worthless.","b":true},{"text":" The annual contribution events produced a flood of trivial pull requests, and maintainers now treat one-line typo fixes from strangers with weariness. Two substantive contributions to one project you actually use beat forty scattered ones, and reviewers can tell the difference instantly."}]},{"t":"p","runs":[{"text":"It does not convert directly into jobs.","b":true},{"text":" Almost nobody is hired because of a pull request. It works by making you credible in a conversation you obtained some other way, and by teaching you how professional code review feels before your first day rather than during it."}]}],"check":{"question":[{"text":"A learner wants a first open-source contribution. Which approach has the best chance of ending in a merge?"}],"options":[{"text":[{"text":"Filter a well-known machine learning framework by “good first issue” and claim the first unassigned one."}],"correct":false,"tempting":[{"text":"Enters the most heavily contested queue in open source, where issues are claimed within hours and maintainer attention is scarcest."}]},{"text":[{"text":"Fork a popular library, refactor a module they find untidy, and submit it as an improvement."}],"correct":false,"tempting":[{"text":"Sends an unrequested large diff, which maintainers decline on principle because they inherit the maintenance of a change they did not ask for."}]},{"text":[{"text":"Notice that a tool they use daily fails on a valid input, cut it to a minimal reproduction with versions, open an issue, and ask how the maintainer would prefer it fixed before writing code."}],"correct":true,"tempting":null},{"text":[{"text":"Submit typo corrections to twenty repositories to build a visible contribution history quickly."}],"correct":false,"tempting":[{"text":"Produces volume that maintainers now actively distrust, and demonstrates none of the four things a reviewer is trying to establish."}]}],"order":[3,2,0,1],"why":null},"prev":{"slug":"writing-in-public","title":"Publishing, and the inbound it creates","minutes":9},"next":{"slug":"the-bridge-job","title":"The job next to the data","minutes":8}}}