From fcbd92b30cc03bc62e75108924779434d230c61c Mon Sep 17 00:00:00 2001 From: Jeff King Date: Wed, 18 Feb 2015 11:30:50 -0500 Subject: [PATCH 0001/3116] add 2015 SoC materials These are mostly ported over from 2014, but: 1. I've marked all of the application answers as needing review. 2. I cleared the list of ideas and microprojects. We may port over entries from last year, but only once somebody has reviewed them. 3. I've listed microprojects as mandatory this year. --- SoC-2015-Ideas.md | 25 ++++ SoC-2015-Microprojects.md | 110 +++++++++++++++++ SoC-2015-Org-Application.md | 239 ++++++++++++++++++++++++++++++++++++ 3 files changed, 374 insertions(+) create mode 100644 SoC-2015-Ideas.md create mode 100644 SoC-2015-Microprojects.md create mode 100644 SoC-2015-Org-Application.md diff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md new file mode 100644 index 0000000000..395cd89efa --- /dev/null +++ b/SoC-2015-Ideas.md @@ -0,0 +1,25 @@ +--- +layout: default +title: SoC 2015 Ideas +--- + +This is the idea page for Summer of Code 2015 for Git and libgit2. + +## About applying for SoC with the Git project + +It is required that students who want to apply to the Git +project for the Summer of Code 2015 complete a tiny, code-related +"microproject" as part of their application. Please refer to our +[guidelines and suggestions for microprojects](http://git.github.io/SoC-2015-Microprojects.html) +for more information. Completing a microproject is not only an important +way for us to get experience with applicants, but it will also help +applicants become familiar with Git's development and submission +process. + +## Summer of code main project ideas + +**Students**: Please consider these ideas as starting points for +generating proposals. We are also more than happy to receive +proposals for other ideas related to Git or libgit2. + +*TODO* add entries :) diff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md new file mode 100644 index 0000000000..07d09e9c1a --- /dev/null +++ b/SoC-2015-Microprojects.md @@ -0,0 +1,110 @@ +--- +layout: default +title: SoC 2015 Applicant Microprojects +--- + +## Introduction + +It is strongly recommended that students who want to apply to the Git +project for the Summer of Code 2015 submit a small code-related patch +to the Git project as part of their application. Think of these +microprojects as the "Hello, world" of getting involved with the Git +project; the coding aspect of the change can be almost trivial, but to +make the change the student has to become familiar with many of the +practical aspects of working on the Git project. + +*NOTE: Students who plan to work on libgit2, which is also under the +Git umbrella in the Google Summer of Code, should refer to [the +libgit2 list of +projects](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md) +rather than the list below.* + +Consider [a sample email +thread](http://thread.gmane.org/gmane.comp.version-control.git/239068), +which shows how a developer proposed a change and a patch to implement +it. The problem being solved, the design of the proposed solution, +and the implementation of that design were all reviewed and discussed, +and after several iterations an improved version of the patch was +accepted into our codebase. As a GSoC student, you will be playing +the role of the developer and engaging in a similar discussion. Get +familar with the flow, need for clarity on both sides (i.e. you need +to clearly defend your design, and need to ask clarifications when +questions/suggestions you are offered are not clear enough), the pace +at which the discussion takes place, and the general tone of the +discussion, to learn what is expected of you. + +To complete a microproject, you will have to go through approximately +the following steps: + +* Download the source code: clone the repository using the [Git via + Git](http://git-scm.com/downloads) instructions and read the + `README` file. + +* Build the source code: this is described in the file `INSTALL`. + +* Glance over our coding guidelines in the file + `Documentation/CodingGuidelines`. We take things like proper code + formatting very seriously. + +* Read about the process for submitting patches to Git: this is + described in `Documentation/SubmittingPatches`. + +* **Make the actual change.** (Funny, this is the only part they teach + you about in college.) + +* Run the test suite and make sure it passes 100%: this is described + in the file `t/README`. (If you have added new functionality, you + should also add new tests, but most microprojects will not add new + functionality.) + +* Commit your change. Surprise: we use Git for that, so you will need + to gain at least + [a basic familiarity](http://git-scm.com/documentation) with using + Git. Make sure to write a good commit message that explains the + reason for the change and any ramifications. Remember to make sure + that you agree with our "Developer's Certificate of Origin" (whose + text is contained in `Documentation/SubmittingPatches`), and to + signify your agreement by adding a `Signed-off-by` line. + +* Submit your change to the Git mailing list. For this step you + probably want to use the commands `git format-patch` and `git + send-email`. Make sure that your email is formatted correctly: send + a test version of the email to yourself and see if you can apply it + to your repository using `git am`. + +* Expect feedback, criticism, suggestions, etc. from the mailing list. + + *Respond to it!* and follow up with improved versions of your + change. Even for a trivial patch you shouldn't be surprised if it + takes two or more iterations before your patch is accepted. *This + is the best part of participating in the Git community; it is your + chance to get personalized instruction from very experienced peers!* + +The coding part of the microproject should be very small (say, 10-30 +minutes). We don't require that your patch be accepted into master by +the time of your formal application; we mostly want to see that you +have a basic level of competence and especially the ability to +interact with the other Git developers. + +When you submit your patch, please mention that you plan to apply for +the GSoC. This will ensure that we take special care not to overlook +your application among the large pile of others. + +Students: Please attempt only **ONE** microproject. We want quality, +not quantity! (Also, it takes work to collect the ideas, and it would +be nice to have enough microprojects for everybody.) If you've +already done a microproject and are itching to do more, then get +involved in other ways, like finding and fixing other problems in the +code, or improving the documentation or code comments, or helping to +review other people's patches on the mailing list, or answering +questions on the mailing list or in IRC, or writing new tests, etc., +etc. In short, start doing things that other Git developers do! + +## Ideas for microprojects + +The following are just ideas. Any small code-related change would be +suitable. Just remember to keep the change small! It is much better +for you to finish a small but complete change than to try something +too ambitious and not get it done. + +*TODO* add entries diff --git a/SoC-2015-Org-Application.md b/SoC-2015-Org-Application.md new file mode 100644 index 0000000000..4f21c927d5 --- /dev/null +++ b/SoC-2015-Org-Application.md @@ -0,0 +1,239 @@ +--- +layout: default +title: SoC 2015 Organization Application +--- + +This is a draft of git's application to Google's Summer of Code 2015. + +## Organization name + +Git + +## Admin / Backup + +peff / ? + +## Description + +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. + +## Tags + +vcs, c, git + +## Main license + +GPLv2 + +## Logo URL + +![Git Logo](/images/logo.png) + +## Ideas list + + + +## Mailing list + +git@vger.kernel.org + +# Organization website + + + +## IRC Channel + + + +## Blog / Google+ / Twitter / Facebook + +We don't have any official versions of these. + +## Veteran organization + +Yes (we participated before) + +## 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. + +*TODO* possibly needs updating for 2015. Surely could manage to be less wordy? + +Git has participated in GSoC every year since 2007, with the exception +of 2013, typically mentoring 2-5 students each year. Our mentors have +always been active contributors within the community. The students +typically did not have a prior relationship with the community, though +in one case we took on a student who had previously contributed patches. + +Of the 23 projects we have mentored, 18 have resulted in success. In +many cases, the code has been merged and is in daily use in git. In some +cases, the code was spun off into its own project (e.g., the +git-statistics project in 2008 ended up as a separate project). In other +cases, the implementations, while never merged into mainline git, served +(or continue to serve) as the basis for discussion and advancement of +certain features (e.g., 2008's GitTorrent project and 2009's svn +interaction improvements). The libgit2 project, which has been the +subject of multiple GSoC projects, has gone from being an unusable +skeleton to a thriving ecosystem, with bindings in Objective-C, Python, +Ruby, C#, Lua, and more. While much of the work on libgit2 and its +bindings were not done through GSoC, the GSoC projects were instrumental +in getting the library to a point that attracted outside interest. + +But most important has been the development of students into open source +contributors. In almost every project, even those whose ultimate goals +did not end up merged into mainline git, students ended up contributing +related commits to git. Furthermore, we have had success with retaining +members in the community. Close to half of our successful students +continued contributing in the year after their GSoC involvement, and the +student from our 2010 libgit2 project has essentially become the project +maintainer. + +One of the biggest challenges has been integrating students into the +public development process, and especially convincing them to produce +and publish work continually throughout the period. While we have had +several students turn into long-term members, just as many disappear +after GSoC. And while many projects have been successful, we often have +difficulty integrating them into mainline git when the results are +dumped on the community at the end. + +This challenge led to us discussing in 2013 the scope of our projects, +how we select students, and how we encourage them to interact through +the summer. This discussion was still going last February. Rather than +try to rush through a GSoC application, we decided instead to take the +year off and consider these issues. This led to a panel at our Git-Merge +conference in May, and an on-list discussion in October. The partial +conclusions of which are: + + 1. Looking at the numbers, we actually do not do that badly. + + 2. We should probably be making the project scopes a bit smaller, and + spending more time getting students involved in day-to-day + activities like review and discussion on list, even when they + aren't necessarily part of their specific projects. + +Here is a summary of our completed/failed projects per year, along with +the number of retained contributors (where "retained" is calculated by +finding contributors which continued to participate on the mailing list +a year or more after their GSoC period ended): + + - 2007: 2 success, 1 failure, 1 student retained + - 2008: 4 success, 2 failure, 3 students retained + - 2009: 1 success, 1 failure, 0 students retained + - 2010: 3 success, 1 failure, 3 students retained + - 2011: 5 success, 0 failure, 4 students retained + - 2012: 3 success, 0 failure, 2 students retained + +## Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? + +*TODO* needs review for 2015 + +With the exception of 2013, Git has participated in GSoC every year +since 2007. We have appreciated not only the code contributions, 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. + +## How many potential mentors do you have for this year's program? What criteria did you use to select them? + +*TODO* needs review and certainly number updates for 2015 + +We have 7 mentors related to specific projects, and a number of people +in both the git-core and libgit2 projects who are available to help +assist or backup mentors. + +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. + +## What is your plan for dealing with disappearing students? + +*TODO* needs review for 2015 + +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. + +## What is your plan for dealing with disappearing mentors? + +*TODO* needs review for 2015 + +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" high 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, and during the program? + +*TODO* needs review for 2015 + +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. + +## What will you do to encourage your accepted students to 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. + +## 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 From 4de2cfc404fd2cd6db25a18bf5e2e17404ad068c Mon Sep 17 00:00:00 2001 From: Jeff King Date: Wed, 18 Feb 2015 11:40:44 -0500 Subject: [PATCH 0002/3116] soc-2015: mark TODOs as bold, not underline The point is to make them stand out. --- SoC-2015-Ideas.md | 2 +- SoC-2015-Microprojects.md | 2 +- SoC-2015-Org-Application.md | 12 ++++++------ 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md index 395cd89efa..b18d8857e0 100644 --- a/SoC-2015-Ideas.md +++ b/SoC-2015-Ideas.md @@ -22,4 +22,4 @@ process. generating proposals. We are also more than happy to receive proposals for other ideas related to Git or libgit2. -*TODO* add entries :) +**TODO** add entries :) diff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md index 07d09e9c1a..b79a89f22e 100644 --- a/SoC-2015-Microprojects.md +++ b/SoC-2015-Microprojects.md @@ -107,4 +107,4 @@ suitable. Just remember to keep the change small! It is much better for you to finish a small but complete change than to try something too ambitious and not get it done. -*TODO* add entries +**TODO** add entries diff --git a/SoC-2015-Org-Application.md b/SoC-2015-Org-Application.md index 4f21c927d5..8682203666 100644 --- a/SoC-2015-Org-Application.md +++ b/SoC-2015-Org-Application.md @@ -58,7 +58,7 @@ Yes (we participated before) ## 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. -*TODO* possibly needs updating for 2015. Surely could manage to be less wordy? +**TODO** possibly needs updating for 2015. Surely could manage to be less wordy? Git has participated in GSoC every year since 2007, with the exception of 2013, typically mentoring 2-5 students each year. Our mentors have @@ -126,7 +126,7 @@ a year or more after their GSoC period ended): ## Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? -*TODO* needs review for 2015 +**TODO** needs review for 2015 With the exception of 2013, Git has participated in GSoC every year since 2007. We have appreciated not only the code contributions, but @@ -137,7 +137,7 @@ remain involved with Git itself. ## How many potential mentors do you have for this year's program? What criteria did you use to select them? -*TODO* needs review and certainly number updates for 2015 +**TODO** needs review and certainly number updates for 2015 We have 7 mentors related to specific projects, and a number of people in both the git-core and libgit2 projects who are available to help @@ -155,7 +155,7 @@ expected of a student working on a Google Summer of Code project. ## What is your plan for dealing with disappearing students? -*TODO* needs review for 2015 +**TODO** needs review for 2015 We think that the most important part of GSoC is integrating the student into the normal communication channels used by other project @@ -173,7 +173,7 @@ failing evaluation, regardless of any code produced. ## What is your plan for dealing with disappearing mentors? -*TODO* needs review for 2015 +**TODO** needs review for 2015 Most of our projects have more than one mentor available. In the unlikely event that a mentor disappears during the summer, another @@ -184,7 +184,7 @@ 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, and during the program? -*TODO* needs review for 2015 +**TODO** needs review for 2015 Students will be required to join the main development mailiing list and post their patches for discussion. All current contributors already do From a160155a91c0a6fbf5655e5321eaa6783f492d0b Mon Sep 17 00:00:00 2001 From: Jeff King Date: Wed, 18 Feb 2015 11:43:35 -0500 Subject: [PATCH 0003/3116] navbar: reverse-sort pages This puts the 2015 pages first. We may want to just do this manually, though. --- _includes/navbar.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_includes/navbar.html b/_includes/navbar.html index 2e2d6cbf98..c457cbf8d5 100644 --- a/_includes/navbar.html +++ b/_includes/navbar.html @@ -2,7 +2,7 @@