GSoC 2014: Summary so far, discussion starter: how to improve?

GSoC 2014: Summary so far, discussion starter: how to improve?

[Thomas Rast]

[Unfortunately libgit2 no longer has a mailing list.  I put an arbitrary
group of libgit2 contributors in the Cc list.]


Previous Episodes
=================

Git participated in Google Summer of Code (GSoC) 2007-2012, but did not
participate in 2013 based on discussion in February [1].  At Git-Merge
in Berlin there was a discussion round [2] that this post attempts to
summarize as a basis for further discussion and (hopefully)
participation in GSoC'14.

Much sooner than in previous years, Google has already confirmed that
GSoC'14 will in fact happen [3].

Note that while mistakes herein are mine, many ideas and opinions
aren't.  This really tries to be a summary.  Please flame >/dev/null,
not me.


GSoC 2007-2012
==============

Data presented in [2] shows that roughly half of the projects resulted
in merged code, and roughly half of the students remained with the Git
community significantly after the end of GSoC.  (The sets aren't
exactly the same.)

A feeling expressed in [1], [2] and elsewhere is that this is not
enough value for money and effort.  We should therefore discuss how to
improve.

Note that everyone seems to agree that libgit2 had a much better run
in GSoC than core git.  There seems to be less agreement on what
exactly they do differently, though.


Theories
========

These are the hypotheses that I have heard (mostly in [1] and [2]) as
to what is bad about Git's prior GSoC participations.

* Aiming far too high, focusing on cool/shiny projects with a large
  impact.  This also affects the students, who tend to cluster around
  the largest, shiniest project suggestions.

* Diminishing returns: Git is too mature, with little low-hanging
  fruit left, making such projects harder

* Projects are too political, progress depending on non-technical
  arguments

* Our mentors suck on various axes, notably not supporting students
  enough in things that matter:
  - smooth interaction with community
  - ensure fast iteration/short cycles
  - navigating the code base

* Scope creep: projects tend to get blocked on some bigger
  refactoring/restructuring task that was not in the original proposal


Ideas and Suggestions
=====================

These are mostly from [2].  There were some suggestions that we learn
from Matthieu Moy's very successful student projects (eg. [4]).

* View GSoC much more as a lot of work than free labor

* Break projects into smaller, easier tasks
  - They should individually be simple, quick things if the mentor did
    them.
  - Should be parallelizable so students don't have to block on reviews.

* Mentoring improvements:
  - Always have a co-mentor
  - Focus on social aspects (who to Cc, etc.)
  - Nominate separate "review mentors" to ensure fast review cycles

* Define explicit criteria
  - what we want to do
  - how we judge code and social interactions
  - when to fail the students

* Have students review some patches


Further steps
=============

* Discuss :-)

  And then apply this hard-won knowledge systematically.  In
  particular I think it wouldn't hurt to keep the project proposals
  out of this thread until we have agreed on goals/standards to
  measure them against.

* Does libgit2 want to remain under the Git umbrella, or participate
  on its own?

* Figure out the wiki situation.  In previous years the project
  proposals and other important information were hosted at k.org [5] and
  github wikis [6].  Other options were floated, such as an official
  wiki hosted by github.  (This is somewhat of a contentious issue that
  spans beyond GSoC.)

* Find an org admin and backup.  In previous years Shawn and Peff did
  this.  Would you do it again?

* Gather a list of potential mentors.



[1]  http://thread.gmane.org/gmane.comp.version-control.git/216485
[2]  http://www.youtube.com/watch?v=XP4CxUkBPSQ‎
[3]  http://googleblog.blogspot.ch/2013/10/50-million-lines-of-code-and-counting.html
[4]  http://thread.gmane.org/gmane.comp.version-control.git/221159
[5]  https://git.wiki.kernel.org/index.php/SoC2011Projects
     similarly for previous years
[6]  https://github.com/peff/git/wiki/SoC-2012-Ideas
     https://github.com/trast/git/wiki/SoC-2013-Ideas

-- 
Thomas Rast
tr@thomasrast.ch

Re: GSoC 2014: Summary so far, discussion starter: how to improve?

[Christian Couder]

Hi,

On Sat, Oct 19, 2013 at 8:09 AM, Thomas Rast <tr@thomasrast.ch> wrote:
>
> Previous Episodes
> =================
>
> Git participated in Google Summer of Code (GSoC) 2007-2012, but did not
> participate in 2013 based on discussion in February [1].  At Git-Merge
> in Berlin there was a discussion round [2] that this post attempts to
> summarize as a basis for further discussion and (hopefully)
> participation in GSoC'14.
>
> Much sooner than in previous years, Google has already confirmed that
> GSoC'14 will in fact happen [3].
>
> Note that while mistakes herein are mine, many ideas and opinions
> aren't.  This really tries to be a summary.  Please flame >/dev/null,
> not me.

Thank you for sending this very good summary.

> Theories
> ========
>
> These are the hypotheses that I have heard (mostly in [1] and [2]) as
> to what is bad about Git's prior GSoC participations.
>
> * Aiming far too high, focusing on cool/shiny projects with a large
>   impact.  This also affects the students, who tend to cluster around
>   the largest, shiniest project suggestions.

Yeah, focusing on _too big_ projects.

> * Diminishing returns: Git is too mature, with little low-hanging
>   fruit left, making such projects harder
>
> * Projects are too political, progress depending on non-technical
>   arguments
>
> * Our mentors suck on various axes, notably not supporting students
>   enough in things that matter:
>   - smooth interaction with community
>   - ensure fast iteration/short cycles
>   - navigating the code base

Yeah, "fast iteration/short cycles" means submitting the work early
and often _to the mailing list_.

One of the thing we learned too is that focusing on selecting the
"best" students didn't really worked.
What worked was selecting students who have already contributed
patches, but unfortunately there are not many potential students who
have already contributed.

> Further steps
> =============
>
> * Discuss :-)
>
>   And then apply this hard-won knowledge systematically.  In
>   particular I think it wouldn't hurt to keep the project proposals
>   out of this thread until we have agreed on goals/standards to
>   measure them against.

Based on the above, what about the following:

1) Advertise early and widely that we will very strongly favor
students who have already contributed and that we can help them
contribute long before their application process starts. Maybe we
could even have a pre GSoC application process for potential students.

2) Advertise that we will really favor small projects over big/shiny ones.

3) Come up with a list of criteria like the following to measure
student/application:

- has the student already contributed much: 0-30 points:
0 means no contribution to any open source project,
5 means some contribution to another open source project,
20 means long time Git contributor

- what is the size of the project: 0-10 points:
0 means big project (one month or more for a regular contributor)
10 means small project (one week for a regular contributor)

- does the student appear willing to act on advice: 0-5 points

- does the student appear to have the necessary skills: 0-5 points

- does the proposal look good: 0-5 points

> * Gather a list of potential mentors.

I would be happy to mentor next year.

Thanks,
Christian.

RE: GSoC 2014: Summary so far, discussion starter: how to improve?

[Felipe Contreras]

Thomas Rast wrote:
> * Diminishing returns: Git is too mature, with little low-hanging
>   fruit left, making such projects harder

Too mature? Aren't there other projects that are "too mature" as well? In
particular I'm thinking about the Linux kernel.

I think it's not about maturity, but how they deal with change.

> * Does libgit2 want to remain under the Git umbrella, or participate
>   on its own?

Personally I don't see what libgit2 has to do with git.git. There isn't even
communication between the two projects.

-- 
Felipe Contreras

Re: GSoC 2014: Summary so far, discussion starter: how to improve?

[Fredrik Gustafsson]

Hi,
so I was a GSoC:er, I got some (most) of my code merged but didn't fully
met my (personal) goals for the project. However I do passed in the eyes
of Google.

GSoC is _hard_. You end up feeling completely stupid over and over
again. Git has hard standards. Beeing just a single programmer and/or
just learnt programming in school, there's a lot of difference.

I started with learning git (better), read documentation and looking
at the codebase and still felt lost.

After that I'd to learn communication skills, who to mail, when to mail,
how to write a commit message, been real strict with codestyle,
setting up a github account, configuring git in a "git contributor
friendly way", etc.

On Sat, Oct 19, 2013 at 08:09:33AM +0200, Thomas Rast wrote:
> Theories
> ========
> 
> These are the hypotheses that I have heard (mostly in [1] and [2]) as
> to what is bad about Git's prior GSoC participations.
> 
> * Aiming far too high, focusing on cool/shiny projects with a large
>   impact.  This also affects the students, who tend to cluster around
>   the largest, shiniest project suggestions.
> 
> * Diminishing returns: Git is too mature, with little low-hanging
>   fruit left, making such projects harder
> 
> * Projects are too political, progress depending on non-technical
>   arguments
> 
> * Our mentors suck on various axes, notably not supporting students
>   enough in things that matter:
>   - smooth interaction with community
>   - ensure fast iteration/short cycles
>   - navigating the code base
> 
> * Scope creep: projects tend to get blocked on some bigger
>   refactoring/restructuring task that was not in the original proposal
> 
> 
> 
> * View GSoC much more as a lot of work than free labor

Totally agree, GSoC is an investment for future labor, not labor.

> 
> * Break projects into smaller, easier tasks
>   - They should individually be simple, quick things if the mentor did
>     them.
>   - Should be parallelizable so students don't have to block on reviews.

I'd 5-6 smaller projects setup for the summer, I think I managed to do
2-3 of them. (I did however do everything I applied for). I really think
it's an excellent idea. This also meant that while one patch waited for
review, I'd other things to work on.

> 
> * Mentoring improvements:
>   - Always have a co-mentor
>   - Focus on social aspects (who to Cc, etc.)
>   - Nominate separate "review mentors" to ensure fast review cycles

I like the idea of review mentors. However bear in mind that you'll
already have three people reviewing the patches (two mentors and Junio).
We will not make it look like it's impossible to get things into
git.git.

> * Have students review some patches

This would be excellent. That's a part that I thinks is very usefull and
would easy students remaining with git. It's easier to review patches
than to make them.


As a last part I would say that GSoC learned me a lot. I'm good at git,
I know test driven development, I learned shell, I got to play with a
huge C-codebase for the first time and I learned open source projects,
QA, etc.

I would like to thank Jens and Heiko for good mentoring and a lot of
patience!

(as a sidenote, I did get extremly busy when the school started. I
didn't even had time to fix a serious bug in my code (Jens had to clean
up after me). However two years later I'd some time again and got a few
patches in and I hope to get a few patches into git in the future too).

A successful GSoC for git isn't a merged project but continued
contribution to git (not necessairly in patches, but also in support and
review).

A successful GSoC for Google/student is a merged project.

A successful GSoC for student is a great learning experience.
-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com

Re: GSoC 2014: Summary so far, discussion starter: how to improve?

[Thomas Rast]

Fredrik Gustafsson <iveqy@iveqy.com> writes:
>> 
>> * Break projects into smaller, easier tasks
>>   - They should individually be simple, quick things if the mentor did
>>     them.
>>   - Should be parallelizable so students don't have to block on reviews.
>
> I'd 5-6 smaller projects setup for the summer, I think I managed to do
> 2-3 of them. (I did however do everything I applied for). I really think
> it's an excellent idea. This also meant that while one patch waited for
> review, I'd other things to work on.

Lots of kudo points for Jens and Heiko :-)

>> * Mentoring improvements:
>>   - Always have a co-mentor
>>   - Focus on social aspects (who to Cc, etc.)
>>   - Nominate separate "review mentors" to ensure fast review cycles
>
> I like the idea of review mentors. However bear in mind that you'll
> already have three people reviewing the patches (two mentors and Junio).
> We will not make it look like it's impossible to get things into
> git.git.

I think the idea was not that you'd get *more* reviews, but that there
would be a group of volunteers doing reviews to ensure that they arrive
fast.  Students should have feedback within 1-2 days of the series being
posted.

The other advantages are that it provides a set of fresh eyes, and takes
load off Junio.

I'm not even sure how official we have to make this.  In Thomas
Gummerer's case, Michael stepped up with reviews when I couldn't.  So
maybe it'll again "just work out".  But I would like to take this role,
and leave the "social" mentoring to others.

-- 
Thomas Rast
tr@thomasrast.ch

Re: GSoC 2014: Summary so far, discussion starter: how to improve?

[Thomas Gummerer]

As participant in GSoC 2012 I'll mostly respond to this from a student
point of view.

Generally I had a great learning experience with my project.  It was a
great introduction into how the Git project and open source projects in
general work and certainly lowered the barrier to start contributing to
Git.  I was and still am grateful for this experience.

Even though my contributions after the GSoC were very small, I wouldn't
have contributed those patches if I hadn't participated in GSoC before.
That probably doesn't (yet) make up for the work invested in me, but I
certainly hope it will down the line.

Thomas Rast <tr@thomasrast.ch> writes:

> [Unfortunately libgit2 no longer has a mailing list.  I put an arbitrary
> group of libgit2 contributors in the Cc list.]
>
>
> Previous Episodes
> =================
>
> Git participated in Google Summer of Code (GSoC) 2007-2012, but did not
> participate in 2013 based on discussion in February [1].  At Git-Merge
> in Berlin there was a discussion round [2] that this post attempts to
> summarize as a basis for further discussion and (hopefully)
> participation in GSoC'14.
>
> Much sooner than in previous years, Google has already confirmed that
> GSoC'14 will in fact happen [3].
>
> Note that while mistakes herein are mine, many ideas and opinions
> aren't.  This really tries to be a summary.  Please flame >/dev/null,
> not me.
>
>
> GSoC 2007-2012
> ==============
>
> Data presented in [2] shows that roughly half of the projects resulted
> in merged code, and roughly half of the students remained with the Git
> community significantly after the end of GSoC.  (The sets aren't
> exactly the same.)
>
> A feeling expressed in [1], [2] and elsewhere is that this is not
> enough value for money and effort.  We should therefore discuss how to
> improve.
>
> Note that everyone seems to agree that libgit2 had a much better run
> in GSoC than core git.  There seems to be less agreement on what
> exactly they do differently, though.
>
> Theories
> ========
>
> These are the hypotheses that I have heard (mostly in [1] and [2]) as
> to what is bad about Git's prior GSoC participations.
>
> * Aiming far too high, focusing on cool/shiny projects with a large
>   impact.  This also affects the students, who tend to cluster around
>   the largest, shiniest project suggestions.

This was mostly why my project wasn't merged, imo.  More complicated
projects generally sound more interesting (to me at least), so I
directly went for one of the more complicated ones.  There were a few
warnings that this might be too complicated along the application
process, but without real previous knowledge of the code base I
overestimated myself and underestimated the project and chose to ignore
all of that.

As some of you may know I'm still working on the project, but my time is
limited so it will take a while for it to bring it to inclusion shape,
if it every will be merged.

> * Diminishing returns: Git is too mature, with little low-hanging
>   fruit left, making such projects harder
>
> * Projects are too political, progress depending on non-technical
>   arguments
>
> * Our mentors suck on various axes, notably not supporting students
>   enough in things that matter:
>   - smooth interaction with community

Especially at first I was reluctant to use the mailing list for
discussions and used the #git-devel irc channel a lot for that.  While I
felt these conversations were very fruitful, it would probably have been
good to send at least a summary email to the list after those
conversations.

>   - ensure fast iteration/short cycles

I think that was quite hard to do with my project, as it was impossible
to split up.  I think this would not only help community interaction,
but would be great for the student too, getting the satisfaction from
getting patches merged early.

>   - navigating the code base

This was the least of my problems, I got good pointers on where to start
from Thomas and others on the irc channel, and help was always available
to me, whenever I needed it.

> * Scope creep: projects tend to get blocked on some bigger
>   refactoring/restructuring task that was not in the original proposal
>
>
> Ideas and Suggestions
> =====================
>
> These are mostly from [2].  There were some suggestions that we learn
> from Matthieu Moy's very successful student projects (eg. [4]).
>
> * View GSoC much more as a lot of work than free labor
>
> * Break projects into smaller, easier tasks
>   - They should individually be simple, quick things if the mentor did
>     them.
>   - Should be parallelizable so students don't have to block on reviews.
>
> * Mentoring improvements:
>   - Always have a co-mentor
>   - Focus on social aspects (who to Cc, etc.)
>   - Nominate separate "review mentors" to ensure fast review cycles
>
> * Define explicit criteria
>   - what we want to do
>   - how we judge code and social interactions
>   - when to fail the students
>
> * Have students review some patches
>
>
> Further steps
> =============
>
> * Discuss :-)
>
>   And then apply this hard-won knowledge systematically.  In
>   particular I think it wouldn't hurt to keep the project proposals
>   out of this thread until we have agreed on goals/standards to
>   measure them against.
>
> * Does libgit2 want to remain under the Git umbrella, or participate
>   on its own?
>
> * Figure out the wiki situation.  In previous years the project
>   proposals and other important information were hosted at k.org [5] and
>   github wikis [6].  Other options were floated, such as an official
>   wiki hosted by github.  (This is somewhat of a contentious issue that
>   spans beyond GSoC.)
>
> * Find an org admin and backup.  In previous years Shawn and Peff did
>   this.  Would you do it again?
>
> * Gather a list of potential mentors.
>
>
>
> [1]  http://thread.gmane.org/gmane.comp.version-control.git/216485
> [2]  http://www.youtube.com/watch?v=XP4CxUkBPSQ‎
> [3]  http://googleblog.blogspot.ch/2013/10/50-million-lines-of-code-and-counting.html
> [4]  http://thread.gmane.org/gmane.comp.version-control.git/221159
> [5]  https://git.wiki.kernel.org/index.php/SoC2011Projects
>      similarly for previous years
> [6]  https://github.com/peff/git/wiki/SoC-2012-Ideas
>      https://github.com/trast/git/wiki/SoC-2013-Ideas
>
> --
> Thomas Rast
> tr@thomasrast.ch

Re: GSoC 2014: Summary so far, discussion starter: how to improve?

[Junio C Hamano]

Thomas Rast <tr@thomasrast.ch> writes:

> Theories
> ========
>
> These are the hypotheses that I have heard (mostly in [1] and [2]) as
> to what is bad about Git's prior GSoC participations.
>
> * Aiming far too high, focusing on cool/shiny projects with a large
>   impact.  This also affects the students, who tend to cluster around
>   the largest, shiniest project suggestions.
>
> * Diminishing returns: Git is too mature, with little low-hanging
>   fruit left, making such projects harder

This needs to be qualified. There probably are little low-hanging
fruit left that still are shiny and cool for a newcomer to tackle.
That does not mean there are little low-hanging fruits that would
help our users; there still are a lot. Just that they are not as
glamorous.

> * Projects are too political, progress depending on non-technical
>   arguments

I do not recall any such.

> * Scope creep: projects tend to get blocked on some bigger
>   refactoring/restructuring task that was not in the original
>   proposal.

I think that is a sign that the original proposal did not look
enough at the existing code, dreaming of a pie-in-the-sky shiny
features in a green-field setting. What needs to be done within the
constraint of the existing code (including a total rewrite, if
necessary, while keeping the project's codebase maintainable is part
of the healthy develpment.

> Ideas and Suggestions
> =====================
>
> These are mostly from [2].  There were some suggestions that we learn
> from Matthieu Moy's very successful student projects (eg. [4]).
>
> * View GSoC much more as a lot of work than free labor
> ...
> * Mentoring improvements:
>   - Always have a co-mentor
>   - Focus on social aspects (who to Cc, etc.)
>   - Nominate separate "review mentors" to ensure fast review cycles

Good.

> * Have students review some patches

I am not sure if this would help.

Reviewing the patches to find style violations and off-by-one errors
is relatively easy as it can be done with knowledge on a narrow
isolated part of the system. Reviewing the design to make sure that
the change fits the way how existing subsystems work, ranging from
the internal API implementation level to consistency a changed
behaviour is presented at the UI level, however, needs understanding
of the far wider entire project than only the parts of the system
the proposed change updates. It will be even more true if the chosen
topic is a cool/shiny one.

Re: GSoC 2014: Summary so far, discussion starter: how to improve?

[Thomas Rast]

Junio C Hamano <gitster@pobox.com> writes:

> Thomas Rast <tr@thomasrast.ch> writes:
>
>> Theories
>> ========
>>
>> * Scope creep: projects tend to get blocked on some bigger
>>   refactoring/restructuring task that was not in the original
>>   proposal.

(Full disclosure: I actually proposed this theory.)

> I think that is a sign that the original proposal did not look
> enough at the existing code, dreaming of a pie-in-the-sky shiny
> features in a green-field setting. What needs to be done within the
> constraint of the existing code (including a total rewrite, if
> necessary, while keeping the project's codebase maintainable is part
> of the healthy develpment.

Hmm, yes, but it's also the only objection that I believe I have never
heard, as opposed to ignored.

I'm okay if we just file this under "things to consider during project
proposal review".

>> * Have students review some patches
>
> I am not sure if this would help.
>
> Reviewing the patches to find style violations and off-by-one errors
> is relatively easy as it can be done with knowledge on a narrow
> isolated part of the system. Reviewing the design to make sure that
> the change fits the way how existing subsystems work, ranging from
> the internal API implementation level to consistency a changed
> behaviour is presented at the UI level, however, needs understanding
> of the far wider entire project than only the parts of the system
> the proposed change updates. It will be even more true if the chosen
> topic is a cool/shiny one.

I'd choose the middle path: review for code readability.  What do the
functions do?  Are the functions and variables named after their roles?
Is there anything that I cannot understand, and therefore warrants a
comment?

That is much more difficult than just reviewing for style, while it can
(usually) be done without too much knowledge of the outside.

-- 
Thomas Rast
tr@thomasrast.ch

Re: GSoC 2014: Summary so far, discussion starter: how to improve?

[Thomas Rast]

Thomas Rast <tr@thomasrast.ch> writes:

> * Does libgit2 want to remain under the Git umbrella, or participate
>   on its own?
>
> * Figure out the wiki situation.  In previous years the project
>   proposals and other important information were hosted at k.org [5] and
>   github wikis [6].  Other options were floated, such as an official
>   wiki hosted by github.  (This is somewhat of a contentious issue that
>   spans beyond GSoC.)
>
> * Find an org admin and backup.  In previous years Shawn and Peff did
>   this.  Would you do it again?

Any opinions on these points?

I would actually favor a move to a wiki of the style that Peff proposed,
hosted by github and backed by git with either a very mild ACL or none
("bots don't know git push").  k.org wiki had a grand total of three
edits in the last 30 days (plus some bot edits for user creation).

And of course without an org admin we don't really need to go any
further...



> [5]  https://git.wiki.kernel.org/index.php/SoC2011Projects
>      similarly for previous years
> [6]  https://github.com/peff/git/wiki/SoC-2012-Ideas
>      https://github.com/trast/git/wiki/SoC-2013-Ideas


-- 
Thomas Rast
tr@thomasrast.ch

Re: GSoC 2014: Summary so far, discussion starter: how to improve?

[Christian Couder]

On Thu, Nov 21, 2013 at 9:36 AM, Thomas Rast <tr@thomasrast.ch> wrote:
> Thomas Rast <tr@thomasrast.ch> writes:
>>
>> * Find an org admin and backup.  In previous years Shawn and Peff did
>>   this.  Would you do it again?

If Shawn and Peff don't answer, it probably means that you should volunteer :-)

> Any opinions on these points?
>
> I would actually favor a move to a wiki of the style that Peff proposed,
> hosted by github and backed by git with either a very mild ACL or none
> ("bots don't know git push").  k.org wiki had a grand total of three
> edits in the last 30 days (plus some bot edits for user creation).

If we are provided a wiki of the style Peff proposed, then I am ok using it.
But until we have it, let's use the k.org wiki.

Thanks,
Christian.

Re: GSoC 2014: Summary so far, discussion starter: how to improve?

[Jeff King]

On Thu, Nov 21, 2013 at 09:36:37AM +0100, Thomas Rast wrote:

> Thomas Rast <tr@thomasrast.ch> writes:
> 
> > * Does libgit2 want to remain under the Git umbrella, or participate
> >   on its own?
> >
> > * Figure out the wiki situation.  In previous years the project
> >   proposals and other important information were hosted at k.org [5] and
> >   github wikis [6].  Other options were floated, such as an official
> >   wiki hosted by github.  (This is somewhat of a contentious issue that
> >   spans beyond GSoC.)
> >
> > * Find an org admin and backup.  In previous years Shawn and Peff did
> >   this.  Would you do it again?
> 
> Any opinions on these points?

I'll answer them in reverse order. :)

I'm happy to be org admin again (or happy to give up the mantle if
somebody else is interested).

Regarding the wiki, my main complaints about the k.org wiki have been:

  1. It was down last time we tried to use it for GSoC. :) This has
     since been fixed.

  2. I had the impression that spam was a problem and it needed a crew
     of scourers to find and remove it. That's a thankless job that I
     don't personally want to do. It looks like there is not much spam
     these days (perhaps due to k.org's login restrictions?), and people
     do remove it. So if there are sufficient volunteers, it may be a
     non-issue.

  3. You can't use git to edit it or view the history. These days we
     have the git-remote-mediawiki helper. I haven't done any real work
     with it, but I have played around and I think it may be sufficient.

  4. Mediawiki syntax sucks compared to Markdown. :)

     That's my personal feeling, but I recognize others may disagree. A
     syntax change might be seen as a disadvantage of moving by some. I
     can live with it (but I want to throw it out there in case
     everybody feels the same way).

The disadvantages / complications of moving to a different wiki (e.g., a
GitHub wiki) are:

  1. It's non-zero work to set up, especially if we do not just use an
     out-of-the-box solution. I'd be in favor of some kind of static
     site generator, but then we have to pick one, style it, set up
     auto-build-on-push, etc. GitHub Pages would do most of the dirty
     work there, if we want to use it.

  2. Some solutions involve using non-free software or services, which
     some people may not like.

  3. What happens to the old wiki? Other sites link there, and it has
     content. Do we migrate the content? Do they both exist simultaneously?
     Is one just for GSoC stuff (which seems unnecessarily confusing to
     me)?

For libgit2, I think it makes sense to leave them under the Git umbrella
and give them a slot or two as appropriate, as it saves administrative
effort. But it is up to them if they want to split off into their own
GSoC org. If that is the case, they will need an admin and to do a bunch
of application paperwork. I believe we can give them a recommendation to
help ease the process along.

-Peff