| layout | title |
|---|---|
default |
SoC 2022 Organization Application |
This is a draft of git's application to Google's Summer of Code 2022.
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
Yes
Every year since 2007 except 2013.
Accepted
fast,scalable,distributed revision control system
GNU General Public License version 2.0 (GPL-2.0)
2005
Programming Languages and Development Tools
c language, shell script, git
version control, dvcs
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.
https://git.github.io/General-Application-Information/
Chat: https://git-scm.com/community
Mailing List / Forum: https://git-scm.com/community
General Email: [email protected]
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.
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.
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.
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.
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.
We sometimes write about the GSoC in our Git Rev News newsletter (https://git.github.io/rev_news/archive/).
No
https://git.github.io/SoC-2022-Ideas/
How many Mentors does your Organization have available to participate in this program?
5
2
1