What we learned from other tools, and what we built

In October 2026 we surveyed the tools, data sources, and research around open source onboarding and Google Summer of Code, read the strongest projects' source code, and turned the findings into features. This page keeps the useful part: where ideas came from, why we adopted or rejected them, and which commands they became. No code was copied; licenses are noted where an idea came from a specific project.

Data sources

Ideas we adopted

• Ideas pages have a small, stable vocabulary. We fetched the ideas pages of all 183 GSoC 2026 organizations. 168 loaded; of those, 118 state a size or hours, 129 name mentors, 113 list skills, 97 state difficulty. A heading-plus-label parser extracts clean idea blocks from about a third of pages and partial fields from another third. This became ideas ORG, which reports its confidence per idea and says when a page is an index or unreadable. Google Docs are read through their HTML export so headings survive; the plain-text export flattens them.

• Organizations publish AI-use policies, and they differ. 75 of the fetched pages contain a sentence about AI or language-model use, from outright bans to disclosure templates. ideas and orient quote them verbatim with their source instead of stating one global rule.

• Prior public engagement is what reviewers score. Google's organization-admin guidance, and 2025 to 2026 posts from OpenStreetMap, Rust, Jenkins, INCF, and Wikimedia, converge on contact before applying, contributions during the application phase, and template adherence. contributions --github USER --org ORG collects the evidence reviewers look for, and next asks for one public introduction before suggesting an issue.

• The weekly note has a known shape. The Python Software Foundation's GSoC blogs ask three questions every week: what did you do, what is next, where are you stuck. log uses those fields plus links and what you learned, and draft status turns the latest note into a post.

• Newcomers' first patches land when they are small bug fixes with tests, and when the author answers review promptly. Turzo, Sultana and Bosu (2025, 1,155 GitHub projects and five Gerrit projects) found good-first-issue labels, few files, few added lines, and prompt, patient responses to review predict acceptance; longer or prettier descriptions do not. pointers shows the repository's real fix norm (median files, how often fixes touch tests) and draft pr and draft review-reply carry the rules.

• "Unclear how to start" and "no response" are the top newcomer barriers (Tan, Zhou and Sun, ICSE 2023, 48,402 good first issues). orient answers the first with facts and paths: where the code lives, how CI runs the tests, who merges, and what the rules are before a pull request. draft question and next address the second by prompting a public, well-formed question after a few days of silence.

• The pull request that closed an issue is findable from the timeline. On matplotlib, four of six closed good-first-issues had a same-repository pull request merged within one second of the close, and every fix touched the tests directory. pointers uses that rule to learn from past fixes without cloning.

• Full paths beat trees for machines and people. The Agentless project reported that listing full file paths, at most five, stopped language models from inventing paths. orient and pointers print full repository-relative paths and never a nested tree or generated prose.

• Sanitise what strangers wrote. The GitHub MCP server sanitises every issue body by default; Unicode tag characters can hide text that models read and people cannot. All titles, descriptions, and quotes we show pass through one cleaner.

• Protocol hints change how assistants treat tools. Clients skip confirmation for read-only tools and prompt for everything else. Every tool now carries annotations and a title; four prompts expose the coaching flows as one-click commands.

• The official archive names mentors. /api/archive/programs/{year}/projects/ lists every completed project with its mentors, code URL, and tags; the community archive we also use drops those fields. mentors ORG turns three archived years into a list of who mentors, who returns, and which repositories past work lives in.

• Claims are commands, not prose. Zulip, Rust, Kubernetes, pandas, Beam and others claim issues with @zulipbot claim, @rustbot claim, /assign, .take and similar, and bots release them after a week or two of silence. Availability now reads those commands and releases.

• Maintainer-filed issues and reservation labels. A GSoC mentor's skills pack (OSS-Skills, below) filters for issues filed by owners, members and collaborators, because drive-by issues often close unmerged, and treats labels such as in progress, claimed, taken, wip and has-pr as claims. issues now marks maintainer-filed issues and scores them a little higher, and availability reads those labels.

• The gates that are not in the docs. OSS-Skills' submit step scans workflows and rulesets for requirements CONTRIBUTING leaves out. GitHub's active branch-rules endpoint answers without a token for public repositories, so orient and draft pr now list those gates in plain words with their source. Checked live on 2026-10-21: OWASP Nest needs two approvals including a code owner, an up-to-date branch, a squash merge queue, and an issue assigned to the author, without which a workflow closes the pull request; SymPy has no rulesets. Classic branch protection stays invisible without admin rights, and the output says so.

• The iterate phase needs eyes on open pull requests. oss-autopilot (MIT) sorts a contributor's open pull requests into ones that need them and ones waiting on maintainers, with careful time ordering: a comment counts as answered only by a commit at least two minutes later, and a later "changes requested" review undoes that. next now does the same from one search plus three calls per pull request (details, timeline, checks), skipping the person's own repositories and machine accounts that GitHub reports as ordinary users (a live run caught stdlib-bot). The top two that need attention become the first actions, with the review-reply draft as the command.

• CI shows the real environment. OSS-Skills' setup skill says to read setup instructions but trust CI: the workflow names the runtime versions, services and systems the tests actually need. orient now prints them next to the test command, matrix values included (SymPy tests on PyPy and Python 3.10 to 3.13; Matplotlib on free-threaded 3.14t builds and four runner images).

• Setup failures have a small number of shapes. Getting the project to build and the tests to run is the first barrier the onboarding studies report. ContribOS's setup --diagnose classifies failure output; diagnose does the same for fourteen common shapes (missing module, a name missing from an installed module, runtime version, compiler or headers, service not running, environment variable, missing command, permissions, network, port in use, lock file, memory, a failed style check, failing tests), quotes the line it matched, says what to try, and with --repo adds what CI really sets up, including the install commands now read from workflows. When an environment cause and failing tests appear together, the environment cause is reported, because the failures are its symptom. On a real missing-module failure against SymPy it points to SymPy's pip install -r requirements-dev.txt and its eight CI Python versions. On a real SymPy pull request that failed CI for a space at the end of a line, it now names the style check and the file and line first, and still reports the separate failing test in the same run.

• Check the message, not just the template. ContribOS's tone flags machine-written tells before a comment is posted. draft KIND --check FILE now applies the same rules draft cites for each kind to what the person actually wrote: leftover placeholders (including the templates' own angle-bracket ones), assistant phrasing and generic filler, a greeting with nothing else, a question with no question in it, asking to ask, a bare claim, a pull request description with no issue or testing note, a weekly update missing one of its three questions. It never rewrites the text.

• Apply the rules to the actual pull request. ContribOS's check reviews a contributor's own branch the way the repository's maintainers would. orient already read those rules but never applied them. The new pr-check does, from the API alone: merge conflict, failing checks, a linked issue (a failure where a workflow closes pull requests without one), the template checklist, AI disclosure, sign-off, commit style, tests beside code, a changelog entry, and size, each with its source. Checked live on 2026-10-21: it caught SymPy's "Check Authors" job failing on a newcomer's pull request, OWASP Nest's missing template checklist and test changes, and a 4,355-line stdlib change. That run also removed a false positive: stdlib's guide mentions an automatic changelog, so changelog wording now has to ask the contributor to act.

• Closed is not always rejected. ContribOS's landed.py counts a closed pull request as landed when a later commit carries its number or title. repo now does the same with one commit listing instead of one call per pull request, adds two signals (a GitHub-Pull-Request: trailer or /pull/N link, and a Co-authored-by trailer naming the author), and refuses title matches on another pull request's squash merge, because a live run showed those are resubmissions by the same author. Checked live on 2026-10-21: Go, which never merges on GitHub, went from no outside work landing to seven outside authors in its last 49 outside pull requests, every match carrying Go's trailer; Zulip and Flask stay low because none of their recent closed outside pull requests left a commit on main, and most were closed the day they opened.

• A quiet claim is still a claim, but say how to ask. is-it-claimed treats an open pull request idle for ninety days as a weak claim. issue keeps such an issue as likely taken, out of respect for the other contributor, but now says how long the pull request has been idle and suggests asking in the thread.

• Changelog entries are a common second review round. ContribOS's policy radar reports when a repository expects a changelog entry. orient now does too, from news-fragment folders (only when they hold fragment-shaped files, so a folder of full release notes does not count: checked on NumPy, pytest and Matplotlib) and from wording such as "release notes" in the pull request template (SymPy).

• An abandoned fix is a guide, not a warning. contrib-scout (below) searches for documented bugs with an unmerged fix. When an issue's only linked pull request was closed without merging, availability now says so and points the newcomer to that pull request's review comments, which show what the maintainers expect.

• An organization's stricter rule wins. AOSSIE's own GSoC assistant skill quotes its rule that nobody may promise help with being selected. The skill now says that when an organization's rules are stricter than general advice, theirs govern.

• Exact commands beat generic advice for a first pull request. The one other MCP server in this space (FindUnderstandFix, below) exists mainly to print the fork, clone, branch and push commands for a chosen issue. draft pr now ends with those commands, using the repository's real default branch and a branch named after the issue.

• Ask before telling, and escalate after the first merge. The learn-codebase skill teaches a codebase by prediction and tracing questions; OSS-Skills refuses a second "good first issue" and sends people to review pull requests. The skill now asks the person to predict what a file does before opening it, and says the second contribution should be one step harder.

• Umbrella organizations are lists of other projects. NumFOCUS, the Python Software Foundation and others publish an index that links to member projects under their own GitHub owners. ideas follows those links, and repos now ranks the member projects' repositories too, each marked with the page it came from.

• A time budget, not a schedule. Outreachy asks applicants for hours per week and Google's timeline fixes the deadlines; nothing in between told a newcomer what fits. next now turns saved hours per week and the next milestone into hours available and a split by phase.

• Elicitation is the protocol's way to ask. The MCP specification lets a server ask the client for structured input. gsoc_recommend_path asks what the person knows and cares about when it was given nothing and no profile is saved, only when the client declares the capability; otherwise it behaves as before.

• People and organizations describe the same work in different words. The 183 GSoC 2026 listings use 257 distinct technology tags and 505 topic tags, with spellings such as ai, ai/ml, artificial intelligence and machine learning side by side, and typos such as heathcare and phyton. A keyword ranker found two organizations for "healthcare" and put security and database organizations third for Python plus astronomy. A small concept vocabulary (about 150 skills and subjects with broader and related links, matching/concepts.py) now reads both sides; skill labels that carry across projects only partly (Santos et al., EMSE 2023) argued for a few broad concepts over fine-grained ones. How recommendations work describes the ranking.

• An organization's ideas page and code say more than its tags. Reading all 183 ideas pages with the existing parser gave 2,266 ideas from 142 organizations; about a third state a difficulty (68 easy, 369 medium, 279 hard) and about a third a size. With the languages and topics of each organization's repositories pushed in the last year, that evidence is shipped monthly as data/org_signals.json and quoted with its source, so a recommendation can say "listed as a skill in 9 of 12 2026 ideas" instead of a bare score.

• Personal fit for issues comes from task type, language, and domain. A personalised first-issue recommender found newcomers' first issues share these with their background (Xiao et al., ASE 2023). issues and recommend now say what in each issue fits the person, and newcomers get documentation and test issues a little higher.

• Measure recommendations against real outcomes. Profiles were written from 240 real GSoC 2026 accepted projects without seeing the organization, and the accepting organization's rank is the score, alongside graded persona judgments made blind to the code and scored with nDCG (Järvelin and Kekäläinen, 2002). Tuning used a dev half; the test half improved from nDCG 0.643 to 0.773 and from 62% to 76% of accepting organizations in the top ten. See evals/.

• Sitting out is news. Learning Unlimited's wiki and Wagtail's issue tracker both say they will not take part in GSoC 2027, while rankings still put them near the top for an HTML and CSS beginner. recommend now reads its top organizations' posts about the coming year and moves those that sit out to the end, with the post as the reason.

• GitHub's advanced issue search treats repeated qualifiers as AND. Checked live: org:a org:b returns 0 results under advanced_search=true and (org:a OR org:b) returns the union. All multi-org searches now use grouped qualifiers.

Ideas we rejected

• Competition scores. Sites that rank organizations by "competition level" could not show their evidence. We show slot history, mentor counts, and the ratio Google publishes instead: for 2026, 15,245 applicants from 131 countries sent 23,371 proposals and 1,142 contributors were accepted, about one proposal in twenty (re-read on 2026-10-21 from Google's April 2026 announcement).
• Generated wikis and whole-repository dumps. Maintainers of OpenWrt and Scala publicly rejected AI-written wikis for inventing details, and packing a repository into a prompt costs more than it teaches. Orientation output contains facts and paths only.
• Daily streaks. Weekly notes with no penalty for a missed week match what mentors ask for; streak mechanics add guilt without adding evidence.
• Autonomous contribution agents. Code search found a published skill that finds or creates issues, writes the fix, and opens the pull request on its own, reporting back to a chat app; contrib-radar's "Route C+" removed its human confirmation steps entirely, and oss-veda instructs the assistant to run every command without asking. That is the pattern Google's AI guidance and organizations' policies reject; this project drafts skeletons and never posts.
• Semantic issue matching with local embeddings. oss-contribution-advisor-mcp embeds issue text with a local sentence model. That adds a large machine-learning dependency, and the assistant reading this project's MCP output already matches interests to text; profile languages and interests keep the server light.
• A learned ranking model. Learning-to-rank recommenders for issues and projects (Xiao et al., ICSE 2022; Liu et al., IEEE Access 2018) train on thousands of historical outcomes. GSoC gives one outcome per contributor per year and no record of who considered which organization, so a model would fit noise and could not explain itself. Hand-set weights, tuned on a dev split and checked on a held-out one, keep every reason checkable.
• Acceptance probabilities. No public data links a contributor's profile to their chance of selection, and about one proposal in twenty succeeds overall. Fit says how well the work matches; it never claims a chance.
• Ranking by downstream dependents. The same project ranks repositories by how many packages depend on them (libraries.io, which needs a key). That measures reach, not whether a newcomer's pull request lands, so it stays out of the ranking.
• Hard-coded program dates. OWASP BLT's assistant embeds a "typical" GSoC timeline in its prompt. Dates here always come from the official site or are marked as estimates.
• Counting pull requests as progress. Hacktoberfest stopped counting them in 2026 because low-effort submissions became trivial to produce. Nothing here rewards volume.
• More ecosyste.ms enrichment. Beyond the committer counts already used, the repository metadata ecosyste.ms offers (stars, topics, languages, funding) duplicates what the GitHub API returns in the same call, and it has no response-time or availability data; adding a second source for the same numbers would only add drift.
• GraphQL-only paths. Repository health already uses GraphQL with a REST fallback. Rewriting issue availability on GraphQL would save a few calls per issue but would re-implement, without new information, a timeline reader that is tested against live events.
• Hosted project finders and maintainer-side health dashboards. Opensox, SimRepo, gitrec, repowise, delivery-intel and repocare rank or score for a maintainer or a browser; none check whether an issue is free, and several are AGPL services. The newcomer-centred health score stays.
• Cloning repositories for symbol analysis. The tree, timeline, and files endpoints already answer a beginner's questions; a local mode can come later if people ask.

Findings by stream, checked

Each stream's report was long; these are the facts that shaped decisions, with the ones re-checked directly by the maintainer session marked "re-checked". On 2026-10-21 the maintainer session also re-read the source files behind eight project rows in the table below; their Status cells name the file and what it showed.

GSoC tools and data. The official site's own JSON covers programs, organizations and an archive of completed projects with mentor names, code URLs and tags (re-checked: 1,191 completed projects for 2025). The community archive mirrors it by hand with a lag of days to weeks and without mentors. Of 183 GSoC 2026 ideas pages, 168 fetched; a heading-plus-label parser extracts clean blocks from about a third (re-checked live on MDAnalysis, KDE, CNCF, PSF, Dart, OpenStreetMap). 75 pages mention AI tools. Re-checked in full on 2026-10-21 by running ideas on all 183 organizations with the current parser: 15 pages are unreachable to scripts, 124 read as labelled or heading blocks, 20 as umbrella indexes (17 of them followed to member pages), 5 as issue trackers, and 19 stay unstructured (JavaScript applications, Confluence and Discourse pages, Google Docs written as prose). 143 organizations yield at least one idea, 1,605 ideas in all, 833 of them with enough labels to be marked high confidence, and 34 pages state an AI rule the detector recognises. The run found four parser gaps that the earlier one-third figure hid, all fixed: pages that omit the closing head tag or never close a navigation block were read as empty (JabRef, Catrobat and others), reStructuredText and setext underlined headings were dropped (Synfig), titles marked up as styled divs instead of heading tags were invisible (LLVM), and label names outside the vocabulary such as "Skills required/preferred" or "Confirmed Mentor" were ignored. Two more followed: a getting-started page with one stray label in its prose stopped being an index, so an index is now a page whose blocks carry no high-confidence labels, and a page whose links lead to no ideas falls back to its own prose blocks (JabRef describes ten ideas that way). Before those fixes the same run gave 129 organizations with ideas and 1,475 ideas. Three organizations read fewer ideas than before (DBpedia, MalariaGEN, and GNU Octave, whose project list sits behind a site-relative wiki link the parser does not resolve); resolving relative links was tried and reverted because it flooded umbrella indexes with navigation links. No GSoC-specific command-line tool, bot, MCP server or Agent Skill exists on GitHub: searches for "gsoc mcp", "summer of code mcp server" and "gsoc skill" on 2026-10-21 return only this project and one unrelated application repository (re-checked).

Beginner-issue finders. Every shipping finder is a cron-fed label crawl with no availability check; several are dead or pivoted (goodfirstissues.com, contribute.dev, Quine, gfibot.io). Claims in large organizations are bot commands with expiry (@zulipbot claim, /assign, .take, pandas /take with a seven-day release). GitHub's advanced issue search treats repeated qualifiers as AND (re-checked: repeated org: returns 0, (org:a OR org:b) returns 120). 48 organization repositories use 38 spellings of "good first issue" plus difficulty, effort and size ladders. Re-checked on 2026-10-21 on the most-starred repository of each of the 153 organizations with a GitHub owner: 149 could be read, 114 carry a label that names beginners, 94 carry one the tool already knew. "good first issue" sits on 83 repositories and "help wanted" on 79, then "easy" (11), "good-first-issue" (7), and a long tail of one-offs such as "good_for_beginners", "newbie-friendly", "first contrib", "difficulty: starter" and "good first issue (taken)". Two changes followed: issues --repo falls back to any label that names beginners when none of the known spellings exist, and a reservation word inside a longer label (that "(taken)" suffix) counts as a claim.

Repository health. author_association is evaluated at query time, so a merged author becomes CONTRIBUTOR and "first-time contributors merged" was zero by construction (re-checked on sympy: 23 CONTRIBUTOR plus 8 MEMBER among merged, zero first-timers). Time to first human response explains most of a pull request's lifetime; stars reduce acceptance odds. CLA and DCO requirements are detectable from check names (cla/google, EasyCLA, DCO) and commit trailers. ecosyste.ms offers a generous zero-token data source but no response-time data.

Codebase onboarding. No existing tool addresses "I picked a repository, now what?"; packers dump everything and generated wikis draw public complaints from maintainers. One recursive tree call, one timeline call and one pull-request-files call are enough to find what a fix touched (re-checked on matplotlib: five of six similar closed issues had a traceable fix pull request, all touching tests). Full paths beat trees for avoiding invented files.

MCP and Agent Skills. The server spoke the current protocol but used none of it: no annotations or titles, every response sent twice through a wrapped output schema, errors as result JSON. Clients skip confirmation for read-only tools. Local stdio servers are distributed as plugins; the skill format allows license, compatibility and metadata fields. Untrusted text should be cleaned of hidden Unicode and structurally separated from server output. (All re-checked over stdio after the changes: 22 tools with titles and annotations, four prompts, four resources, errors flagged.)

Onboarding science. Prior engagement is what organizations score; about one proposal in twenty succeeds (1,142 of 23,371 in 2026, from Google's own announcement). The five studies cited below were re-opened on 2026-10-21: the titles match, the Tan, Zhou and Sun paper does study 48,402 good first issues, and the Turzo, Sultana and Bosu paper does cover 1,155 GitHub projects and five Gerrit projects (both figures read from the PDFs). First patches land when they are small bug fixes with tests and the author answers review promptly. "Unclear how to start" and "no response" are the top newcomer barriers. Community contact belongs before claiming an issue, which is now the order of the journey. Weekly notes with no streak mechanics match what organizations ask for.

Other tools we checked

To check that nothing comparable was missed, on 2026-10-21 we ran about forty GitHub repository searches (gsoc, google summer of code, good first issue, open source onboarding, issue recommender, codebase onboarding, mcp server open source contribution, and similar), eight code searches over file contents (SKILL.md and AGENTS.md files that mention GSoC or good first issues, and MCP servers that call the official site), and a third pass for code that does what this project does: calls to the official archive API, timeline readers that look for linked pull requests, claim-phrase detectors, first-timer merge rates, and branch-rule readers. Every result with at least twenty stars and a push in the last two years was read (README, license, last push), 188 repositories in all, then scanned by file tree for skills, servers, and crawlers that the README did not advertise. The closest ones were read in source. Nothing found combines GSoC data, availability checks, and an assistant skill. The ones that mattered:

• chiruu12/OSS-Skills (MIT, 60 stars, by a GSoC mentor) is the closest Agent Skills pack: fifteen prompt skills driven by the gh command, from finding an issue to a second contribution, all read in full. Its checklist filters for issues filed by owners, members and collaborators, checks that outside pull requests get merged, treats reservation labels as claims, re-reads every comment and cross-referenced pull request before claiming, and gates coding behind the person explaining the plan in their own words. It also recommends test and documentation contributions as the fastest way to learn a codebase, checking whether a CI failure also happens on the main branch, and learning a technology only from examples inside the repository. It has no server, no availability algorithm beyond what the model does with the raw data, and no GSoC data. Three of its rules were adopted (above).
• rabbive/contrib-scout (MIT, created 2026-08) is the closest skill in method: a GO / GO-IF / NO-GO report backed by scripts for a pull-request census (merge rates, time to first human response, diff size, docs-only share), an unclaimed-issue inventory, and the official GSoC organization list. Its verify_firsttimers reconstructs true first-timers with one search per author to undo GitHub's read-time author_association relabelling, the same bias this project corrects with outside-author counts and ecosyste.ms one-commit counts at a fixed cost. Its "documented bug with unmerged fix" search was adopted (above).
• ContribOS (MIT, created 2026-09) shares this project's stance almost word for word: it never opens pull requests, posts comments or claims issues. Its policy command cites file and line for each rule (tests, changelog, AI disclosure trailers, vouch gates), landed.py checks whether a closed pull request landed anyway through a maintainer's commit, and tone flags machine-written phrasing. It clones repositories to work; orient reads them through the API.
• devch-tech/FindUnderstandFix (MIT, 11 stars, TypeScript) is the closest MCP server: five tools that list open issues by label, newest first, with no assignee, claim, or linked pull request check; get_contribution_guide prints the fork, clone, upstream, branch, rebase and push commands, and get_hints calls a Claude model from inside the server with the user's key. The commands idea was adopted (draft pr ends with them); the unchecked search and the in-server model calls were not.
• ktaletsk/learn-codebase (MIT, 89 stars) teaches a codebase by prediction and tracing questions, with a learning journal in .claude/ and structured choices through the client's question tool. The ask-before-telling rule was adopted into the skill.
• mansoor-mamnoon/codeglance (MIT) tours a local checkout from its manifest files, with detectors for entry points, frameworks, scripts, tools and git activity. orient covers the same ground for a remote repository without cloning. Nothing adopted.
• kpj2006/GSoC-Info-Assistant is AOSSIE's own assistant skill. It answers only from Google's and AOSSIE's published rules, says which tier each answer came from, and refuses selection coaching under AOSSIE's rule (adopted above). Its mode switch (no tools, local files, or fetch) is a good pattern for skills that run in very different hosts.
• drkrillo/good-first-issues (Apache-2.0, 48 stars) is a GitHub Action that crawls listed owners into a CSV and an MCP server, on the same SDK version as this project, that searches that CSV by language and comment count. It reads a snapshot, so it cannot see claims or linked pull requests made since the last crawl.
• oss-autopilot (MIT, 23 stars) tracks a contributor's open pull requests; its idea was adopted (above).
• is-it-claimed (MIT) treats an open pull request idle for ninety days as only a weak claim and looks for branches named after the issue in recent forks.
• open-source-radar (MIT, 26 stars) refreshes 3,369 issues every twelve hours and runs its own /claim bot that frees claims after seven quiet days.
• contri (MIT) shows project activity, maintainer reply times, claims and linked pull requests on GitHub pages, with an MCP server.
• ContribAI (AGPL-3.0, 246 stars) is the maintainer-side mirror image: it submits AI-prepared changes only where a repository manifest or maintainer label invites them, with an evidence receipt.
• gsoc-2026-explorer scrapes all 184 organizations' ideas into Markdown for a search site; it normalises pages but does not extract fields or confidence.
• oss-contribution-advisor-mcp (no license, created 2026-08) matches interests to issues with local sentence embeddings, scores repositories on responsiveness and first-timer merge rate, and ranks them by downstream dependents from libraries.io: three ideas rejected above.
• Found only by scanning file trees: contrib-radar (a Chinese-language contribution-finder skill whose "collision detection" pages through every open pull request because search returns only the first hundred; the issue timeline used here sees every cross-reference without that limit), oss-veda (ranks AI/ML issues by "career impact"), agent-sh/onboard, spine and investigate-codebase (codebase orientation from a local checkout, the last with a read-only, evidence-first contract close to orient's), diagram-tour (a narrated architecture video), and the weekly data refresh behind openorganizations. eve-mentor-mcp, a mentor server for a video game, is the closest outside analogue to this project's shape: tools built around the questions newcomers actually ask, plus remembered goals.
• Organization-side ideas repositories (numfocus/gsoc, python-gsoc, cBioPortal/GSoC, jitsi/gsoc-ideas, uaanchorage/GSoC, sugarlabs/GSoC) served as live tests of ideas: the Python Software Foundation's index yields 20 ideas from 5 followed pages, cBioPortal is read through its issue tracker (9 ideas), Jitsi's index links to two pages that hold no readable ideas, and the Alaska organization has no ideas URL in the official data. The NumFOCUS run found two defects, both fixed: an umbrella page that is only a list of links was read as unstructured and not followed, and a list of links could be mistaken for an AI policy sentence (a .ai domain plus "Proposed-Projects" in a path). Links under an ideas heading are now sub-pages, a page that is mostly links is an index, link targets are ignored when matching policy sentences, and wrapped lines are joined first. ideas NumFOCUS now reads 20 ideas from 8 sub-project pages.
• Proposal archives: nirmaltodwal7/GSoC_archive_2026 (264 stars) is a sixth archive with one folder per organization, and COPS-IITBHU/GSoC-Accepted-Proposals (526 stars, no license file) sorts by year and names each file after the organization. ideas links both, matching file names as well as folder names.
• RocketChat/RC.Guided.Tours: a GSoC organization onboards contributors with CodeTour files, which is the format orient --codetour writes.
• google/gsocguides (541 stars) is the source of the contributor-guide rules that draft cites.
• first-timers/app (Apache-2.0, 292 stars, the Probot bot that turns a maintainer's small fix into a first-timers-only issue), BirthdayResearch/oss-governance-bot (/assign chat-ops), AOSSIE-Org/Gitcord and AOSSIE-Org/Devr.AI (Discord onboarding) are organization-side bots; their commands and labels were already in the claim vocabulary.
• nodesagar/gsoc-proposal-wisdom distils a local folder of accepted proposals into scoring heuristics and hard-codes one person's corpus path; proposal checks a draft against required sections instead and never bundles other people's proposals. NachiketPatil26/gssoc-ops runs a pre-flight check (gh, git, jq, auth, git identity) before a GirlScript Summer of Code workflow; doctor covers the same ground.
• Repository health and recommendation tools (repowise, delivery-intel, repocare, GitVital, gitrec, SimRepo, howfairis) score for maintainers or rank by popularity; rejected (above).
• Lists of adjacent programs (yashisrani/List-of-OpenSource-Programs, deepanshu1422/List-Of-Open-Source-Internships-Programs, european-summer-of-code) are useful pointers for someone not selected; skill marketplaces (Gentleman-Skills, Skill_Seekers, ccpm) are distribution channels. Nothing to build. A gsoc-contributor skill and OWASP BLT's assistant are the two rejected patterns above; tinyfish oss-bounty-finder (paid open source work through browser automation) and accessibility-agents contributions-hub (maintainer-side community health) are adjacent.

Everything else was looked at once (README, license, last push), with this verdict:

Evidence worth reading

• Turzo, Sultana, Bosu, "From First Patch to Long-Term Contributor" (2025): https://arxiv.org/pdf/2407.04159
• Tan, Zhou, Sun, "Is It Enough to Recommend Tasks to Newcomers?" (ICSE 2023): https://arxiv.org/pdf/2302.05058
• Hoshikawa et al., "A Longitudinal Analysis of Good First Issue Practices" (EASE 2026): https://arxiv.org/abs/2604.27532
• Xiao et al., "Recommending Good First Issues in GitHub OSS Projects" (ICSE 2022): https://hehao98.github.io/files/2022-recgfi.pdf
• Steinmacher, Pinto, Wiese, Gerosa, "Almost There" (ICSE 2018): https://www.ime.usp.br/~gerosa/papers/icse2018-Pinto.pdf
• Google, how organizations filter low-quality proposals: https://developers.google.com/open-source/gsoc/resources/spam_proposals
• Google, GSoC contributor guide, making first contact: https://google.github.io/gsocguides/student/making-first-contact
• Google, AI tooling guidance: https://developers.google.com/open-source/gsoc/resources/ai_guidance

Projects and sources examined

Checked on 2026-10-20 and 2026-10-21 by reading source, documentation, issues, or live endpoints. "Status" records what could and could not be verified. Ideas only; no code was reused.

Guide contents · Sources and limitations

Source: docs/research.md on GitHub. Corrections are welcome.