Google Summer of Code/2016/Organization application
- 1 Your details
- 1.1 Why does your org want to participate in Google Summer of Code?
- 1.2 How many potential mentors have agreed to mentor this year?
- 1.3 How will you keep mentors engaged with their students?
- 1.4 How will you help your students stay on schedule to complete their projects?
- 1.5 How will you get your students involved in your community during GSoC?
- 1.6 How will you keep students involved with your community after GSoC?
- 1.7 Has your org been accepted as a mentoring org in Google Summer of Code before?
- 1.8 Which years did your org participate in GSoC?
- 1.9 What is your success/fail rate per year?
- 1.10 If your org has applied for GSoC before but not been accepted, select the years:
- 2 Public Profile
- 2.1 Website URL
- 2.2 Tagline
- 2.3 Primary Open Source License
- 2.4 Organization Category
- 2.5 Technology Tags
- 2.6 Topic Tags
- 2.7 Ideas List
- 2.8 Short Description
- 2.9 Long Description
- 2.10 Application Instructions
- 2.11 Proposal Tags
- 2.12 IRC Channel
- 2.13 Mailing List
- 2.14 General Email
- 2.15 Google+ URL (optional)
- 2.16 Twitter URL (optional)
- 2.17 Blog URL (optional)
Why does your org want to participate in Google Summer of Code?
We intend to recruit enthusiastic, experienced, high-quality Gentoo developers to maintain the growth and health of our developer community and its many derivative distributions: Google's ChromeOS; CoreOS, the Linux for massive server deployments; Calculate Linux; Sabayon Linux; etc... We also help and take under our GSoC umbrella a number of OSS projects which are not Gentoo-specific and sometimes not even directly related to Gentoo. This year we have: Eudev, oVirt, imapfw, OpenRC.
How many potential mentors have agreed to mentor this year?
How will you keep mentors engaged with their students?
Gentoo's training and recruiting process is well known for being thorough. We have reliable mentors with great social skills and years of experience in mentoring GSoC students or new Gentoo developers. Less experienced mentors, or those coming from other organizations, will always be paired with a trusted and experienced one. We have a pool of backup mentors ready to jump in temporarily or permanently if needed. We also have expert mentors who are called in on an as-needed basis to advise on specific, usually technical, topics. We have a mentor-specific IRC channel where mentors can discuss and exchange advice. The administrators will contact them at least 2-3 times a week to inquire about progress of their student, how the relationship is going, etc... Mentors are asked to conduct a weekly review with their student in an IRC channel and in the presence of an administrator. Finally, mentors always have a personal interest in the project they're mentoring.
How will you help your students stay on schedule to complete their projects?
Before they start, we discuss with them their daily schedule and all practical aspects. Any other activities during GSoC? Exams? Do they have a suitable place to work with internet access? We require a physical address and phone number, and we will confirm the phone number at the start of the program. We ask them to take 5 minutes at the end of each workday to answer the following questions, in one line or so, everyday: What was your plan for the day? Did you accomplish that? Why? What is your plan for tomorrow? In case they stop communicating we will try to contact them by any mean, including having someone near them geographically (the Gentoo community covers almost the entire world) try to get in touch. After one week and without any advance notice from them, they will be sent a final warning. If we hear nothing by the following day, they will be failed. Students will be informed of this policy when the program starts and will agree to follow it.
How will you get your students involved in your community during GSoC?
We will strongly encourage applicants to interact with the community using our standard communication methods (mailing lists and IRC) before and during the application & evaluation periods. In fact, this will be part of our custom application template. If they cannot learn to do it during that month-long period, we can't expect that they will learn to do so during the next few months. That will count against them in the ranking of their application. Since communication will be one of the requirements for a successful application, we expect that problems during and after the program will be much rarer. We will treat students in the same way we treat our new developers, a significant portion of whom are college students just like the applicants. By encouraging students to communicate directly with the community instead of privately with their mentors, we will infuse them with the process of open-source development.
How will you keep students involved with your community after GSoC?
It mostly boils down to treating them as being full Gentoo developers during GSoC and integrating them into the Gentoo community right from the start of their project. Donnie Berkholz wrote a detailed blog post on what we do here: http://redmonk.com/dberkholz/2012/07/10/how-to-recruit-open-source-contributors/ Here's a summary: Step 0: Set goals and measure progress Step 1: Establish the expectation that most contributors become long-term developers Step 2: Make them interact as true community members, not through a mentor’s conduit Step 3: Don’t let them slip away. Sometimes, all you have to do is ask
Has your org been accepted as a mentoring org in Google Summer of Code before?
Which years did your org participate in GSoC?
2014 2013 2012 2011 2010 2009 2008 2007 2006
What is your success/fail rate per year?
2006: 10/14 2007: 8/9 2008: 5/6 2009: 6/7 2010: 16/19 2011: 14/15 2012: 8/8 2013: 6/7 2014: 3/4
If your org has applied for GSoC before but not been accepted, select the years:
A flexible, source-based Linux distribution.
Primary Open Source License
GNU General Public License version 2.0 (GPL-2.0)
shell script c/c++ python perl sql
virtualization security linux embeddded operating systems
Flexible, source-based Linux distribution which becomes just about any system you need — and much more.
Every user has work they need to do. The goal of Gentoo is to design tools and systems that allow a user to do that work as pleasantly and efficiently as possible, as they see fit. Our tools should be a joy to use, and should help the user to appreciate the richness of the Linux and free software community, and the flexibility of free software. This is only possible when the tool is designed to reflect and transmit the will of the user, and leave the possibilities open as to the final form of the raw materials (the source code.) If the tool forces the user to do things a particular way, then the tool is working against, rather than for, the user. We have all experienced situations where tools seem to be imposing their respective wills on us. This is backwards, and contrary to the Gentoo philosophy.
Put another way, the Gentoo philosophy is to create better tools. When a tool is doing its job perfectly, you might not even be very aware of its presence, because it does not interfere and make its presence known, nor does it force you to interact with it when you don’t want it to. The tool serves the user rather than the user serving the tool.
The goal of Gentoo is to strive to create near-ideal tools. Tools that can accommodate the needs of many different users all with divergent goals. Don’t you love it when you find a tool that does exactly what you want to do? Doesn’t it feel great? Our mission is to give that sensation to as many people as possible.
Students interested in applying to do a project for Gentoo should join #gentoo-soc on the Freenode IRC network and the firstname.lastname@example.org mailing list. Announcements related to Gentoo's Summer of Code effort will be relayed to both places.
You can choose among our project ideas or come up with your own. The gentoo-soc mailing list, the gentoo-soc IRC channel or any of the listed mentors can provide feedback.
Write a proposal attempting to convince us why your project should be chosen. A few sentences is not sufficient in most cases to sway anyone.
Abstract. Try to keep this section to one paragraph. It should not be an in depth analysis.
Objective. What problem does the project solve? This does not need to be a long section.
Deliverables. What will the project consist of when it is finished? Source code, documentation, a build system, libraries, binaries. These should all be enumerated and described in details in your proposal.
Timeline. When will the deliverables be done? This section needs to be chronologically and technically detailed.
Biography. Tell us about yourself.
We highly recommend having some initial discussion with one of the mentors about your proposal before you submit it.
More information at: https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2016/Application_Guidelines
new feature improvement eudev ovirt imapfw openrc