Sefism Open Source Cheat Sheet

What this cheat sheet is

The Sefism Open Source cheat sheet is a reference for developers contributing to open source, from a first pull request to a mentored programme and a project of their own. It puts the ideas behind each step in one place: how projects are run, the Git workflow contributors use, and the habits that get changes merged.

It has six chapters and 51 concepts. Every concept is written the same way: what it is in plain words, why it matters, and where useful a concrete example and the mistake people usually make with it. Twelve concepts carry a short snippet, mostly the exact Git commands for forking, syncing, rebasing and force-pushing safely, plus a sample commit message. Around them sit eight rules of thumb and a glossary of the smaller terms (CODEOWNERS, bisect, stale bot, stipend and so on) that come up in project discussions.

Who it suits

Students and engineers who can already build small programs and are starting to contribute, people preparing for Google Summer of Code, Outreachy or LFX Mentorship, and anyone who has opened a pull request and wants to understand why it stalled. If you are new to Git altogether, the Developer tools cheat sheet covers the basics first.

Chapter by chapter

1. How open source works

Licences, maintainers, contributing guides and codes of conduct, with the reminder that most rejected first pull requests break a norm, not a test. Concepts: open source licence (OSI approval and SPDX identifiers such as MIT), permissive licences (MIT, BSD, Apache 2.0 and its patent grant), copyleft licences (GPL, LGPL, MPL and AGPL), maintainers, project governance (single lead, core team or foundations such as the Apache Software Foundation, CNCF and the Linux Foundation), the contributing guide, codes of conduct, CLA and DCO (including git commit -s), and why people contribute.

2. Git and GitHub for contributors

Working in a repository you do not own. Concepts: fork, origin and upstream, feature branch, keeping a fork in sync, rebase, merge conflict, a good commit message, Conventional Commits, squashing and force-pushing, and the everyday commands (status, diff, add -p, stash, log --oneline, restore). This chapter is where the snippets live: adding an upstream remote, starting a branch from the latest upstream main, a fast-forward sync, rebasing with conflict resolution, and --force-with-lease after an interactive rebase.

3. Your first merged pull request

Where maintainers expect newcomers: documentation, tests and labelled beginner issues. Concepts: good first issue, claiming an issue, running a project locally, documentation and test contributions, the pull request itself, the pull request description (what changed, why, how you tested it, which issue it closes), CI checks, responding to review, and draft pull requests.

4. Becoming a regular on one project

Committing to one project for months. Concepts: reading a large codebase (start from an entry point or a test, follow one feature, use git blame), issue triage, minimal reproduction, reviewing other people's pull requests, proposals and RFCs (such as Python PEPs or Kubernetes KEPs), project communication channels, and how committer and maintainer status is earned.

5. Mentored programmes

Fixed-length, usually paid projects with maintainers as mentors. Concepts: Google Summer of Code, Outreachy, LFX Mentorship, timelines and eligibility, choosing an organisation, the project proposal (problem, solution, weekly milestones, deliverables, risks and prior contributions), working with a mentor, and Hacktoberfest and the MLH Fellowship. Programme rules change from year to year, so the sheet points you to each programme's official page for current dates.

6. Maintaining your own project

Running a small project the way good maintainers do. Concepts: README, choosing a licence, CI with GitHub Actions, issue and pull request templates, semantic versioning, releases and changelog, reviewing outside contributions, and maintainer burnout.

Each chapter ends with up to three library resources to go deeper, such as the Open Source Guides: How to Contribute, Pro Git, Good First Issue, CodeTriage and Choose a License.

The rules of thumb

The sheet closes with eight short rules, among them: read the README, contributing guide and a few merged pull requests before you write any code; keep each pull request small and about one thing; use --force-with-lease, never plain --force; discuss anything bigger than a small fix in an issue first; wait a week before a polite nudge; and depth beats breadth, because months on one project teach more than one pull request to twenty.

How to use it with the roadmap

The chapters match the six stages of the Open source roadmap one to one, and topics on the roadmap link straight to the concepts that cover them.

• Revise after each stage. Read the matching chapter and check you can explain every concept without looking.
• Keep chapter 2 open while you work. The Git snippets are the ones you will reach for when a rebase goes wrong or a fork falls behind upstream.
• Before you open a pull request, reread chapter 3: claiming, description, CI and responding to review.
• Before a mentored programme deadline, go through chapter 5 against your proposal draft.
• Before a technical round, use the sheet to refresh the vocabulary (rebase, upstream, semantic versioning, DCO) so you can talk about your contributions precisely.

How it works on Sefism

Everything on Sefism is free to learn from. The public page at /cheatsheets/open-source/ lists every chapter title, with the first chapters open to read. Keeping the sheet uses a few credits, and new members get starting credits when they join; following the Open source roadmap also unlocks this sheet. Once it is yours, every chapter opens in the member area, with search across terms and the names people search for, such as "license" or "SPDX". Create a free account to start, or ask Tauseef a question about a project you are stuck on.

Related on Sefism

• Open source roadmap, the companion learning path
• How to learn Git and GitHub properly
• How to read and understand a large codebase
• Git, properly: the model behind the commands you use every day
• Google Summer of Code and Outreachy in the library
• Project idea: Good first issue finder for university open source clubs

FAQ

What is the difference between origin and upstream? By convention origin is your fork and upstream is the original project. You fetch from upstream to stay current and push your branches to origin.

Should I use MIT or Apache 2.0 for my own project? Both are permissive. The sheet notes that Apache 2.0 also grants patent rights; GPL is the choice if you want modified versions to stay open.

Why use --force-with-lease instead of --force? Plain --force can silently delete commits a maintainer pushed to your branch. --force-with-lease refuses if the remote changed since you last fetched.

Is the cheat sheet enough to start contributing? It is a reference, not a course. Pair it with the roadmap, which sets the milestones, checklists and the order of work.