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

[Wayne Beaton <wayne@xxxxxxxxxxx>]

Here's a scenario:

A student is working on some new functionality for your project. They
work for two weeks and produce some functioning subset of that new
functionality. They contribute that functionality to the project as an
attachment to a Bugzilla record.

One of your existing committers reviews the attachment. In that review,
they'd look for things like proper headers on the source files, obvious
violations of our IP Policy (like inclusion of GPL code, for example),
and general correctness. Your committer may decide to push back and ask
the student for some minor changes before accepting the contribution.

Once the committer is content with the attachment, they take it through
the IP Process [1]. You would most likely start from Figure #3 (Written
100% by submitting contributor). This will likely require a CQ. Assuming
that the student hasn't inadvertently copied code from somewhere, the IP
due diligence process should move forward quickly (i.e. within a few days).

Once approved by the IP team, the contribution can be committed. Once
committed, the student can reasonably be nominated to the project to be
a committer.

FWIW, this is exactly the process we followed with the IDE4EDU project
over several terms. Actually, that's not entirely true as I don't think
that we ever nominated any students after a single contribution. As a
PMC representative, I leave it to you to determine what actual level of
contribution you require before nominating the committer.

We do not make exceptions to our process for students. This is a good
thing for the project as it gives you some assurances that the student
has an appreciation for the IP Policy; discovering IP problems later in
the life of the project will be very costly/catastrophic (what is the
cost of an early IP violation if you are wildly successful and your
project is adopted into major distributions?). It's also good for the
student. It may seem like a PITA, but the "open source" experience is
more than just writing code. Understanding and participating in the
process is important. IP is important. Community development is important.

HTH,

Wayne

[1] http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf

On 03/23/2011 04:24 AM, Marcel Bruch wrote:
> On 22.03.2011, at 23:59, Wayne Beaton wrote:
>
>> On 03/22/2011 03:06 AM, Marcel Bruch wrote:
>>> OK. Are there any particular expectations on your side regarding size and quality of this contribution? 
>>>
>> It's subjective. Sorry. It could be a handful of relatively small
>> patches, or a single relatively large contribution of new functionality.
>> Ultimately, we're looking for understanding of our processes.
>>
> Wayne, I'm sorry. I have to ask few more questions to understand your expectations.
>
> "a handful relatively small patches" is pretty clear. This requires a fundamental understanding of the process and the software before becoming a committer. Students that make a hands-on typically do not start with patching small issues and bugs but work on new features. Also, in most cases they are new to the project and learn about the project and Eclipse during their hands-on. Thus, I tend to think that I ever nominate a student doing a hands-on, GSOC, or thesis based on this criterion.  
>
> I'm not sure whether we have the same understanding of "a single relatively large contribution of a new feature". My understanding of this is "a hands-on", "a bachelor thesis", or "a master thesis". Those contributions typically implement some functionality new to the project and typically exceed by far 250 lines of code. This is typically a process that takes 3 to 6 months to implement. In a hands-on/thesis there are no smaller features students work on.
>
> Is this the same understanding of "a relatively large contribution of a new functionality"?
>
> Thanks,
> Marcel
>
> _______________________________________________
> recommenders-dev mailing list
> recommenders-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/recommenders-dev