{"thread":{"id":"35169","subject":"GSoC 2014: Summary so far, discussion starter: how to improve?","startedAt":"2013-10-19T06:09:33Z","lastAt":"2013-11-21T10:04:21Z","messageCount":11,"participants":["Thomas Rast","Christian Couder","Felipe Contreras","Fredrik Gustafsson","Thomas Gummerer","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"229205","messageId":"8761stx04i.fsf@linux-k42r.v.cablecom.net","threadId":"35169","inReplyTo":null,"subject":"GSoC 2014: Summary so far, discussion starter: how to improve?","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-10-19T06:09:33Z","receivedAt":"2013-10-19T06:09:33Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"[Unfortunately libgit2 no longer has a mailing list.  I put an arbitrary\ngroup of libgit2 contributors in the Cc list.]\n\n\nPrevious Episodes\n=================\n\nGit participated in Google Summer of Code (GSoC) 2007-2012, but did not\nparticipate in 2013 based on discussion in February [1].  At Git-Merge\nin Berlin there was a discussion round [2] that this post attempts to\nsummarize as a basis for further discussion and (hopefully)\nparticipation in GSoC'14.\n\nMuch sooner than in previous years, Google has already confirmed that\nGSoC'14 will in fact happen [3].\n\nNote that while mistakes herein are mine, many ideas and opinions\naren't.  This really tries to be a summary.  Please flame >/dev/null,\nnot me.\n\n\nGSoC 2007-2012\n==============\n\nData presented in [2] shows that roughly half of the projects resulted\nin merged code, and roughly half of the students remained with the Git\ncommunity significantly after the end of GSoC.  (The sets aren't\nexactly the same.)\n\nA feeling expressed in [1], [2] and elsewhere is that this is not\nenough value for money and effort.  We should therefore discuss how to\nimprove.\n\nNote that everyone seems to agree that libgit2 had a much better run\nin GSoC than core git.  There seems to be less agreement on what\nexactly they do differently, though.\n\n\nTheories\n========\n\nThese are the hypotheses that I have heard (mostly in [1] and [2]) as\nto what is bad about Git's prior GSoC participations.\n\n* Aiming far too high, focusing on cool/shiny projects with a large\n  impact.  This also affects the students, who tend to cluster around\n  the largest, shiniest project suggestions.\n\n* Diminishing returns: Git is too mature, with little low-hanging\n  fruit left, making such projects harder\n\n* Projects are too political, progress depending on non-technical\n  arguments\n\n* Our mentors suck on various axes, notably not supporting students\n  enough in things that matter:\n  - smooth interaction with community\n  - ensure fast iteration/short cycles\n  - navigating the code base\n\n* Scope creep: projects tend to get blocked on some bigger\n  refactoring/restructuring task that was not in the original proposal\n\n\nIdeas and Suggestions\n=====================\n\nThese are mostly from [2].  There were some suggestions that we learn\nfrom Matthieu Moy's very successful student projects (eg. [4]).\n\n* View GSoC much more as a lot of work than free labor\n\n* Break projects into smaller, easier tasks\n  - They should individually be simple, quick things if the mentor did\n    them.\n  - Should be parallelizable so students don't have to block on reviews.\n\n* Mentoring improvements:\n  - Always have a co-mentor\n  - Focus on social aspects (who to Cc, etc.)\n  - Nominate separate \"review mentors\" to ensure fast review cycles\n\n* Define explicit criteria\n  - what we want to do\n  - how we judge code and social interactions\n  - when to fail the students\n\n* Have students review some patches\n\n\nFurther steps\n=============\n\n* Discuss :-)\n\n  And then apply this hard-won knowledge systematically.  In\n  particular I think it wouldn't hurt to keep the project proposals\n  out of this thread until we have agreed on goals/standards to\n  measure them against.\n\n* Does libgit2 want to remain under the Git umbrella, or participate\n  on its own?\n\n* Figure out the wiki situation.  In previous years the project\n  proposals and other important information were hosted at k.org [5] and\n  github wikis [6].  Other options were floated, such as an official\n  wiki hosted by github.  (This is somewhat of a contentious issue that\n  spans beyond GSoC.)\n\n* Find an org admin and backup.  In previous years Shawn and Peff did\n  this.  Would you do it again?\n\n* Gather a list of potential mentors.\n\n\n\n[1]  http://thread.gmane.org/gmane.comp.version-control.git/216485\n[2]  http://www.youtube.com/watch?v=XP4CxUkBPSQ‎\n[3]  http://googleblog.blogspot.ch/2013/10/50-million-lines-of-code-and-counting.html\n[4]  http://thread.gmane.org/gmane.comp.version-control.git/221159\n[5]  https://git.wiki.kernel.org/index.php/SoC2011Projects\n     similarly for previous years\n[6]  https://github.com/peff/git/wiki/SoC-2012-Ideas\n     https://github.com/trast/git/wiki/SoC-2013-Ideas\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"229212","messageId":"CAP8UFD0KF_X8sbmUNNvRkHz+XFwAZ7aW+YfVyCnt0yJ_WfW2Bg@mail.gmail.com","threadId":"35169","inReplyTo":"8761stx04i.fsf@linux-k42r.v.cablecom.net","subject":"Re: GSoC 2014: Summary so far, discussion starter: how to improve?","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2013-10-19T10:41:03Z","receivedAt":"2013-10-19T10:41:03Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Sat, Oct 19, 2013 at 8:09 AM, Thomas Rast <tr@thomasrast.ch> wrote:\n>\n> Previous Episodes\n> =================\n>\n> Git participated in Google Summer of Code (GSoC) 2007-2012, but did not\n> participate in 2013 based on discussion in February [1].  At Git-Merge\n> in Berlin there was a discussion round [2] that this post attempts to\n> summarize as a basis for further discussion and (hopefully)\n> participation in GSoC'14.\n>\n> Much sooner than in previous years, Google has already confirmed that\n> GSoC'14 will in fact happen [3].\n>\n> Note that while mistakes herein are mine, many ideas and opinions\n> aren't.  This really tries to be a summary.  Please flame >/dev/null,\n> not me.\n\nThank you for sending this very good summary.\n\n> Theories\n> ========\n>\n> These are the hypotheses that I have heard (mostly in [1] and [2]) as\n> to what is bad about Git's prior GSoC participations.\n>\n> * Aiming far too high, focusing on cool/shiny projects with a large\n>   impact.  This also affects the students, who tend to cluster around\n>   the largest, shiniest project suggestions.\n\nYeah, focusing on _too big_ projects.\n\n> * Diminishing returns: Git is too mature, with little low-hanging\n>   fruit left, making such projects harder\n>\n> * Projects are too political, progress depending on non-technical\n>   arguments\n>\n> * Our mentors suck on various axes, notably not supporting students\n>   enough in things that matter:\n>   - smooth interaction with community\n>   - ensure fast iteration/short cycles\n>   - navigating the code base\n\nYeah, \"fast iteration/short cycles\" means submitting the work early\nand often _to the mailing list_.\n\nOne of the thing we learned too is that focusing on selecting the\n\"best\" students didn't really worked.\nWhat worked was selecting students who have already contributed\npatches, but unfortunately there are not many potential students who\nhave already contributed.\n\n> Further steps\n> =============\n>\n> * Discuss :-)\n>\n>   And then apply this hard-won knowledge systematically.  In\n>   particular I think it wouldn't hurt to keep the project proposals\n>   out of this thread until we have agreed on goals/standards to\n>   measure them against.\n\nBased on the above, what about the following:\n\n1) Advertise early and widely that we will very strongly favor\nstudents who have already contributed and that we can help them\ncontribute long before their application process starts. Maybe we\ncould even have a pre GSoC application process for potential students.\n\n2) Advertise that we will really favor small projects over big/shiny ones.\n\n3) Come up with a list of criteria like the following to measure\nstudent/application:\n\n- has the student already contributed much: 0-30 points:\n0 means no contribution to any open source project,\n5 means some contribution to another open source project,\n20 means long time Git contributor\n\n- what is the size of the project: 0-10 points:\n0 means big project (one month or more for a regular contributor)\n10 means small project (one week for a regular contributor)\n\n- does the student appear willing to act on advice: 0-5 points\n\n- does the student appear to have the necessary skills: 0-5 points\n\n- does the proposal look good: 0-5 points\n\n> * Gather a list of potential mentors.\n\nI would be happy to mentor next year.\n\nThanks,\nChristian.\n"},{"id":"229217","messageId":"5262746ce10dc_4e9f1021e84b7@nysa.notmuch","threadId":"35169","inReplyTo":"8761stx04i.fsf@linux-k42r.v.cablecom.net","subject":"RE: GSoC 2014: Summary so far, discussion starter: how to improve?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-19T12:00:44Z","receivedAt":"2013-10-19T12:00:44Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Thomas Rast wrote:\n> * Diminishing returns: Git is too mature, with little low-hanging\n>   fruit left, making such projects harder\n\nToo mature? Aren't there other projects that are \"too mature\" as well? In\nparticular I'm thinking about the Linux kernel.\n\nI think it's not about maturity, but how they deal with change.\n\n> * Does libgit2 want to remain under the Git umbrella, or participate\n>   on its own?\n\nPersonally I don't see what libgit2 has to do with git.git. There isn't even\ncommunication between the two projects.\n\n-- \nFelipe Contreras\n"},{"id":"229228","messageId":"20131019215139.GX13967@paksenarrion.iveqy.com","threadId":"35169","inReplyTo":"8761stx04i.fsf@linux-k42r.v.cablecom.net","subject":"Re: GSoC 2014: Summary so far, discussion starter: how to improve?","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2013-10-19T21:51:39Z","receivedAt":"2013-10-19T21:51:39Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"Hi,\nso I was a GSoC:er, I got some (most) of my code merged but didn't fully\nmet my (personal) goals for the project. However I do passed in the eyes\nof Google.\n\nGSoC is _hard_. You end up feeling completely stupid over and over\nagain. Git has hard standards. Beeing just a single programmer and/or\njust learnt programming in school, there's a lot of difference.\n\nI started with learning git (better), read documentation and looking\nat the codebase and still felt lost.\n\nAfter that I'd to learn communication skills, who to mail, when to mail,\nhow to write a commit message, been real strict with codestyle,\nsetting up a github account, configuring git in a \"git contributor\nfriendly way\", etc.\n\nOn Sat, Oct 19, 2013 at 08:09:33AM +0200, Thomas Rast wrote:\n> Theories\n> ========\n> \n> These are the hypotheses that I have heard (mostly in [1] and [2]) as\n> to what is bad about Git's prior GSoC participations.\n> \n> * Aiming far too high, focusing on cool/shiny projects with a large\n>   impact.  This also affects the students, who tend to cluster around\n>   the largest, shiniest project suggestions.\n> \n> * Diminishing returns: Git is too mature, with little low-hanging\n>   fruit left, making such projects harder\n> \n> * Projects are too political, progress depending on non-technical\n>   arguments\n> \n> * Our mentors suck on various axes, notably not supporting students\n>   enough in things that matter:\n>   - smooth interaction with community\n>   - ensure fast iteration/short cycles\n>   - navigating the code base\n> \n> * Scope creep: projects tend to get blocked on some bigger\n>   refactoring/restructuring task that was not in the original proposal\n> \n> \n> \n> * View GSoC much more as a lot of work than free labor\n\nTotally agree, GSoC is an investment for future labor, not labor.\n\n> \n> * Break projects into smaller, easier tasks\n>   - They should individually be simple, quick things if the mentor did\n>     them.\n>   - Should be parallelizable so students don't have to block on reviews.\n\nI'd 5-6 smaller projects setup for the summer, I think I managed to do\n2-3 of them. (I did however do everything I applied for). I really think\nit's an excellent idea. This also meant that while one patch waited for\nreview, I'd other things to work on.\n\n> \n> * Mentoring improvements:\n>   - Always have a co-mentor\n>   - Focus on social aspects (who to Cc, etc.)\n>   - Nominate separate \"review mentors\" to ensure fast review cycles\n\nI like the idea of review mentors. However bear in mind that you'll\nalready have three people reviewing the patches (two mentors and Junio).\nWe will not make it look like it's impossible to get things into\ngit.git.\n\n> * Have students review some patches\n\nThis would be excellent. That's a part that I thinks is very usefull and\nwould easy students remaining with git. It's easier to review patches\nthan to make them.\n\n\nAs a last part I would say that GSoC learned me a lot. I'm good at git,\nI know test driven development, I learned shell, I got to play with a\nhuge C-codebase for the first time and I learned open source projects,\nQA, etc.\n\nI would like to thank Jens and Heiko for good mentoring and a lot of\npatience!\n\n(as a sidenote, I did get extremly busy when the school started. I\ndidn't even had time to fix a serious bug in my code (Jens had to clean\nup after me). However two years later I'd some time again and got a few\npatches in and I hope to get a few patches into git in the future too).\n\nA successful GSoC for git isn't a merged project but continued\ncontribution to git (not necessairly in patches, but also in support and\nreview).\n\nA successful GSoC for Google/student is a merged project.\n\nA successful GSoC for student is a great learning experience.\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"229235","messageId":"87bo2kdzz2.fsf@gmail.com","threadId":"35169","inReplyTo":"8761stx04i.fsf@linux-k42r.v.cablecom.net","subject":"Re: GSoC 2014: Summary so far, discussion starter: how to improve?","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2013-10-20T10:00:01Z","receivedAt":"2013-10-20T10:00:01Z","isPatch":false,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"\nAs participant in GSoC 2012 I'll mostly respond to this from a student\npoint of view.\n\nGenerally I had a great learning experience with my project.  It was a\ngreat introduction into how the Git project and open source projects in\ngeneral work and certainly lowered the barrier to start contributing to\nGit.  I was and still am grateful for this experience.\n\nEven though my contributions after the GSoC were very small, I wouldn't\nhave contributed those patches if I hadn't participated in GSoC before.\nThat probably doesn't (yet) make up for the work invested in me, but I\ncertainly hope it will down the line.\n\nThomas Rast <tr@thomasrast.ch> writes:\n\n> [Unfortunately libgit2 no longer has a mailing list.  I put an arbitrary\n> group of libgit2 contributors in the Cc list.]\n>\n>\n> Previous Episodes\n> =================\n>\n> Git participated in Google Summer of Code (GSoC) 2007-2012, but did not\n> participate in 2013 based on discussion in February [1].  At Git-Merge\n> in Berlin there was a discussion round [2] that this post attempts to\n> summarize as a basis for further discussion and (hopefully)\n> participation in GSoC'14.\n>\n> Much sooner than in previous years, Google has already confirmed that\n> GSoC'14 will in fact happen [3].\n>\n> Note that while mistakes herein are mine, many ideas and opinions\n> aren't.  This really tries to be a summary.  Please flame >/dev/null,\n> not me.\n>\n>\n> GSoC 2007-2012\n> ==============\n>\n> Data presented in [2] shows that roughly half of the projects resulted\n> in merged code, and roughly half of the students remained with the Git\n> community significantly after the end of GSoC.  (The sets aren't\n> exactly the same.)\n>\n> A feeling expressed in [1], [2] and elsewhere is that this is not\n> enough value for money and effort.  We should therefore discuss how to\n> improve.\n>\n> Note that everyone seems to agree that libgit2 had a much better run\n> in GSoC than core git.  There seems to be less agreement on what\n> exactly they do differently, though.\n>\n> Theories\n> ========\n>\n> These are the hypotheses that I have heard (mostly in [1] and [2]) as\n> to what is bad about Git's prior GSoC participations.\n>\n> * Aiming far too high, focusing on cool/shiny projects with a large\n>   impact.  This also affects the students, who tend to cluster around\n>   the largest, shiniest project suggestions.\n\nThis was mostly why my project wasn't merged, imo.  More complicated\nprojects generally sound more interesting (to me at least), so I\ndirectly went for one of the more complicated ones.  There were a few\nwarnings that this might be too complicated along the application\nprocess, but without real previous knowledge of the code base I\noverestimated myself and underestimated the project and chose to ignore\nall of that.\n\nAs some of you may know I'm still working on the project, but my time is\nlimited so it will take a while for it to bring it to inclusion shape,\nif it every will be merged.\n\n> * Diminishing returns: Git is too mature, with little low-hanging\n>   fruit left, making such projects harder\n>\n> * Projects are too political, progress depending on non-technical\n>   arguments\n>\n> * Our mentors suck on various axes, notably not supporting students\n>   enough in things that matter:\n>   - smooth interaction with community\n\nEspecially at first I was reluctant to use the mailing list for\ndiscussions and used the #git-devel irc channel a lot for that.  While I\nfelt these conversations were very fruitful, it would probably have been\ngood to send at least a summary email to the list after those\nconversations.\n\n>   - ensure fast iteration/short cycles\n\nI think that was quite hard to do with my project, as it was impossible\nto split up.  I think this would not only help community interaction,\nbut would be great for the student too, getting the satisfaction from\ngetting patches merged early.\n\n>   - navigating the code base\n\nThis was the least of my problems, I got good pointers on where to start\nfrom Thomas and others on the irc channel, and help was always available\nto me, whenever I needed it.\n\n> * Scope creep: projects tend to get blocked on some bigger\n>   refactoring/restructuring task that was not in the original proposal\n>\n>\n> Ideas and Suggestions\n> =====================\n>\n> These are mostly from [2].  There were some suggestions that we learn\n> from Matthieu Moy's very successful student projects (eg. [4]).\n>\n> * View GSoC much more as a lot of work than free labor\n>\n> * Break projects into smaller, easier tasks\n>   - They should individually be simple, quick things if the mentor did\n>     them.\n>   - Should be parallelizable so students don't have to block on reviews.\n>\n> * Mentoring improvements:\n>   - Always have a co-mentor\n>   - Focus on social aspects (who to Cc, etc.)\n>   - Nominate separate \"review mentors\" to ensure fast review cycles\n>\n> * Define explicit criteria\n>   - what we want to do\n>   - how we judge code and social interactions\n>   - when to fail the students\n>\n> * Have students review some patches\n>\n>\n> Further steps\n> =============\n>\n> * Discuss :-)\n>\n>   And then apply this hard-won knowledge systematically.  In\n>   particular I think it wouldn't hurt to keep the project proposals\n>   out of this thread until we have agreed on goals/standards to\n>   measure them against.\n>\n> * Does libgit2 want to remain under the Git umbrella, or participate\n>   on its own?\n>\n> * Figure out the wiki situation.  In previous years the project\n>   proposals and other important information were hosted at k.org [5] and\n>   github wikis [6].  Other options were floated, such as an official\n>   wiki hosted by github.  (This is somewhat of a contentious issue that\n>   spans beyond GSoC.)\n>\n> * Find an org admin and backup.  In previous years Shawn and Peff did\n>   this.  Would you do it again?\n>\n> * Gather a list of potential mentors.\n>\n>\n>\n> [1]  http://thread.gmane.org/gmane.comp.version-control.git/216485\n> [2]  http://www.youtube.com/watch?v=XP4CxUkBPSQ‎\n> [3]  http://googleblog.blogspot.ch/2013/10/50-million-lines-of-code-and-counting.html\n> [4]  http://thread.gmane.org/gmane.comp.version-control.git/221159\n> [5]  https://git.wiki.kernel.org/index.php/SoC2011Projects\n>      similarly for previous years\n> [6]  https://github.com/peff/git/wiki/SoC-2012-Ideas\n>      https://github.com/trast/git/wiki/SoC-2013-Ideas\n>\n> --\n> Thomas Rast\n> tr@thomasrast.ch\n"},{"id":"229307","messageId":"xmqqli1lro08.fsf@gitster.dls.corp.google.com","threadId":"35169","inReplyTo":"8761stx04i.fsf@linux-k42r.v.cablecom.net","subject":"Re: GSoC 2014: Summary so far, discussion starter: how to improve?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-22T21:31:35Z","receivedAt":"2013-10-22T21:31:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <tr@thomasrast.ch> writes:\n\n> Theories\n> ========\n>\n> These are the hypotheses that I have heard (mostly in [1] and [2]) as\n> to what is bad about Git's prior GSoC participations.\n>\n> * Aiming far too high, focusing on cool/shiny projects with a large\n>   impact.  This also affects the students, who tend to cluster around\n>   the largest, shiniest project suggestions.\n>\n> * Diminishing returns: Git is too mature, with little low-hanging\n>   fruit left, making such projects harder\n\nThis needs to be qualified. There probably are little low-hanging\nfruit left that still are shiny and cool for a newcomer to tackle.\nThat does not mean there are little low-hanging fruits that would\nhelp our users; there still are a lot. Just that they are not as\nglamorous.\n\n> * Projects are too political, progress depending on non-technical\n>   arguments\n\nI do not recall any such.\n\n> * Scope creep: projects tend to get blocked on some bigger\n>   refactoring/restructuring task that was not in the original\n>   proposal.\n\nI think that is a sign that the original proposal did not look\nenough at the existing code, dreaming of a pie-in-the-sky shiny\nfeatures in a green-field setting. What needs to be done within the\nconstraint of the existing code (including a total rewrite, if\nnecessary, while keeping the project's codebase maintainable is part\nof the healthy develpment.\n\n> Ideas and Suggestions\n> =====================\n>\n> These are mostly from [2].  There were some suggestions that we learn\n> from Matthieu Moy's very successful student projects (eg. [4]).\n>\n> * View GSoC much more as a lot of work than free labor\n> ...\n> * Mentoring improvements:\n>   - Always have a co-mentor\n>   - Focus on social aspects (who to Cc, etc.)\n>   - Nominate separate \"review mentors\" to ensure fast review cycles\n\nGood.\n\n> * Have students review some patches\n\nI am not sure if this would help.\n\nReviewing the patches to find style violations and off-by-one errors\nis relatively easy as it can be done with knowledge on a narrow\nisolated part of the system. Reviewing the design to make sure that\nthe change fits the way how existing subsystems work, ranging from\nthe internal API implementation level to consistency a changed\nbehaviour is presented at the UI level, however, needs understanding\nof the far wider entire project than only the parts of the system\nthe proposed change updates. It will be even more true if the chosen\ntopic is a cool/shiny one.\n"},{"id":"229552","messageId":"87txg4qwiq.fsf@linux-k42r.v.cablecom.net","threadId":"35169","inReplyTo":"xmqqli1lro08.fsf@gitster.dls.corp.google.com","subject":"Re: GSoC 2014: Summary so far, discussion starter: how to improve?","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-10-26T08:14:21Z","receivedAt":"2013-10-26T08:14:21Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Thomas Rast <tr@thomasrast.ch> writes:\n>\n>> Theories\n>> ========\n>>\n>> * Scope creep: projects tend to get blocked on some bigger\n>>   refactoring/restructuring task that was not in the original\n>>   proposal.\n\n(Full disclosure: I actually proposed this theory.)\n\n> I think that is a sign that the original proposal did not look\n> enough at the existing code, dreaming of a pie-in-the-sky shiny\n> features in a green-field setting. What needs to be done within the\n> constraint of the existing code (including a total rewrite, if\n> necessary, while keeping the project's codebase maintainable is part\n> of the healthy develpment.\n\nHmm, yes, but it's also the only objection that I believe I have never\nheard, as opposed to ignored.\n\nI'm okay if we just file this under \"things to consider during project\nproposal review\".\n\n>> * Have students review some patches\n>\n> I am not sure if this would help.\n>\n> Reviewing the patches to find style violations and off-by-one errors\n> is relatively easy as it can be done with knowledge on a narrow\n> isolated part of the system. Reviewing the design to make sure that\n> the change fits the way how existing subsystems work, ranging from\n> the internal API implementation level to consistency a changed\n> behaviour is presented at the UI level, however, needs understanding\n> of the far wider entire project than only the parts of the system\n> the proposed change updates. It will be even more true if the chosen\n> topic is a cool/shiny one.\n\nI'd choose the middle path: review for code readability.  What do the\nfunctions do?  Are the functions and variables named after their roles?\nIs there anything that I cannot understand, and therefore warrants a\ncomment?\n\nThat is much more difficult than just reviewing for style, while it can\n(usually) be done without too much knowledge of the outside.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"229553","messageId":"87fvrophm7.fsf@linux-k42r.v.cablecom.net","threadId":"35169","inReplyTo":"20131019215139.GX13967@paksenarrion.iveqy.com","subject":"Re: GSoC 2014: Summary so far, discussion starter: how to improve?","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-10-26T08:21:36Z","receivedAt":"2013-10-26T08:21:36Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Fredrik Gustafsson <iveqy@iveqy.com> writes:\n>> \n>> * Break projects into smaller, easier tasks\n>>   - They should individually be simple, quick things if the mentor did\n>>     them.\n>>   - Should be parallelizable so students don't have to block on reviews.\n>\n> I'd 5-6 smaller projects setup for the summer, I think I managed to do\n> 2-3 of them. (I did however do everything I applied for). I really think\n> it's an excellent idea. This also meant that while one patch waited for\n> review, I'd other things to work on.\n\nLots of kudo points for Jens and Heiko :-)\n\n>> * Mentoring improvements:\n>>   - Always have a co-mentor\n>>   - Focus on social aspects (who to Cc, etc.)\n>>   - Nominate separate \"review mentors\" to ensure fast review cycles\n>\n> I like the idea of review mentors. However bear in mind that you'll\n> already have three people reviewing the patches (two mentors and Junio).\n> We will not make it look like it's impossible to get things into\n> git.git.\n\nI think the idea was not that you'd get *more* reviews, but that there\nwould be a group of volunteers doing reviews to ensure that they arrive\nfast.  Students should have feedback within 1-2 days of the series being\nposted.\n\nThe other advantages are that it provides a set of fresh eyes, and takes\nload off Junio.\n\nI'm not even sure how official we have to make this.  In Thomas\nGummerer's case, Michael stepped up with reviews when I couldn't.  So\nmaybe it'll again \"just work out\".  But I would like to take this role,\nand leave the \"social\" mentoring to others.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"230877","messageId":"87txf6jgmi.fsf@linux-k42r.v.cablecom.net","threadId":"35169","inReplyTo":"8761stx04i.fsf@linux-k42r.v.cablecom.net","subject":"Re: GSoC 2014: Summary so far, discussion starter: how to improve?","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-11-21T08:36:37Z","receivedAt":"2013-11-21T08:36:37Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Thomas Rast <tr@thomasrast.ch> writes:\n\n> * Does libgit2 want to remain under the Git umbrella, or participate\n>   on its own?\n>\n> * Figure out the wiki situation.  In previous years the project\n>   proposals and other important information were hosted at k.org [5] and\n>   github wikis [6].  Other options were floated, such as an official\n>   wiki hosted by github.  (This is somewhat of a contentious issue that\n>   spans beyond GSoC.)\n>\n> * Find an org admin and backup.  In previous years Shawn and Peff did\n>   this.  Would you do it again?\n\nAny opinions on these points?\n\nI would actually favor a move to a wiki of the style that Peff proposed,\nhosted by github and backed by git with either a very mild ACL or none\n(\"bots don't know git push\").  k.org wiki had a grand total of three\nedits in the last 30 days (plus some bot edits for user creation).\n\nAnd of course without an org admin we don't really need to go any\nfurther...\n\n\n\n> [5]  https://git.wiki.kernel.org/index.php/SoC2011Projects\n>      similarly for previous years\n> [6]  https://github.com/peff/git/wiki/SoC-2012-Ideas\n>      https://github.com/trast/git/wiki/SoC-2013-Ideas\n\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"230878","messageId":"CAP8UFD0n3gs0ynP8f_RgbpE4rugodcWQ_CtqvtbV0bnc9fzi9Q@mail.gmail.com","threadId":"35169","inReplyTo":"87txf6jgmi.fsf@linux-k42r.v.cablecom.net","subject":"Re: GSoC 2014: Summary so far, discussion starter: how to improve?","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2013-11-21T09:43:34Z","receivedAt":"2013-11-21T09:43:34Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Nov 21, 2013 at 9:36 AM, Thomas Rast <tr@thomasrast.ch> wrote:\n> Thomas Rast <tr@thomasrast.ch> writes:\n>>\n>> * Find an org admin and backup.  In previous years Shawn and Peff did\n>>   this.  Would you do it again?\n\nIf Shawn and Peff don't answer, it probably means that you should volunteer :-)\n\n> Any opinions on these points?\n>\n> I would actually favor a move to a wiki of the style that Peff proposed,\n> hosted by github and backed by git with either a very mild ACL or none\n> (\"bots don't know git push\").  k.org wiki had a grand total of three\n> edits in the last 30 days (plus some bot edits for user creation).\n\nIf we are provided a wiki of the style Peff proposed, then I am ok using it.\nBut until we have it, let's use the k.org wiki.\n\nThanks,\nChristian.\n"},{"id":"230879","messageId":"20131121100421.GA14066@sigill.intra.peff.net","threadId":"35169","inReplyTo":"87txf6jgmi.fsf@linux-k42r.v.cablecom.net","subject":"Re: GSoC 2014: Summary so far, discussion starter: how to improve?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-11-21T10:04:21Z","receivedAt":"2013-11-21T10:04:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 21, 2013 at 09:36:37AM +0100, Thomas Rast wrote:\n\n> Thomas Rast <tr@thomasrast.ch> writes:\n> \n> > * Does libgit2 want to remain under the Git umbrella, or participate\n> >   on its own?\n> >\n> > * Figure out the wiki situation.  In previous years the project\n> >   proposals and other important information were hosted at k.org [5] and\n> >   github wikis [6].  Other options were floated, such as an official\n> >   wiki hosted by github.  (This is somewhat of a contentious issue that\n> >   spans beyond GSoC.)\n> >\n> > * Find an org admin and backup.  In previous years Shawn and Peff did\n> >   this.  Would you do it again?\n> \n> Any opinions on these points?\n\nI'll answer them in reverse order. :)\n\nI'm happy to be org admin again (or happy to give up the mantle if\nsomebody else is interested).\n\nRegarding the wiki, my main complaints about the k.org wiki have been:\n\n  1. It was down last time we tried to use it for GSoC. :) This has\n     since been fixed.\n\n  2. I had the impression that spam was a problem and it needed a crew\n     of scourers to find and remove it. That's a thankless job that I\n     don't personally want to do. It looks like there is not much spam\n     these days (perhaps due to k.org's login restrictions?), and people\n     do remove it. So if there are sufficient volunteers, it may be a\n     non-issue.\n\n  3. You can't use git to edit it or view the history. These days we\n     have the git-remote-mediawiki helper. I haven't done any real work\n     with it, but I have played around and I think it may be sufficient.\n\n  4. Mediawiki syntax sucks compared to Markdown. :)\n\n     That's my personal feeling, but I recognize others may disagree. A\n     syntax change might be seen as a disadvantage of moving by some. I\n     can live with it (but I want to throw it out there in case\n     everybody feels the same way).\n\nThe disadvantages / complications of moving to a different wiki (e.g., a\nGitHub wiki) are:\n\n  1. It's non-zero work to set up, especially if we do not just use an\n     out-of-the-box solution. I'd be in favor of some kind of static\n     site generator, but then we have to pick one, style it, set up\n     auto-build-on-push, etc. GitHub Pages would do most of the dirty\n     work there, if we want to use it.\n\n  2. Some solutions involve using non-free software or services, which\n     some people may not like.\n\n  3. What happens to the old wiki? Other sites link there, and it has\n     content. Do we migrate the content? Do they both exist simultaneously?\n     Is one just for GSoC stuff (which seems unnecessarily confusing to\n     me)?\n\nFor libgit2, I think it makes sense to leave them under the Git umbrella\nand give them a slot or two as appropriate, as it saves administrative\neffort. But it is up to them if they want to split off into their own\nGSoC org. If that is the case, they will need an admin and to do a bunch\nof application paperwork. I believe we can give them a recommendation to\nhelp ease the process along.\n\n-Peff\n"}]}