The Sugar Labs GSoC guide explains how to apply, and what Sugar Labs expects from you

What this repository is

The repository is a guide for participating in Google Summer of Code with Sugar Labs, and the top-level entries match that description exactly. There is README.md, Ideas-2026.md, Template.md, an archives/ directory and an assets/ directory, plus a gh-md-toc entry that appears to be the tool used to generate the table of contents.

The current cycle's contents are three files. The Ideas-2026.md file lists the projects on offer, Template.md is a proposal template you may use or replace with your own, and the README is the guide itself. The shortcuts table at the top of the README links the first two and the Sugar Labs GitHub organisation.

The archives are the other half. The README lists project archives going back to 2009, with the years 2009 to 2018 hosted on the Sugar Labs wiki and the years 2019 to 2025 as Markdown files in the archives/ directory. Seventeen years of past projects is a useful thing to have, because it shows what kind of work the organisation actually takes on and how the scope of each project has been set.

Sugar Labs is described as a Google Summer of Code 2026 mentoring organisation, and the README opens by pointing at Google's own description of the programme as a global program focused on bringing more student developers into open source software development.

The primary language of the repository is recorded as Shell, which is a little odd for a documentation repository and probably reflects the tooling rather than the content. The licence is recorded as unknown, there are no GitHub releases, and the last push was on 2026-09-01, which is when the 2026 cycle would be in its application phase.

The proposal requirements, which are stricter than Google's

The most operationally useful section of the README is the list of requirements for Sugar Labs proposals, because it adds several conditions on top of the Google Summer of Code requirements for a proposal.

A proposal must be your own work, and not the work of others, except where the work of others is minimal, duly credited and quoted.

It must show you are fluent in the programming language needed.

It must show your assessment of the competency of your mentors.

That third one is unusual. Most programmes do not ask you to evaluate your own mentors in the proposal; Sugar Labs does, on the reasoning that the student is the one who has to work with them for a summer and is therefore the one who can judge whether the proposed support is real. A proposal that names a mentor without any assessment of their competence is treated as incomplete.

Then the format rules. A proposal should be posted to the sugar-devel mailing list as GitHub Markdown or PDF, and supported with answers to any questions posted in reply.

And the negative form of the same rule, which is worth reading carefully because it explains itself. A proposal should not be posted to the mailing list as a Google Docs, because a document can change after you send the link, a document can disappear, the export feature may be turned off, and the reviewers do not want to require community members to use Google Docs.

That is a specific, reasoned objection rather than a general dislike of a tool, and it is about the integrity of the artefact the reviewers read. A PDF or a Markdown file in a repository is fixed at the moment of posting.

The README also handles a case that many programmes leave ambiguous. Students who wish to be able to delete their proposal after failing to win a project should not post it on the mailing list, and the decisions will be based on the contents of the final PDF proposal and on the interactions with the student.

So there is a real trade-off here. Posting to the list gives your proposal public visibility and an answer thread, at the cost of not being able to withdraw it.

How to talk to the community

The section titled How to talk to us is short and unusually concrete about how not to behave.

The sugar-devel mailing list is the main channel, and the README asks you to join to participate in the discussion and ask for help, with the caveat to allow some days for reply. There is also a matrix channel for talking with other community members.

Then the rule that matters most, and it is one that experienced open source contributors will recognise as the difference between a proposal that gets work and one that does not. Do not write secretly to mentors or developers unless they have asked you to. This varies by idea, and the README says to check the list of coding mentors for each idea, because contact methods have been added per idea.

The Getting Help section expands on the same theme with a warning that is easy to miss. The Sugar Labs community is large, and there are people who are not mentors in the contest, and everyone else you talk with may be a non-mentor.

The advice to students is to keep in mind that some people are non-mentors and cannot see the contest progress, dates, or information about students. When communicating widely, students are told to introduce themselves the first time, talk about the task as if they want to do it themselves rather than because of the contest, and defend their technical decisions without using the contest as a defence.

The last point is the sharpest one. Non-mentors may give good guidance on technical decisions but bad guidance on how they think a task is judged, so always consult with your mentors as well.

That is a real hazard in a community of this size, where the same mailing list carries contest business and ordinary development discussion. The practical consequence for a student is that a technical answer from the list is not a decision, and treating it as one is how a project goes wrong in month two.

The community etiquette section

The etiquette section is the kind of document that sounds like boilerplate until you read the specific instructions in it.

Everyone in the community has to be polite and respectful, and consider everyone else a member of a team and not a competitor.

One should be considerate to everyone else's time, and the organisation would like to have quality discussions, and not answer questions that are already documented, or available on stackoverflow.

Then the distinction that makes the rule workable: this doesn't mean you can't ask questions, but a clueless user and a lazy developer are two different things.

That is a sharper formulation than the usual request to do your research first. It does not forbid asking; it asks you to have tried, and it distinguishes a person who has not understood the project from a person who is choosing not to investigate. A reviewer reading a question cannot tell those apart, so the guidance is really written for the reader.

The rest of the section is about honesty. Tell things as you see them, and be polite, but don't sugar coat it. And on apologies: you don't have to apologize every time you make a mistake, but avoid repeating it.

There is a Code of Conduct linked as well, hosted in the sugar-docs repository, so the formal rules and the informal guidance sit in two different places.

The contributing guidance is linked out to sugar-docs as well, with pages for opportunities and for the programming languages and libraries the projects use. Sugar Labs runs a wide range of projects, and the languages page is the practical way to find out whether the language you write in has anything to contribute to.

What Sugar Labs looks for in a student

The section titled Right fit is a list of what the organisation calls our perfect student, and it is the most revealing part of the guide because it describes a person rather than a project.

The list starts with evidence of habit rather than skill: you have a GitHub profile with a history of commits, pull requests, and issues in our project, other projects, or personal projects.

Then patience with review: you are patient to apply every suggestion during a pull request review.

Then care that goes past the ticket: you care about our project beyond the specific task you are working on, and about changes to documentation, tests, releases, issues.

Then the ability to hold a conversation: your conversation with us is more than the topic you are working on, but flows naturally to any topic, and you are able to have a proper technical discussion, and understand the value of the discussion in itself.

And then independence: you don't just say yes and do something because a mentor says so.

The remaining items are about the community and about honesty. You are interested in our community and follow our code of conduct and guidelines. You keep working with our community even if you are not accepted. You have contributed to our project before the application period. You can engage in tight feedback loops around design discussions in proposal drafts. You don't ask for help to write a proposal. You don't remain ignorant of our software or what our project does. You always write in public, and never write to a mentor in private unless the mentor has asked for that. You work on a project our community needs, regardless of your personal interests. And you don't just fix issues, but you also get involved in other people's work.

Read as a whole, this is a specification for a specific kind of contributor. Several items, contributing before the application period, keeping working after rejection, getting involved in other people's work, are behaviours that only make sense if the student is joining a community rather than collecting a placement.

Where this guide fits, and where it stops

The comparison worth making is with Google's own Summer of Code guides and with the archives of previous years.

Against Google's guidance, the difference is that Google's is generic and this one is organisational. Google tells you what a proposal should contain; the Sugar Labs README tells you that your proposal must include an assessment of your mentors' competency, must not be posted as a Google Docs link, and that writing privately to a mentor will count against you unless they asked for it. None of that is in the generic guidance, and all of it would be a rejection risk for someone who had only read Google's.

Against the archives, the difference is that the archives are evidence rather than instruction. Ideas-2026.md is what the organisation wants this year, and the seventeen previous years show how those ideas have actually been scoped in practice, which is a different thing from how they are written down.

The limits are worth naming. This is a documentation repository with no source code, so there is nothing to build, run or test, and the ideas, template and archives are the whole of it. The information is a snapshot of one application cycle, with the ideas list living in a file named for 2026 and no indication of how it changes. The licence is not recorded, which matters if you want to reuse the template or the ideas list verbatim in a proposal for a different organisation.

And the guide is written for students, not for mentors. The README says the decisions will be based on the contents of the final PDF proposal and on the interactions with the student, which puts the burden of the interaction on the person who has not yet been selected.

On maintenance, the pattern is clear from the archive structure. The early years are wiki pages and the recent ones are files in the repository, so the project has been progressively moving its own documentation away from the wiki and into version control, which is where a proposal template belongs.

For anyone planning to apply to Sugar Labs, the practical order is the one the README implies. Read the ideas, pick one, make sure you can already write the language it needs, get a commit into one of the Sugar Labs projects before the application period, then write the proposal with the template and post it as Markdown or PDF to the mailing list.

Editorial conclusion

The Sugar Labs GSoC guide suits a student preparing a proposal for a Sugar Labs project, since it states the proposal requirements in full, links the current ideas list and template, and sets out what the organisation looks for in a student before and during the contest. It is the wrong tool if you want to see the code, since this repository holds documentation and no source, and the actual Sugar Labs projects live in the sugarlabs GitHub organisation. Before you write anything, read the proposal requirements for Sugar Labs alongside Google's own proposal guidance, and post your draft as GitHub Markdown or PDF to the sugar-devel mailing list rather than as a Google Docs link.

Frequently asked questions

Official sources

1. Issues
2. README
3. sugarlabs/GSoC on GitHub