How to talk to GSoC mentors (without being annoying)

If you only do one thing before submitting your GSoC proposal, talk to the mentors. Mentor communication is the single highest-leverage move available to a first-time applicant — by a wide margin. The students who get accepted are almost universally the students whose names mentors recognized before they read the proposal.

But "talk to mentors" is also the single thing students do worst. Most applicants either don't talk to mentors at all, or they talk to mentors in ways that actively hurt their candidacy. This guide is about how to do it well.

Why mentor communication matters

Mentors don't get to spend equal attention on every proposal. They might receive 50 to 500 proposals across all slots. Reading every one carefully is impossible. So they prioritize: proposals from contributors they recognize get a careful read; everything else gets a 30-second skim.

Becoming "recognized" is not magic. It's the cumulative effect of small, useful interactions over a few weeks. Mentors who recognize your name will give your proposal a fair shot. Mentors who don't, won't.

Where mentors actually are

The first job is figuring out where the mentor team is reachable. This is org-specific. Common venues:

• Org's official mailing list or forum (oldest and often most active)
• Org's Discord, Matrix, or IRC channel
• GitHub issue threads on the project ideas
• Mentor's personal email (only if explicitly invited)

You should figure this out from the org's contribution guide or GSoC project ideas page. If it's not obvious, ask in the public channel where the org is most active. Don't email mentors privately as a first contact — it reads as bypassing the public channel.

The first message

Your goal in the first message is one thing: demonstrate you've read the project description and have a specific, useful question.

A good first message looks like:

"Hi! I'm interested in the [Project name] idea. I've been reading [specific file in the codebase] and I noticed [specific observation]. I'm thinking the implementation might [specific approach]. Two questions: (a) is [specific aspect] a hard requirement, or is there flexibility? (b) Has the team considered [alternative approach] in the past?"

This message:

• Names the project specifically
• Shows you've read actual code
• Asks specific questions that require expertise to answer
• Is short

A bad first message looks like:

"Hi, I'm interested in GSoC and would love to contribute! Can you tell me where to start?"

This message says nothing about the project. It puts all the work on the mentor. It signals you haven't done basic homework. Mentors get this exact message 30 times per week and learn to ignore it.

The "small PR before any conversation" rule

Many strong applicants treat mentor communication as a result of contributing, not a precondition. They open a small, useful PR before introducing themselves. The PR introduces them. Then a follow-up message in the project channel — "hi, I just opened PR #1234 — does this match what you'd want for issue #5678?" — gets immediate, friendly attention.

This is the meta-strategy: skip the introduction step. Make a contribution. Then introduce yourself in context.

Cadence: how often to message

Once you're in conversation, the right cadence is: respond when they respond, plus one or two proactive updates per week. A weekly "hey, here's what I've been working on" is genuinely useful to mentors and shows you're consistent.

Anti-pattern: messaging the mentor 5 times in a week, every week. This is exhausting for them and signals neediness. If they take a week to respond, that's normal — mentors have day jobs.

What not to ask

There are specific questions that signal "I have not read the project description" and tank your standing instantly:

• "Will I get accepted if I write a good proposal?" (Mentors cannot answer this.)
• "Is anyone else working on this idea?" (Doesn't matter; the slot is competitive regardless.)
• "Can you review my draft proposal?" (Most orgs explicitly forbid this.)
• "Can you guarantee a recommendation letter?" (No.)

What's appropriate to ask:

• Clarifications on technical scope or requirements
• Whether a specific approach is acceptable
• Where in the codebase a piece of functionality lives
• What test framework / contribution conventions to follow
• How they want progress communicated during the coding period

Asking for proposal feedback

Most orgs have an explicit policy about pre-submission proposal review:

• Some orgs encourage you to share a draft for feedback (read the contribution guide).
• Most orgs decline to give feedback before the official submission.
• A few orgs require you to share your proposal in a specific channel for community review.

Read the org's policy and follow it. Don't ask for review unless review is invited.

If review is invited: share early (3+ weeks before deadline), be specific about what kind of feedback you want, and act on the feedback you get. "Thanks for the suggestion!" without changes is worse than no feedback at all.

When mentors don't respond

Sometimes you message and get crickets for days. This is normal. Mentors are volunteers, on day jobs, in different time zones, and during application season they are slammed.

Wait at least 4–7 days before bumping. When you bump, do it once, with new information ("I've thought more about your suggestion and tried this — does that look right?"). Don't bump twice without new information.

If you still get nothing after a bump, move to the public channel: post the question in the project's main forum. Other community members may answer, or the silence may be a signal that the org isn't actively mentoring this project.

After submission

Many students disappear after submitting their proposal. Don't. Even after the deadline, keep contributing small useful things — review another contributor's PR, file a small bug fix, write documentation. This isn't to "score points" (selection is usually decided in the first 2 weeks after the deadline). It's because consistent contribution post-deadline shows mentors you're someone they want to work with for 12 weeks.

A note on tone

Be warm but professional. Use the mentor's name. Say thanks when they help. Acknowledge their time. Don't grovel — mentors are not impressed by grovelling and it's actually exhausting for them.

The vibe you want to project: a curious, capable peer who's excited to learn. Not a desperate student begging for a slot.

See also

• How to pick a GSoC organization
• Proposal structure explained
• Common rejection reasons