| layout | title |
|---|---|
default |
SoC 2014 Organization Application |
This is a draft of git's application to Google's Summer of Code 2014.
Git
peff? / spearce? / trast?
Git is the most widely-used distributed revision control system in Open Source. Many large and successful projects use git, including the Linux Kernel, Perl, Eclipse, Gnome, KDE, Qt, Ruby on Rails, Android, PostgreSQL, Debian, and X.org.
vcs, c, git
GPLv2
They've asked that the image be 65x65 or smaller, so we probably need to shrink this and put it somewhere.
http://git.github.io/SoC-2014-Ideas.html
#git and #git-devel (on freenode)
Yes (we participated before)
We can't go further in the application process without a backup admin registered. I grabbed the following question list from the GSoC FAQ (so it may not be complete).
All mentors are volunteers for the specific projects that they can contribute the most to (i.e., ones that meet their interests and abilities). All mentors are active contributors within the Git development community.
Active contributors are defined to be those who have submitted and have had accepted into a shipped release a substantial amount of code, where substantial is defined to be equal to or larger than what might be expected of a student working on a Google Summer of Code project.
We think that the most important part of GSoC is integrating the student into the normal communication channels used by other project participants. We don't expect regular developers to go silent for 3 months and then dump 10,000 lines of code on us to review, and we don't want students to do that to us either. The first step in dealing with disappearing students is to make sure they are engaging with the community on design and code issues, and reaching small milestones on the way to the project. Then if they do disappear, we know quickly and can react, rather than being surprised at the end.
Once they do disappear, we'll obviously try to contact them and find out what's going on. But ultimately, non-communication is grounds for a failing evaluation, regardless of any code produced.
Most of our projects have more than one mentor available. In the unlikely event that a mentor disappears during the summer, another mentor can step in. By keeping student progress public and reviewed on the list, there's a good chance that another mentor (or the community at large) can pick up the slack. We try to keep the "bus factor" low for regular development, and we should do it for mentors, too.
What steps will you take to encourage students to interact with your project's community before, during and after the program?
Students will be required to join the main development mailiing list and post their patches for discussion. All current contributors already do this, so students will be able to see experienced hands performing the same tasks and learn by example. We also feel that the list based discussions will help the student to become and stay a member of the community.
The traffic on the list is focused around Git feature development. We expect the students to stay current by at least skimming the messages, and participating in discussions that are close to their area of work.
Students will also be required to post their work as a Git repository on a publicly available server so that their works-in-progress will be available for everyone to review. However, as patch review typically happens on the mailing list, we expect that to be the main venue for review of the students' work.
Mentors will also exchange direct email with students on at least a weekly basis, if not more frequently. Students will be required to provide weekly progress reports back to their mentors, so that mentors are aware of the tasks that a student might be stuck on or are having difficulty with. The intent of the progress reports is to give the mentors a chance to provide suggestions for problem resolution back to the student.
Frequent email and IRC interaction with mentors and other developers will be strongly encouraged by suggesting students post their questions and ideas to the mailing list, and to discuss them on #git. Many developers either already hold "office-hours" on IRC, or have agreed to do so during the GSoC period.
Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here.
N/A
Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here.
N/A
What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes?
Ultimately we have no leverage over the students after they leave, so the best we can do is to help them form habits of interaction that they might find rewarding and want to continue with. We specifically don't want to give the student a "half project" that needs more work after the GSoC period is done. That's not fair to the student, nor to the project.
Instead, we'd prefer to get the student involved in the day-to-day of interacting on the mailing list, reviewing code, and commenting on other people's ideas and problems. Those are things they can continue to do after GSoC ends, and those discussions can often spur more coding.