www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Menard <kmen...@servprise.com>
Subject Re: [Fwd: Google Summer of Code Summit]
Date Thu, 12 Oct 2006 17:35:16 GMT
For this and other emails in the thread, I'm going to switch hats from 
my role of solicitor to one of fellow mentor.  This is mostly to 
stimulate more conversation.  I will do my best to represent all 
viewpoints fairly in the end, however.

Andrus Adamchik wrote:
>> Sorry if this went through before, since there were issues with my 
>> list subscription.
> AFAIK it didn't - this is the first copy that I received.

Well, then that certainly sucks.  Thanks for letting me know.

> I disagree. You are right about the goals, but you are wrong about the 
> focus. Two reasons:
> 1. *Abstract* altruistic motives (on the mentors part) don't work. It 
> has to a be a *specific* altruistic (or not) motive for anyone to 
> participate in that.
> 2. From my own student years and a few internship-type projects that 
> I've done back then (more than a few years ago to be sure) - the most 
> discouraging part is a hypocrisy of being told that you are working on 
> a "real thing", only to realize later that you were doing something 
> that nobody ever intended to use. This is the most certain way to kill 
> enthusiasm.

Heh.  My own experience is that it can be really discouraging to just do 
all the crap work no one else wanted to do.  Although, if SoC is to be 
like an internship, maybe it's not too far off the mark.

>> o How can the ASF improve the student experience?
> Make sure the patches are reviewed and committed promptly.

In my own experience, this turned out to be much easier said than done.  
The easiest patches to review are the small ones.  Since many students 
essentially start from scratch, they're patches aren't exactly small 
ones to begin with.  Sure, they could provide patches that do nothing, 
but no one wants incomplete patches either.  Based on mentor feedback, 
the codebase may change considerably, and then the next submission is a 
patch against an old patch that's so radically different, it may as well 
have been a new submission to begin with.  More on this below.

>> o How should the ASF use student projects?
> Depends on the project. Ideally it should be clear at the proposal 
> stage where the code would fit in.

Agreed, but all too often things change.

> So while it is unreasonable to expect most of the students to stick 
> around past the end of the program, my personal feeling is that we 
> should only accept the proposals that we know how we can use, and 
> actually ask the students to put "integration of the code in the 
> product core" item on the proposal (see my comments above on the 
> reasons why). Or was it already on a proposal? :-)

Heh.  Once that secret's out, everyone will be using it in their 
proposals ;-)

>> o Should students be given more development resources than non- 
>> committers?
> -1

This goes a bit in hand with the previous discourse on patches.  This 
could quickly degrade into a procedural firefight, but it does sorta irk 
me that we expect people to give us code, but don't give them adequate 
tools to do it.  If I ever applied for a job somewhere and they told me 
the only tools I had for submitting code were diff and JIRA, I'd hazard 
to say I wouldn't be at that job very long.  There's something of a 
culture of earning the right to commit, and for the main codebase I'd 
say it's warranted.  For a throw away branch, however, it seems to me 
like an unnecessary hurdle that we put in the way of students completing 
their work.

> I am glad we followed the advice from 2005 SoC mentors and didn't go 
> that way. Still we diverted a bit by setting up the sandbox SVN 
> outside Apache. The result was that 1 project never communicated 
> anything to the community (I still have no idea what it does and how 
> far it went in its development, as it was all done between the mentor 
> and the student).

In my own experience, it's easier to stay on top of commit emails with 
diffs than it is JIRA issues with attached patches *shrug*

Kevin Menard
Servprise International, Inc.
"Remote reboot without pulling the plug" -- http://www.servprise.com 

To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

View raw message