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

Initial form

Organization Name

Git

Is this organization an established Open Source project or organization that releases code under an OSI approved license ? An OSI License is required for program participation.

Yes

Has your organization participated in Google Summer of Code before?

Yes

Please select all years in which your organization participated prior to 2022.

Every year since 2007 except 2013.

Agreement

Accepted

Organization Profile

Website URL for Organization

https://git-scm.com/

Logo

Tagline

fast,scalable,distributed revision control system

Primary Open Source License

GNU General Public License version 2.0 (GPL-2.0)

When year was your project started?

2005

Link to your source code location

http://github.com/git/git

Organization Categories

Programming Languages and Development Tools

Technology tags

c language, shell script, git

Topic Tags

version control, dvcs

Organization 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.

Contributor Guidance

https://git.github.io/General-Application-Information/

Communication Methods

Chat: https://git-scm.com/community

Mailing List / Forum: https://git-scm.com/community

General Email: git@vger.kernel.org

Organization Questionnaire

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 organization consider to be a successful GSoC program?

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 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.

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/).

Is your organization part of any government?

Program Application

Ideas List URL

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

Mentors

How many Mentors does your Organization have available to participate in this program?