This is a draft of git’s application to Google’s Summer of Code 2021.

Organization Application

Why does your org want to participate in Google Summer of Code?

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.

What would your org consider to be a successful summer?

Students enjoying contributing improvements, learning and participating in the community. It would be even better if they continue to contribute and are willing to mentor other people after the Summer.

How many potential mentors have agreed to mentor this year?

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.

How will you keep mentors engaged with their students?

We think that the most important part of GSoC is integrating the students 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.

How will you help your students stay on schedule to complete their projects?

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.

How will you get your students involved in your community during GSoC?

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.

How will you keep students involved with your community after GSoC?

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.

Has your org been accepted as a mentor org in Google Summer of Code before?

Has your org been accepted as a mentor org in Google Summer of Code before?

Yes

Which years did your org participate in GSoC?

Every year since 2007 except 2013.

How many students did your org accept for 2020?

3

How many of your org’s 2020 students have been active in your community in the past 60 days?

3

For each year your organization has participated, provide the counts of successful and total students. (e.g. 2016: 3/4)

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 2020: 3/3

Is there an organization new to GSoC that you would like to refer to the program for 2021? Feel free to add a few words about why they’d be a good fit.

(Left blank)

If your org has applied for GSoC before but not been accepted, select the years:

None.

If you are a new organization to GSoC, is there a Google employee or previously participating organization who will vouch for you? If so, please enter their name, contact email, and relationship to your organization.

(Left blank)

What year was your project started?

2005

Where does your source code live?

http://github.com/git/git

Is your organization part of any government?

No

Anything else we should know (optional)?

We sometimes write about the GSoC in our Git Rev News newsletter (https://git.github.io/rev_news/archive/).

Organization Profile

Website URL

http://git-scm.com

Tagline

fast, scalable, distributed revision control system

Logo

Primary Open Source License

GNU General Public License version 2.0 (GPL-2.0)

Organization Category

Programming Languages and Development Tools

Technology Tags

c language, shell script, git

Topic Tags

version control, dvcs

Ideas List

https://git.github.io/SoC-2021-Ideas/

Short Description (180 chars max)

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.

Long Description

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.

Application Instructions

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 git@vger.kernel.org. Please discuss your application on this list.

Proposal Tags

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

Contact Methods

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: git@vger.kernel.org

Twitter URL (optional)

(Left blank)

Blog URL (optional)

(Left blank)