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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
