<div dir="ltr">Going to add a "me too" to everything Tobias wrote here. I've spent a lot of years mentoring GSoC students and honestly have found a strong correlation to previous work on a project, but that's the same with anyone. Some previously unknown people have come onto the project and done quite well. Ultimately it comes down to a project with an easy ramp up and small bite sized chunks of work.<div><br></div><div>If I can be of any help here let me know.</div><div><br></div><div>-eric<br><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 21, 2017 at 11:54 PM Tobias Grosser via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Feb 20, 2017, at 03:26 PM, Amara Emerson via llvm-dev wrote:<br class="gmail_msg">
> Agreed. I think it's worth thinking about what GSoC is actually about,<br class="gmail_msg">
> which according to the website: "Google Summer of Code is a global<br class="gmail_msg">
> program focused on introducing students to open source software<br class="gmail_msg">
> development."<br class="gmail_msg">
><br class="gmail_msg">
> Strongly favouring students with prior experience in community<br class="gmail_msg">
> involvement with LLVM is somewhat missing the point, and I think we<br class="gmail_msg">
> should be mindful of the differences in opportunities that some<br class="gmail_msg">
> students have had.<br class="gmail_msg">
<br class="gmail_msg">
Dear Mehdi,<br class="gmail_msg">
<br class="gmail_msg">
thanks for sparking this discussion.<br class="gmail_msg">
<br class="gmail_msg">
I believe we should evaluate students only by the quality of the student<br class="gmail_msg">
himself without requiring previous LLVM experience. If a student can<br class="gmail_msg">
convince us that he could be a great contributor in the future,<br class="gmail_msg">
I am very much in favor of accepting him. In fact, many students who<br class="gmail_msg">
never contributed to LLVM before<br class="gmail_msg">
had great impact. Justin who pushed the PTX backend to a usable state<br class="gmail_msg">
during GSoC, got later hired by NIVIDA and also helped upstreaming the<br class="gmail_msg">
current PTX backend. He never had LLVM experience before.<br class="gmail_msg">
<br class="gmail_msg">
The one most important thing which in my experience has been a very good<br class="gmail_msg">
filter of good students is the requirement for them to have at least one<br class="gmail_msg">
patch upstreamed and committed to LLVM. This does not mean that they<br class="gmail_msg">
have to be long-term LLVM contributors, but this means they got in touch<br class="gmail_msg">
with us early enough, asked for a trivial problem for them to address,<br class="gmail_msg">
and went once through a full review process.<br class="gmail_msg">
We can give them as much guidance as possible and help them finding very<br class="gmail_msg">
easy bugs. However, if a student -- with all the help we can provide --<br class="gmail_msg">
does not manage to submit a patch for a trivial problem over 6-8 weeks<br class="gmail_msg">
it is a clear indication that he won't make a lot of progress in GSoC as<br class="gmail_msg">
well. On the other side, if they once went through a full review<br class="gmail_msg">
process, we have already a good feeling how this interaction will pan<br class="gmail_msg">
out in the future.<br class="gmail_msg">
<br class="gmail_msg">
The "one-patch-rule" is very common to a lot of GSoC projects and I<br class="gmail_msg">
suggest we require it as well and make it very clear and explicit on our<br class="gmail_msg">
GSoC application page how students can get support with such<br class="gmail_msg">
a patch.<br class="gmail_msg">
<br class="gmail_msg">
Regarding which projects to choose. I believe a good mix is great and --<br class="gmail_msg">
assuming we have a good mix -- the quality of the proposal should help<br class="gmail_msg">
us to decide. I agree here with arguments brought forward by Hal and<br class="gmail_msg">
John.<br class="gmail_msg">
<br class="gmail_msg">
Best,<br class="gmail_msg">
Tobias<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> Amara<br class="gmail_msg">
><br class="gmail_msg">
> On 18 February 2017 at 02:10, Anna Zaks via llvm-dev<br class="gmail_msg">
> <<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg">
> ><br class="gmail_msg">
> > On Feb 16, 2017, at 10:16 PM, Mehdi Amini via llvm-dev<br class="gmail_msg">
> > <<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg">
> ><br class="gmail_msg">
> > Hello all,<br class="gmail_msg">
> ><br class="gmail_msg">
> > GSOC is around the corner, and the LLVM projects plans to participate again<br class="gmail_msg">
> > this year. For those who don’t know about GSOC, students are proposing a<br class="gmail_msg">
> > project that they will work on for 3 months. Amongst other, one goal for<br class="gmail_msg">
> > LLVM is to mentor students to become good developers and also contributors<br class="gmail_msg">
> > to the LLVM project (or user/advocate of LLVM for building other cool<br class="gmail_msg">
> > projects).<br class="gmail_msg">
> ><br class="gmail_msg">
> > A key part of the process is about how do we select the projects. The way<br class="gmail_msg">
> > we’ve done it last year, is that the volunteer mentors shared an email<br class="gmail_msg">
> > thread and ultimately each one individually ranked the projects. We kept the<br class="gmail_msg">
> > average grading for each project to ranked them overall.<br class="gmail_msg">
> ><br class="gmail_msg">
> > In order to make the process more transparent to student applicants, we want<br class="gmail_msg">
> > to formalize and announce the criteria for ranking and selection project.<br class="gmail_msg">
> ><br class="gmail_msg">
> > The purpose of this email is to gather community feedback about the<br class="gmail_msg">
> > criterion that mentors should apply when ranking projects, for example:<br class="gmail_msg">
> ><br class="gmail_msg">
> > - Should we favor a student which has past contributions to LLVM compared to<br class="gmail_msg">
> > a newcomer? Is it more important or as equally important as the quality of<br class="gmail_msg">
> > the proposal?<br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> > While students with previous LLVM dev experience will be more productive,<br class="gmail_msg">
> > GSoC is a great way of attracting newcomers to the project! So if a proposal<br class="gmail_msg">
> > is scoped to be completed in time even by someone not familiar with LLVM, we<br class="gmail_msg">
> > should still accept it.<br class="gmail_msg">
> ><br class="gmail_msg">
> > - How should we rank (if any) “research or unbounded projects” vs “project<br class="gmail_msg">
> > with an immediate application”? Should we strive to keep a balance?<br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> > My preference would be to give priority to projects that are on a trajectory<br class="gmail_msg">
> > to have practical benefit.<br class="gmail_msg">
> ><br class="gmail_msg">
> > - What about “projects that touch LLVM/Clang/…” vs “projects that are<br class="gmail_msg">
> > building something on top of LLVM”? (For example this project was first<br class="gmail_msg">
> > proposed to be selected by LLVM before being rejected and finally picked by<br class="gmail_msg">
> > the Julia project directly:<br class="gmail_msg">
> > <a href="https://summerofcode.withgoogle.com/archive/2016/projects/6197080536121344/" rel="noreferrer" class="gmail_msg" target="_blank">https://summerofcode.withgoogle.com/archive/2016/projects/6197080536121344/</a><br class="gmail_msg">
> > )?<br class="gmail_msg">
> ><br class="gmail_msg">
> > - Should we ask that the work is done upstream all along? In the past there<br class="gmail_msg">
> > have been project developed on GitHub outside the community that have never<br class="gmail_msg">
> > been merged. The LLVM developer policy has a full section insisting on<br class="gmail_msg">
> > incremental development (<br class="gmail_msg">
> > <a href="http://llvm.org/docs/DeveloperPolicy.html#incremental-development" rel="noreferrer" class="gmail_msg" target="_blank">http://llvm.org/docs/DeveloperPolicy.html#incremental-development</a> ).<br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> > An invaluable part of participating in GSoC is for students to learn about<br class="gmail_msg">
> > how open source projects work. Following the developer policy is one of the<br class="gmail_msg">
> > main aspects of development in these codebases. In addition, if a project is<br class="gmail_msg">
> > being developed on a branch it is likely not to get merged and the impact of<br class="gmail_msg">
> > the student, the mentor, as well as the GSoC budget will be minimal.<br class="gmail_msg">
> ><br class="gmail_msg">
> > Hopefully we should be able to provide a set of guidelines to student that<br class="gmail_msg">
> > would help them fill the best application, and avoid unfortunate surprise at<br class="gmail_msg">
> > the end of the process.<br class="gmail_msg">
> ><br class="gmail_msg">
> > We should have this discussion before receiving the projects proposals,<br class="gmail_msg">
> > which opens on 2/28.<br class="gmail_msg">
> ><br class="gmail_msg">
> > Best,<br class="gmail_msg">
> ><br class="gmail_msg">
> > --<br class="gmail_msg">
> > Mehdi<br class="gmail_msg">
> ><br class="gmail_msg">
> > _______________________________________________<br class="gmail_msg">
> > LLVM Developers mailing list<br class="gmail_msg">
> > <a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a><br class="gmail_msg">
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> > _______________________________________________<br class="gmail_msg">
> > LLVM Developers mailing list<br class="gmail_msg">
> > <a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a><br class="gmail_msg">
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="gmail_msg">
> ><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> LLVM Developers mailing list<br class="gmail_msg">
> <a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a><br class="gmail_msg">
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
LLVM Developers mailing list<br class="gmail_msg">
<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a><br class="gmail_msg">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="gmail_msg">
</blockquote></div></div></div></div>