OSSGrid

Contributor playbook

You are not ready just because you want to start. Here is how to get ready.

Open source rewards preparation, not excitement. This page adapts, in our own words, Ashutosh’s post “You Are Not Ready for Open Source Just Because You Want to Start”, and adds a checklist for every program OSSGrid tracks. Read the original; it has the full story.

Readiness comes first

Fundamentals take months, not days

Before any repo, know how a real application hangs together: how data moves between frontend and backend, how a project is laid out, how APIs, databases, auth, state and deployment fit. Once that is solid, a codebase reads as a system instead of a pile of files.

Build one real project

Something with real parts: a typed frontend, auth, a database, deployment, actual user flows. Complex enough that a reviewer would not dismiss it as tutorial code. One is enough; ten toy apps are not.

Do a shadow build

Clone a good tutorial project, understand each design decision, then build a different product next to it using what you learned. Clone, understand, translate, build your own. The goal is to be able to transfer decisions to new problems.

AI makes code cheap, not judgment

Generated code does not know what should exist, how a system should be designed, or when not to build something. Fundamentals are the base; tools amplify what you already understand.

Pick a community before an issue

  • Find the project's channel before you look for an issue: Discord, Slack, Element, a mailing list or GitHub Discussions.
  • Watch which mentors are active, which projects get discussion, whether pull requests get reviewed and whether maintainers reply.
  • Pick an active project with present people over a quiet repo that merely looks easy.
  • Get the project running locally. Broken dependencies, stale docs and OS differences are normal friction, not a sign you are unfit.
  • Trace one feature end to end and write yourself a map of the architecture. Verify it against the code; treat it as a map, not as truth.

The org pages on OSSGrid show years active, projects per year and mentors’ GitHub handles, so you can tell a steady community from a one-off before you join its chat.

The contribution loop

Tick them off as you go. The loop never really ends; the point is to get through it once, honestly.

0 of 18 done…

Saved in this browser only. Nothing leaves your device.

Do not wait for good-first-issue labels

  • Many strong projects never label good-first-issues. That is not a signal to leave.
  • Issues opened by mentors or maintainers are usually worth attention.
  • Verify every issue before you work on it. Some no longer exist, some were fixed indirectly, some were misunderstood, some are too vague to act on.
  • Learn only what the issue requires: one API, one component, one data flow. Read docs, old pull requests and similar code; ask mentors after you have done your own research. The understanding compounds.

Read pull request conversations

Feature work is tradeoffs and discussion. These four threads show what maintainers actually ask for.

  • laurent22/joplin#15013

    Add a global shortcut to show and hide Joplin

    A feature that worked on Windows, macOS and X11 failed on Wayland. The thread walks through Electron, desktop portals and GNOME versions, a mentor's suggestion to scope the feature, and a maintainer's push to understand the platform properly. Admitting a gap, testing again and reporting back earned more trust than confidence would have.

  • laurent22/joplin#14582

    Include notebook icons in frontmatter export

    A feature request with tradeoffs. Reviewers asked to keep unrelated code untouched, to explain a design choice and to support custom icons; the author moved the data into a per-folder file and it merged.

  • laurent22/joplin#14443

    Add editor and sync target to the about dialog

    Check your diff before asking for review. Format-on-save added unrelated changes to a test file and the maintainer asked for them to go.

  • sugarlabs/musicblocks#6062

    Enforce pull request categories with auto-labelling

    Tested in a fork across several trial pull requests before review, with the results written up. Clear testing is what made it quick to merge.

What selection looks at

Mentors are choosing someone to work with for months. Pull request count on its own is not the signal.

  • Communication: do you reply, and do you say what you do not know?
  • Showing up: meetings, chat, the review thread.
  • Understanding the project, not just the file you touched.
  • Testing properly, on the platforms the project cares about.
  • Learning when stuck, and accepting review without ego.
  • Reliability over months. A few well-communicated pull requests beat many isolated ones.

When you get to the proposal, read a few accepted ones in the proposals library for structure. Never copy one.

Checklist per program

Google Summer of CodeIndexedShow
  1. 01 Confirm eligibility: 18 or older; students or beginners to open source.
  2. 02 Shortlist orgs in February, when accepted organizations are announced. Prefer orgs that have come back for years.
  3. 03 Read the org's ideas list and the last two years of accepted projects on OSSGrid.
  4. 04 Land at least one merged fix in the repo before applications open.
  5. 05 Write one proposal per idea you have discussed with a mentor; up to three total, only one can be accepted.
  6. 06 Pick a project size you can deliver: small ~90 h, medium ~175 h, large ~350 h. Stipends run $750 to $6,600 by size and country.
  7. 07 Submit on the official site during the March to April window, then keep contributing while you wait.
Browse GSoC orgsOfficial site Facts source
LFX MentorshipIndexedShow
  1. 01 Confirm eligibility: 18 or older; not a past Linux Foundation mentee.
  2. 02 Pick a term: three terms a year: spring, summer and fall. Projects appear on the portal a few weeks before each term starts.
  3. 03 Read the org's past terms on OSSGrid: mentors who keep showing up are a good sign.
  4. 04 Join the project's Slack channel and reproduce one open issue before you apply.
  5. 05 Apply to at most 3 projects per term; you can only join one.
  6. 06 Plan for 12 weeks full time or 24 part time. Stipends run $1,000 to $6,600 by country.
  7. 07 Upload a resume and a cover letter that links your merged pull requests in that repo.
Browse LFX orgsOfficial site Facts source
OutreachyComing soonShow
  1. 01 Check eligibility on the official site: 18 or older; underrepresented in tech where you live.
  2. 02 Note the cadence: Two cohorts a year: May to August, December to March.
  3. 03 Join the project's community and land one merged change before the window opens.
  4. 04 Follow the OSSGrid tracking issue for the dashboard.
About OutreachyOfficial site Facts source
GirlScript Summer of CodeComing soonShow
  1. 01 Check eligibility on the official site: Open to everyone; free to apply.
  2. 02 Note the cadence: Once a year, launching in March.
  3. 03 Join the project's community and land one merged change before the window opens.
  4. 04 Follow the OSSGrid tracking issue for the dashboard.
About GSSoCOfficial site Facts source
MLH FellowshipComing soonShow
  1. 01 Check eligibility on the official site: See official site.
  2. 02 Note the cadence: See official site.
  3. 03 Join the project's community and land one merged change before the window opens.
  4. 04 Follow the OSSGrid tracking issue for the dashboard.
About MLHOfficial site Facts source
Summer of BitcoinComing soonShow
  1. 01 Check eligibility on the official site: University students.
  2. 02 Note the cadence: See official site.
  3. 03 Join the project's community and land one merged change before the window opens.
  4. 04 Follow the OSSGrid tracking issue for the dashboard.
About SoBOfficial site Facts source

Resources

Adapted from Ashutosh’s original post. Program facts come from each program’s official pages; 6 programs are tracked in the registry.