Checklist · Career
Open Source Contribution Checklist
Opens with creditsA step-by-step open source contribution checklist, from choosing a project to getting a pull request merged and becoming a regular contributor. It covers project health signals, CONTRIBUTING files and sign-off rules, claiming issues, the fork and branch workflow, writing a pull request maintainers can review quickly, handling feedback, and reporting security problems the right way.
Written by Tauseef Fayyaz8 chapters, 38 checksAbout 24 minReviewed 13 October 2026What you will learn
8 chapters · about 24 min
1Pick a healthy projectBefore you write any code, make sure the project is open source, alive and likely to review what you send.5 checks · 4 min
- 1Start with a project you already use or want to learn
- 2Confirm the project has an open source licence file
- 3Check that the project is active: recent commits, merges and replies
- 4Read a few issue threads to see how maintainers treat newcomers
- 5Find the code of conduct and know how to report a problem
5 in this chapterOpen this chapter2Read the rules before you codeEvery project writes down how it wants contributions made. Find those rules and set up the project locally before changing anything.4 checks · 3 min
- Find and claim an issuePick work that the project actually wants, and tell people you are on it so nobody duplicates your effort.5 checks · 3 minOpens with credits
- Fork, branch and keep in syncThe standard GitHub contribution workflow: your own fork, one branch per change, and an up-to-date base.5 checks · 3 minOpens with credits
- Open a pull request maintainers can reviewA good pull request is small, explains itself, links its issue and passes the checks before anyone has to ask.6 checks · 4 minOpens with credits
- After you submit: review and follow-upHow to respond to feedback, chase a stalled pull request politely and close the loop either way.5 checks · 3 minOpens with credits
- Security reports and community conductSecurity problems need a private route, and every public comment is part of your record.4 checks · 2 minOpens with credits
- Grow from first pull request to regular contributorDepth in one project builds trust, skill and a record that speaks for itself.4 checks · 2 minOpens with credits
About this checklist
An open source contribution checklist helps because most first pull requests fail for reasons that have nothing to do with code quality. The contributor picked an abandoned project, skipped the CONTRIBUTING file, started work on an issue someone else had claimed, or opened a 900 line pull request with no description. Maintainers are volunteers or busy staff, and a contribution that respects their process is far more likely to be reviewed and merged.
This checklist follows a contribution in order. The first chapters cover choosing a project that is alive and welcoming, then reading the rules that every project writes down in different places: the README, CONTRIBUTING, the code of conduct and any sign-off or licence agreement. The middle chapters cover finding and claiming an issue, the fork and branch workflow, and writing a pull request that is easy to review. The last chapters cover what to do after you submit, how to report a security problem without exposing users, and how to grow from one merged pull request into a trusted contributor.
The advice is checked against GitHub's own documentation, the Open Source Guides published by GitHub, and the Developer Certificate of Origin, as of October 2026. Most of it applies to GitLab, Codeberg and other hosts too, because the etiquette is the same everywhere. It works whether you are a student in Karachi making your first documentation fix or an experienced engineer in Berlin contributing to a library you use at work.
Every item says what to do and how to check you did it. Open source contributions are public and permanent, so a careful first contribution is worth more than ten rushed ones.
Common questions
How do I find my first open source issue to work on?
Start with projects you already use. Look for issues labelled good first issue, or add /contribute to a repository URL to see beginner-friendly issues. Check that nobody has claimed the issue, comment that you would like to work on it, and confirm old issues are still wanted before you start.
Do I need to be an expert to contribute to open source?
No. Documentation fixes, clearer examples, bug reproductions and small tests are real contributions, and the Open Source Guides note that 28% of casual contributions are documentation. Start small to learn the process, then take larger issues in the same project.
What does Signed-off-by mean on a commit?
It is a sign-off under the Developer Certificate of Origin, which certifies that you wrote the code or have the right to submit it under the project's licence. Projects that require it ask you to commit with git commit -s, which adds the line using your configured name and email.
What should I do if maintainers do not respond to my pull request?
Wait at least a week, then post one polite comment in the pull request asking for a review, mentioning the likely reviewer if you know them. Do not message maintainers privately. If the project looks inactive, consider contributing elsewhere.
How do I keep my fork up to date?
Use the Sync fork button on your fork's GitHub page, run gh repo sync, or on the command line fetch from the upstream remote, merge upstream/main into your main and push it. Sync before creating a branch and again before opening a pull request.
How do I report a security bug in an open source project?
Privately. Use the Report a vulnerability button on the repository's Security tab if it is enabled, or follow SECURITY.md. If neither exists, open an issue asking only for a security contact, without any details of the vulnerability.
Sources (8)
Checked against these, last on 13 October 2026.
- How to Contribute to Open Source, Open Source Guidesopensource.guide/how-to-contribute/
- Setting guidelines for repository contributors, GitHub Docsdocs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors
- Encouraging helpful contributions to your project with labels, GitHub Docsdocs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels
- Developer Certificate of Origin, Linux Foundationdevelopercertificate.org/
- Syncing a fork, GitHub Docsdocs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork
- Creating a pull request from a fork, GitHub Docsdocs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork
- Linking a pull request to an issue, GitHub Docsdocs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue
- Privately reporting a security vulnerability, GitHub Docsdocs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability
Related on Sefism
Picked from the other libraries by shared topics.
Checklists
See allProject structures
See all- Python package and CLI project structureA command line tool published to PyPI, laid out the way the Python Packaging User Guide and uv recommend: a src layout, one pyproject.toml for metadata and every tool, a thin Typer CLI over plain, testable modules, and releases uploaded by GitHub Actions with trusted publishing. The example is mdlinks, a tool that finds broken links in Markdown files. For students who have written Python scripts and want to ship one that strangers can
pip install. - TypeScript npm library project structureA small, typed npm package (a retry helper) built the way modern libraries ship in 2026: TypeScript source in
src, bundled by tsdown intodistwith type declarations and anexportsmap, tested with Vitest, checked with publint and Are the Types Wrong, versioned with Changesets and published from CI with npm provenance. For students who want to publish their first package, and for anyone whose package works locally but breaks for users. - VS Code extension project structureA TypeScript extension for Visual Studio Code, built from the official Yeoman generator with esbuild bundling. The example, TODO Lens, finds TODO comments and shows them in a tree view, with commands, settings and editor decorations. The tree grows from the generator's Hello World into commands, providers and editor-free core logic, then tests on three operating systems, publishing to the Marketplace and Open VSX, and a webview with a strict security policy. For students who use VS Code every day and want to build a tool other developers install.
Career questions
See all- How do I learn to read a large codebase when I can handle small projects but get lost in real ones?Nobody reads a large codebase from top to bottom. You follow one real path through it, such as a single request or button click, from entry point to database and back. Map what you find, ignore everything off that path for now, and repeat with a different path. Understanding builds in layers, and a first small change teaches more than a week of reading.
- Should I spend my free time building projects, solving DSA, contributing to open source or networking?Not one of them: a weighted mix that changes with your stage. Early on, lean on projects and fundamentals; closer to applying, shift time towards problem solving and networking. Open source is valuable but optional. Decide the split weekly and review it monthly against what is actually blocking you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com