| layout | title | navbar |
|---|---|---|
default |
SoC 2020 Organization Application |
false |
This is a draft of git's application to Google's Summer of Code 2020.
fast, scalable, distributed revision control system
GPLv2
Programming Languages and Development Tools
c, shell script, git
version control, dvcs
https://git.github.io/SoC-2020-Ideas/
Git is the most widely-used revision control system in Open Source. It is a distributed system with an emphasis on speed, data integrity, and support for many workflows.
Git is the most widely-used revision control system in Open Source. It is a distributed system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows.
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.
This organization covers projects for Git itself. Other git-based software or services are not covered by this organization.
Guidance for students on how to apply to your organization. Should
include any prerequisites or requirements. You may wish to include a
template or tips for their proposals. May include limited Markdown.
Please read the "General Application Information" page: https://git.github.io/General-Application-Information/
The primary way to contact the Git community is through the Git mailing list [email protected]. Please discuss your application on this list.
Enter tags that students can select (one) from and apply to their own
proposals to help organize them. Examples: New Feature, Optimization.
You can also use these to designate "sub-organizations" if you are an
umbrella organization.
new feature, refactoring, bug fix
You must complete at least one of the following three contact options.
Chat: https://git-scm.com/community
Mailing List: https://git-scm.com/community
General Email: [email protected]
(Left blank)
(Left blank)
With the exception of 2013, Git has participated in GSoC every year since 2007. We have appreciated not only the code contributions (both new features and internal refactoring to reduce the maintenance effort), but also the increased project visibility and the addition of new long-term contributors. We also believe strongly in helping students become comfortable contributing to open source in general, even if they do not remain involved with Git itself.
dropdown list => 1-5.
Text below unused:
We have 3 potential co-mentors this year. This is a small number, and
we expect to take a correspondingly smaller number of projects
(probably only 1).
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, and well-known to the project leadership.
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.
1000 characters.
We think that the most important part of GSoC is integrating the student into the normal communication channels used by other project members. 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.
If they do disappear, we'll obviously contact them and find out what's going on. But ultimately, non-communication is grounds for a failing evaluation, regardless of any code produced.
We plan to take fewer projects than we have as mentors. We usually have two co-mentors per students, so that one mentor being unavailable would have a limited impact on the project. Most of our projects can be mentored by any of the mentors, and by keeping student progress public and reviewed on-list, another mentor (or the community at large) can pick up the slack if needed.
1000 characters.
There are several ways to do this, and they have been successful in the past:
-
Prepare students to submit patches before they started. We use a microproject system prior to the student application where students must submit at least a patch, and respond to reviews. This means that on day 1 of their project, students already know how long review cycles are, and how important it is to work with the mailing-list.
-
Split the work into small patch series. 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. Even if the first patch series are only preparatory steps that do not bring a real added value to Git, it is important to get them merged as early as possible. Even if the project is not "completed", useful pieces of code are validated all along the project.
1000 characters.
Students will be required to join the main development mailing list and post their patches for discussion (in addition to posting their work as a Git repository on a publicly available server). 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.
Mentors will also exchange direct email with students on at least a weekly basis. Students will be required to provide weekly progress reports back to their mentors, so that mentors are aware of the current difficulties. Progress reports 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.
Unused text (did not fit the characters limit):
The traffic on the list is focused around Git 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.
Many developers either already hold "office-hours" on IRC, or have
agreed to do so during the GSoC period.
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.
Yes
Every year since 2007 except 2013.
For each year your organization has participated, provide the counts of successful and total students. (e.g. 2016: 3/4)
500 characters
2007: 2/3 2008: 4/6 2009: 1/2 2010: 3/4 2011: 5/5 2012: 3/3 2014: 2/3 2015: 2/2 2016: 1/1 2017: 1/1 2018: 3/3 2019: 2/2
(Left blank)
None.
(Left blank)
2005
No
We sometimes write about the GSoC in our Git Rev News newsletter (https://git.github.io/rev_news/archive/).
The 2015 application had a question "If you chose "veteran" in the organization profile dropdown, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year." with a very detailed answer.