Proposal Submission Guidelines
How to engage with OLake mentors and submit a strong GSoC proposal. Follow these guidelines to increase your chances of acceptance.
Communicate early and in public
Start discussions early in the community discussion period and keep technical discussion public.
Use GitHub issues/discussions and public Slack channels. Be respectful and concise. Introduce yourself, share your interest in a project, and ask clarifying questions before the application window closes.
Align with OLake contribution workflow
If you submit any code before selection:
- Follow OLake's PR guide
- Target the staging branch (feature branches should be created from staging)
- Prefer small, reviewable PRs (docs, tests, bugfixes)
- Link your PR(s) in your proposal
Demonstrate that you can run OLake locally
Your proposal should state:
- Which source + destination you used locally (e.g., Postgres → Iceberg)
- How you reproduced or tested the scenario locally
- Any scripts or docker-compose you used
Proposal format expectations
We strongly recommend you follow the official Writing a proposal guide.
Your proposal must clearly include:
- Required deliverables vs optional stretch goals
- Risks + mitigation
- Testing strategy (unit + integration where relevant)
- Documentation plan
How we evaluate proposals
We prioritize:
Show that you've read the docs and understand the Go → gRPC → Java writer flow.
Small (~90h), Medium (~175h), Large (~350h)—match your plan to the size.
Midterm should show meaningful progress; include buffer time and a "code freeze" period for tests/docs.
Prior OSS work or early OLake contributions (even a small PR or doc fix) strengthen your application.
Responsive, clear, and collaborative in public channels.
Where to ask questions
Reach out before and during the application period.
Submit your proposal
Submit your proposal via the GSoC web application before Google's deadline.
summerofcode.withgoogle.com