[tahoe-dev] working in public Re: Google Summer of Code chooses to sponsor Tahoe-LAFS!

[Zooko O'Whielacronx]

Folks:

Hacking on Tahoe-LAFS, like most open source projects, is an exercise
in "working in public".

Matt Mackall, the original inventor of Mercurial and the current
organizer of Mercurial's Google Summer of Code, pointed me to this
letter that he just wrote to the students who are applying to work on
Mercurial for GSoC this summer:

http://www.selenic.com/pipermail/mercurial/2010-April/030996.html

I couldn't have put it better myself. And so I'm copying it below and
truncating the part that the end that is about a specific Mercurial
project.

Regards,

Zooko

From: Matt Mackall mpm at selenic.com
To: Mercurial mailing list
Subject: GSoC folks, read this

On Sat, 2010-04-03 at 10:53 -0400, Paul Malmsten wrote:
> Hi Matt,

[forwarded back to the list]

> I am considering applying to the Mercurial project for Google's Summer
> of Code program, and I'm looking for more information about the posted
> projects to determine which would be a good fit for me. To this end, I
> have a few questions about the lightweight copies/renames project, and
> I learned from the mailing list that you would be the person to ask.
>       * Which skills do you think should be brought to the project in
>         order to make considerable progress?

The real challenge of GSoC is not coding, it's learning to work with a
community. And the first lesson is: communicate in public. I'm sorry
that I didn't see your first message, but I rarely answer private
correspondence about Mercurial. If I did, I'd spend my entire life
repeating myself and never get any work done.

The next big challenge is: work in public (you might begin to see a
theme here). Lots of programmers have a tendency to go off in a corner
and code until they think they've found what they think is the complete
solution. That's one of the best ways to fail at GSoC, because odds are
good you'll have overlooked some important issue and we'll send you back
to the drawing board. Alternately, you'll go off in the wrong direction
and never be able to finish. Instead, divide your project into small,
manageable parts and get feedback on each of them along the way.

And finally: be part of the community. The tendency for GSoC students
has been to work on their own projects and talk to no one but their
mentor. That's completely missing the interesting parts of the open
source experience.

So this year, I'm hoping that students will actually engage with all
facets of the community. That means following both lists, reading
patches from other contributors, hanging out on IRC, responding to stuff
on the BTS, and engaging in things other than just your project,
including helping users. Plan on spending as much as half your time
doing these things.

Students who learn how to do this will learn a lot more valuable skills
and will be more successful than those who go off in a corner to code.
To help encourage this, this year we're going to pair students with
mentors who aren't experts in the project area so students don't have
any shortcuts around the community to getting help or getting their code
reviewed.