Re: GSOC idea: build in scripts and cleanups

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> On Mon, Apr 04, 2011 at 11:09:00AM -0700, Junio C Hamano wrote:
>
>> I am afraid to say that the above schedule is too ambitious and does not
>> leave any time for reviews and re-rolls.  Please keep in mind that
>> historically patch series by more experienced contributors of substantial
>> size (comparable or even smaller scale than the topic you are proposing)
>> all typically took three or four review-reroll cycles, if not less, and we
>> don't automatically get extra review bandwidth just because GSoC is going
>> on.
>
> I agree. I think it's important to take review-reroll cycles into
> account. Not just in terms of allocating time, but also considering the
> latency, and keeping the student's pipeline full of work while waiting
> on review.

During the course of GSoC program, one will learn that other community
members do not have any obligation to keep one's pipeline full [*1*], and
learn how to cope with it.  Measuring the availability of others so that
one can make optimum use of others' time is a skill to be learned to be
successful in interacting with the open source community.

It takes people skills, not just "hacking" [*2*].

>   Week 3: build new functionality Y on top of X
>
> Obviously "Y" is going to depend somewhat on the refactoring of "X". But
> you can say in the RFC/PATCH for Y that X is still ongoing, and to
> review with that in mind. And that keeps the student doing something
> during week 3 while reviews for X flow in.

Yes.

> In the past, students haven't been very engaged with the list community,
> and I think that has hurt us. The code gets dumped as a whole at the
> end, and review is a lot harder, and GSoC is over, so the student ends
> up busy with going back to school.

While GSoC's "success" criteria (from stipend payment point of view) may
be to finish the defined task for the project, the program's larger
objective is to give an opportunity to students to learn how to work with
the open source community, so in that sense, I'd call that a total
failure.

I agree that we should help fixing that.

[Footnote]

*1* The mentor is special, has that obligation, and fulfils the obligation
by exercising his open source community skills and guiding the student to
break down the project into smaller subtasks to match the bandwidth of the
community.

*2* That incidentally is what I learned from working with Linus during the
early 2 months of git's life.  "People skill" is not just "being nice,
polite and diplomatic", none of which describes Linus ;-).

I think the most important skills include

 * being observant and know what others are doing, how busy they are, what
   patches are in flight that may have potential interactions with your
   work, and at what velocity these patches are progressing; and

 * clearly communicate what you are doing, in what order, for what reason,
   and where the boundaries of your goals are, and demonstrate that you
   are dedicated to the cause of the project.

The former would help you avoid duplicated work (if somebody is doing what
you can take advantage of and it is going at a reasonable pace, you can
spend your time on areas that do not depend on his work in the meantime
and wait) and unnecessary conflicts. The latter would make it more likely
that others would want to help you by correcting flaws in your design
assumptions and filling the gap that you are planning to punt, and help
these others to avoid duplicated work and unnecessary conflicts while
helping you.