Google Summer of Code/2022/Application Guidelines

This guide is intended to be read by anyone who is interested in applying to Gentoo in the Google Summer of Code. Interested students need not be Gentoo developers; anyone who meets the eligibility requirements of Google is encouraged to apply.

Communication
Students interested in applying to do a project for Gentoo should join on the Libera.Chat IRC network and the gentoo-soc mailing list. Announcements related to Gentoo's Summer of Code effort will be relayed to both places

Requirements:
 * 1) Please start using Gentoo if you're not already. This is critical for several reasons (need to have investment in the project, need to understand the landscape and ecosystem and problems to solve, etc).
 * 2) See our Contribute to Gentoo page to learn more about our workflows and how to get started.
 * 3) Ideally propose working on a problem that affects you or you have a real interest in.

Get feedback on your idea
Students interested in applying to do a project for Gentoo should review the projects. Each project should have a potential mentor listed, who you should contact to discuss your idea before applying. You are free to apply for a project that is not on our list. In either case, once you have an idea of what you want to work on, find a potential mentor to discuss it with. The gentoo-soc mailing list, or any of the listed mentors on the ideas page should be able to provide feedback.

Write a proposal
Students should author a proposal that attempts to convince Gentoo why their project should be chosen over other competing proposals. A few sentences is not sufficient in most cases to sway anyone.

For Gentoo, the coding period should not explicitly include time to learn, research, investigate, etc. Your initial research should be done before writing the proposal, to convince us that you know enough about your project to understand it and complete it successfully. If further dedicated time for research/learning is required, it should happen during the community-bonding period, which comes before the coding period.
 * 1) Abstract - What does the project do; try to keep this section to one paragraph. It should not be an in depth analysis but is helpful when someone desires an overview of the project.
 * 2) Objective - What problem does the project solve. This does not need to be a long section. Generally software tries to help make people more efficient, or foster communication, or entertain folks. Any proposed software should have a purpose and applicants should define that purpose here.
 * 3) Deliverables - What will the project consist of when it is finished? Source code, documentation, a build system, libraries, binaries; these should all be enumerated in your proposal. Without a concrete set of deliverables it is difficult to judge if a student finished their proposal. If it is difficult to judge if the proposal was finished, it is difficult to pay for the work as well.
 * 4) Timeline - When will the deliverables be done? This is very important for the mid-term evaluation as the mentor has to determine if a given student has made enough progress to award them money. A student should strive to make this as easy for the mentor as possible by providing a bar to be measured by and then meeting that bar. A student should be careful to make good judgements in time costs and if the student slips behind he/she should alert their mentor to this fact and explain why the estimates were wrong. Your timeline should be at a level of detail of one work item every 1-2 weeks, and the items should be technically detailed.
 * 5) Biography - The student should talk about themselves: where they are from what they like to study, what they do in their free time, etc. Part of this contest is to make new friends and learn about each other and this is an important part of that goal. This section should include things like previous jobs, internships, and any educational experience an applicant may have. This section is also intended to promote oneself and convince Gentoo that we should chose a given student over other applicants.

We understand that sometimes implementations cannot match the proposal, and further experimentation and research may be necessary while implementing any given week's work, but this falls under the time for the implementation itself rather than devoting a week to research.

We highly recommend having some initial discussion with one of the mentors about your proposal before you submit it.

Submitting your proposal
Next, you must submit the proposal to the Google program site. Google provides documentation for this process.