{"title":"Building a Track Record","description":null,"content":"One merged pull request is a good start. A track record means you have done useful work more than once.\n\nFor hiring purposes, a strong open-source signal usually comes from steady contributions to one or two projects over time. A few thoughtful pull requests to the same project can show that you learned the codebase, responded well to review, and took on more useful work as you gained context. That tells a hiring manager more than a scattered set of tiny pull requests across many unrelated repositories.\n\n---\n\n# Why Depth Beats Breadth\n\nGoing deeper in one or two projects usually helps more than spreading yourself across many projects.\n\nDepth shows progression. You might start with documentation or small fixes, then move into bugs, small features, or issue triage as you understand the project better. That progression is useful evidence because it mirrors normal engineering work: you join an existing codebase, learn how it works, and gradually take on more responsibility.\n\nDepth also helps relationships form naturally. If maintainers see you contribute more than once, communicate clearly, and make review easy, they are more likely to trust your future contributions. Sometimes that can lead to referrals or introductions, but treat that as a possible bonus, not the main plan.\n\nThe diagram below contrasts the same effort spent two ways.\n\n\n```mermaid\nflowchart TD\n S[Same number of
merged pull requests]:::start --> A[One per project
across six repos]:::breadth\n S --> B[Several to one or
two projects]:::depth\n A --> C[Reads as scattered
no progression]:::weak\n B --> D[Shows learning and
maintainer trust]:::yes\n\n classDef start fill:#00ceff,stroke:#000,color:#000\n classDef breadth fill:#ffa94d,stroke:#000,color:#000\n classDef depth fill:#38d9a9,stroke:#000,color:#000\n classDef weak fill:#ff8787,stroke:#000,color:#000\n classDef yes fill:#69db7c,stroke:#000,color:#000\n```\n\n\nBoth paths cost the same effort. The concentrated path produces a stronger signal because it shows you stayed with a codebase long enough to learn it and earn some trust, which scattered one-off fixes cannot demonstrate.\n\nThis takes time. Building a real contribution record is measured in months, not days. You do not need to become a maintainer for the work to matter. A small set of accepted, well-described contributions to a useful project is already worth showing.\n\nThe last piece is visibility. Contributions buried in your GitHub activity feed are easy to miss. Your GitHub profile `README`, LinkedIn Featured section, and resume can make the work easier for a hiring manager to find.\n\n---\n\n# Building Depth in One or Two Projects\n\n### Pick one or two projects to go deep on\n\nAfter your first merged pull request, consider staying with the same project for the next few contributions. One or two projects you know well are usually better than a long list of unrelated one-off pull requests.\n\n### Climb the contribution ladder deliberately\n\nStart with documentation or small fixes, then take on slightly harder work as you learn the codebase. Do not rush this. The goal is to show steady growth, not to jump into a feature before you understand the project.\n\n### Contribute at a steady pace\n\nAim for regular, manageable contributions. For some people, that means a small pull request every week or two. For others, it means one useful contribution a month. Consistency matters more than speed.\n\n### Build the maintainer relationship\n\nBe reliable, respectful, and easy to review. Respond to feedback, keep pull requests focused, and follow the project's conventions. Once you know the project better, you can help answer simple issues or review small changes if the project welcomes that.\n\n### Plan your next several contributions in advance\n\nDo not start from zero after each merge. Keep a short list of two or three possible next issues in the same project. If one issue gets claimed or grows in scope, you have another option ready.\n\n### Put the work where people can find it\n\nAdd a line to your GitHub profile `README` naming the project and the type of work you contributed. Feature a strong pull request or contributor page on LinkedIn if it is relevant. Add a concise resume line when the work is meaningful enough to support.\n\n### Set a realistic horizon\n\nTreat this as a multi-month effort. You may get useful resume evidence after a few merged pull requests, but trust and deeper responsibility take longer. Do not judge the entire strategy by the first few weeks.\n\nHere is a realistic progression in one project.\n\n\n```mermaid\nflowchart LR\n A[Docs and
small fixes]:::start --> B[Real bug
fixes]:::main\n B --> C[Small features
or improvements]:::main2\n C --> D[Issue triage
or light review]:::support\n D --> E[Deeper project
responsibility]:::yes\n\n classDef start fill:#00ceff,stroke:#000,color:#000\n classDef main fill:#ffa94d,stroke:#000,color:#000\n classDef main2 fill:#ffd43b,stroke:#000,color:#000\n classDef support fill:#38d9a9,stroke:#000,color:#000\n classDef yes fill:#69db7c,stroke:#000,color:#000\n```\n\n\nMost job seekers only need the first two or three stages. You do not need maintainer status for the work to be worth showing. The signal is steady, accepted work in a real project.\n\n---\n\n# How to Feature Your Contributions\n\n\n| Where | What to show | Format |\n|-------|--------------|--------|\n| GitHub profile README | The project and your role | \"Contributor to [project]: [area you work on]\" with a link |\n| LinkedIn Featured | A key pull request or your contributor profile | Pin the pull request or the project, strongest first |\n| Resume | A concise line under projects or open source | \"[N] merged pull requests to [project], including [the notable one]\" |\n\n\nKeep each line honest and specific. \"Contributor to a widely used logging library; fixed two documentation gaps and one configuration bug\" says more than \"open source contributor\" because it names what you actually did.\n\n---\n\n# One-Off Contributions vs a Track Record\n\nThe difference is usually depth in one place. Here are two profiles after three months.\n\n**One-off contributions:**\n\n\n```javascript\nOne merged pull request each to six different projects, all small documentation\nfixes, with no follow-up contribution to any of them.\n```\n\n\n**Track record:**\n\n\n```javascript\nSix merged pull requests to one CLI tool over three months: started with\ntwo documentation fixes, fixed two small bugs, improved one error message,\nand helped clarify an issue for another new contributor.\n```\n\n\n**Why the track record version works:** The one-off contributions show useful effort, but they do not show much depth. The track record shows that the contributor stayed with one codebase, learned it, and became more useful over time. Same number of weeks, stronger signal.\n\n---\n\n# Mistakes That Weaken a Track Record\n\nThe contributions below are all real work, yet their shape sells the effort short and leaves a reviewer with a weaker impression than the hours deserve.\n\n- **Spreading across too many projects.** One small pull request in many repositories can look scattered. A few contributions in one or two projects usually tell a stronger story.\n- **Staying only on tiny changes.** Documentation is a great start, but if you can do more, gradually move toward bugs or small improvements.\n- **Contributing in bursts.** A weekend of activity followed by silence is less convincing than steady contributions over time.\n- **Forgetting the human side.** Maintainers remember contributors who are clear, reliable, and easy to work with.\n- **Hiding the work.** Contributions buried in your activity feed are easy to miss. Put the best ones on your profile, LinkedIn, and resume.\n- **Expecting fast status.** Trust in a project takes time. A few good pull requests can help your profile, but deeper standing is a longer effort.","pageType":"job-search"}

Get Premium