Re: [recommenders-dev] Committer vote for Kristijan has been vetoed by t

[Wayne Beaton <wayne@xxxxxxxxxxx>]

You misunderstand.

I do not mean to suggest that students should not be committers. In
fact, I am very much in favour of having students as committers. We have
numerous student success stories.

A central tenant of the Eclipse Development Process is that committer
access is granted based on demonstrated merit. An individual must prove
that they are ready to take on the responsibility that is inherent in
being a committer at Eclipse. Do we know that this student understands
our IP Policy? Can we be confident, for example, that they're not going
to inadvertently commit some "interesting code" of questionable pedigree
that they find on the web? The answers are, hopefully, "yes". But by
having some track record of contribution, we can be sure. This will be
very important as the project reaches maturity.

It's just not generally enough to make somebody a committer because of
some wonderful stuff that they're going to do. The process I outlined is
something that I need to see for any new committer, regardless of
whether or not they are a student. Frankly, it shouldn't add any
significant burden to get the student to take the code that will likely
be in their first commit anyway and contribute that through Bugzilla.
This will give them (and you) the opportunity to gain experience with
our processes and understanding of the requirements that come with being
a committer. Then they can be nominated.

BTW: makes sure that the student is aware of the Google Summer of Code
programme.

HTH,

Wayne

On 03/21/2011 08:45 PM, Marcel Bruch wrote:
> Hi Wayne,
>
> ---
> I added Chris and Ralph to this topic. Chris as mentor; Ralph because of the Foundation's interest to get universities involved and this discussion may be of interest to him too.
> ---
>
>
> I'm sorry that our current approach led to a veto.
>
> I understand that giving students committer state for incubator projects can be discussed controversially. For that reason I asked Chris and Ralph several months ago how to deal with student contributions created during a hands-on, bachelor-, or master thesis. Giving them committer status was one proposed approach.
>
>
> Let me briefly describe my motivation for doing so:
>
> In the past 2 years, round about 50 students contributed to various code recommenders sub-projects - some of them up to 4 times. Some of the projects fail, some created excellent results.
> I clearly understand that giving students committer access to this research project may seem odd at first if you compare it with rock-solid industry-driven projects like JDT, Platform and others. But I'm not sure whether the same guidelines should be applied for university-driven projects compared to industry-driven ones.
>
> Just a few sentences on the benefit of having students as committers:
> This semester eight students work on the project; four of them have committer access, two of them already agreed on a follow up project and thus continue contributing to the project (but as part of subsequent hands-on and master thesis respectively). I am sure that committer status has some positive effect on their motivation since they immediately see the fruits of their work in action and the quality of their work.
>
> Regarding this point (fruits in action): Today I presented code recommenders to the JDT guys in Zurich and they expressed their interest to integrate our jdt-based chain completion engine into the JDT as soon as we are ready. We are quite happy with that - and it's a student's work created during his first hands-on. They also offered to extend JDT where necessary (see, for instance, https://bugs.eclipse.org/bugs/show_bug.cgi?id=100267) to support Code Recommenders' integration into Eclipse best possible.
>
> Regarding Kristijan in particular: I didn't state that in my nomination because I wasn't aware of the need. This work will be the second topic he takes for the code recommenders project. Last semester he worked on a prototype of the extended javadoc platform where he showed deep interest in the project and contributed to code recommenders the first time. 
>
>
>
>
> Anyway, I'm not pushing against the PMC guidelines. But I would like to ask you to discuss the committer guidelines for this project with the PMC/Foundation. Code Recommenders is a quite development- and research-intensive piece of software with a non-commercial background and limited resources, which heavily relies on students to produce new and innovative tools for Eclipse. Students are a great source of innovation and becoming Committer for this project is a big honor and motivation for them too. In addition, all work committed to Eclipse ensures IP cleanliness, eliminates later IP issues, and frees us from maintaining our own build servers, repositories, legal stuff etc.
>
>
> But if you finally decide that students doing a hands-on, or thesis, or GSOC (is there a difference?) are not eligible as committers, than we have to change our process accordingly. 
>
> Thanks for consideration,
> Marcel
>
>
>
>
> On 21.03.2011, at 18:27, Wayne Beaton wrote:
>
>> technology.recommenders Committers,
>> This automatically generated message marks the PMC's veto of the vote for
>> Kristijan's full Committer status on the technology.recommenders project.
>>
>> The PMC's comments were: Committer elections should provide some
>> demonstration of merit. This generally takes the form of a list of bugs
>> that the individual has contributed. Regretfully, I am going to veto this
>> election. Kristijan should be encouraged to contribute an early (working)
>> version of his code via Bugzilla, and work with an existing committer to
>> move that contribution in the the project's VCS. After Kristijan has
>> demonstrated an understanding our our processes, rerun this election.
>>
>> If you have any questions, please do not hesitate to contact your project
>> lead, PMC member, or the EMO <emo@xxxxxxxxxxx>
>>
>> _______________________________________________
>> recommenders-dev mailing list
>> recommenders-dev@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/recommenders-dev