Skip to content

What Is a GSoC Proposal?

A proposal is your formal application to work on a project for GSoC.

  • It explains what you want to do, how you will do it, and why you are capable.
  • Think of it as a project plan + proof of ability + roadmap.
  • Unlike pull requests, a proposal is evaluated for feasibility and trust, not just coding skill.

In short: a strong proposal can matter more than 5–10 PRs.

Why Do We Write a Proposal?

  1. Communicate your plan to mentors.
  2. Show feasibility—you know what can realistically be done in the coding period.
  3. Demonstrate trust—mentors see that you can organize and finish a project.
  4. Convince the committee why you should get a GSoC slot over hundreds of applicants.

Where to Apply

How Many Proposals Can You Submit?

  • Up to 3 proposals per student.
  • Recommended: focus on 1–2 strong proposals, not 3 weak ones.
  • Quality > quantity.

When Can You Edit Your Proposal?

  • You can edit your proposal until the submission deadline (usually mid-April).
  • After the deadline, you cannot upload a new proposal—only minor corrections may be allowed for formatting.

Tip: Don’t wait until the last day—mentors may give feedback during the community bonding phase.

Common Questions About Proposals

Why do some organizations collect proposals early?

  • They may ask for early drafts before the portal opens.

  • Purpose:

  • Mentor meetings to discuss feasibility

  • Early feedback to improve the proposal
  • Pre-selection discussions
  • Early submission shows seriousness and commitment.

What a Good Proposal Should Contain

  1. Title – short, clear, and specific
  2. Abstract / Summary – 2–3 sentences explaining what you will do
  3. Benefits to the community – why your project matters
  4. Deliverables / Milestones – divide the project into achievable steps
  5. Timeline – weekly or bi-weekly plan
  6. Technical details / approach – how you will implement it
  7. Qualifications / Experience – skills, PRs, previous contributions
  8. References / Links – prototype, demos, documentation

Optional: link to a working prototype or demo at the top. Mentors should understand your project within 30 seconds.

Proposal Writing – Reality

  • Follow the organization’s template strictly – they often reject proposals that ignore formatting.
  • Length: 6–8 pages (more is not better).
  • Prototype/Demo link: very helpful to show practical understanding.
  • Clarity matters more than fancy language.

Example: Instead of “I will improve the system”, write: “I will implement feature X by adding module Y, which will reduce setup time by Z%.”

How Organizations Review Proposals

  1. Committee of mentors reviews all submissions
  2. Internal discussion: mentors debate feasibility, student reliability, and prior contributions

  3. Selection criteria:

  4. Feasibility (can the project be completed?)

  5. Trust (can the student deliver?)
  6. Prior interaction (PRs, prototype, discussions)
  7. Direct communication helps – asking clarifying questions or discussing your idea can increase trust
  8. Demonstrated effort matters more than ideas alone – mentors prefer students who have already contributed or built a prototype.

Here is a clean, clear, and professional version of your last points, integrated smoothly with the proposal section. This is written so you can add it directly at the end of your guide.

Get Your Proposal Reviewed (Very Important)

1️⃣ Ask Mentors to Review Your Proposal

  • If possible, share your draft with the project mentors.

  • Mentors know:

  • what the organization actually expects

  • what scope is realistic
  • what usually gets accepted or rejected
  • Even small feedback from a mentor can greatly improve your proposal.

2️⃣ Ask Previous GSoC Contributors for Review

  • Reach out to past GSoC contributors from the same organization.

  • They have:

  • already gone through the selection process

  • experience with proposal evaluation
  • They often point out missing details or unrealistic timelines.

3️⃣ Review and Improve Your Proposal Regularly

  • Don’t write your proposal once and submit it.

  • Revise it every week if possible:

  • clarify goals

  • refine milestones
  • simplify explanations
  • Each revision should make the proposal clearer and more realistic.

4️⃣ Always Base the Proposal on Real Contributions

  • Proposals are strongest when based on:

  • accepted pull requests

  • real issues you worked on
  • prototypes you built
  • Reviewers trust proposals more when they see:

“This person already understands the project.”

  • When sharing your proposal (for review or feedback):

  • provide a clean, readable link

  • include context (project name, org, status)
  • mention what kind of feedback you want

Example message:

“Hi, this is my draft GSoC proposal for . I’d appreciate feedback on scope, feasibility, and clarity.”