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

[Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>]

Hi Wayne,

your scenario absolutely makes sense - even more in distributed developer teams.

We'll have to work out a process that fits nicely into our current (mostly local) setup. Typically we have 1-2 student meetings per week discussing progress, issues etc. which makes some parts of the review cycle via Bugzilla look like overkill.

However, by the time other people join the project from outside TU our process won't work anymore. Thus, we need to rethink our process for future committer elections.

Thanks for discussion,
Marcel


On 23.03.2011, at 18:54, Wayne Beaton wrote:

> 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
> _______________________________________________
> recommenders-dev mailing list
> recommenders-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/recommenders-dev