[llvm-dev] [lldb-dev] LLVM GSOC Projects Criteria Consultation (before 2/28)

[John Criswell via llvm-dev]

On 2/17/17 1:16 AM, Mehdi Amini via lldb-dev wrote:
> Hello all,
>
> GSOC is around the corner, and the LLVM projects plans to participate 
> again this year. For those who don’t know about GSOC, students are 
> proposing a project that they will work on for 3 months. Amongst 
> other, one goal for LLVM is to mentor students to become good 
> developers and also contributors to the LLVM project (or user/advocate 
> of LLVM for building other cool projects).
>
> A key part of the process is about how do we select the projects. The 
> way we’ve done it last year, is that the volunteer mentors shared an 
> email thread and ultimately each one individually ranked the projects. 
> We kept the average grading for each project to ranked them overall.
>
> In order to make the process more transparent to student applicants, 
> we want to formalize and announce the criteria for ranking and 
> selection project.
>
> The purpose of this email is to gather community feedback about the 
> criterion that mentors should apply when ranking projects, for example:
>
> - Should we favor a student which has past contributions to LLVM 
> compared to a newcomer? Is it more important or as equally important 
> as the quality of the proposal?

Historically, we have opted for students with previous LLVM experience 
because they are more likely to make progress and complete their 
project.  For most projects, this makes sense. However, it does have the 
downside of attracting students that are already "on board" with LLVM; 
it doesn't introduce new developers to the LLVM community.

We therefore might want to devise projects that would fit beginner 
developers.  For example, a proposal that aims to fix a set of bugs 
might work.

> - How should we rank (if any) “research or unbounded projects” vs 
> “project with an immediate application”? Should we strive to keep a 
> balance?

We should strive to keep a balance.  The important factor is getting 
students to either improve the existing LLVM software or to build cool 
tools using LLVM.  We want to grow the LLVM community, and both the 
software development and research communities are important.

I also believe that research projects and open-ended projects can 
provide long-term gains even if they don't provide immediate short-term 
benefits.  Remember that LLVM itself was once a research project.

If we keep a balance, then we will have a nice mix of short-term, low 
risk projects and projects that contribute to longer-term, higher risk 
goals.



> - What about “projects that touch LLVM/Clang/…” vs “projects that are 
> building something on top of LLVM”? (For example this project was 
> first proposed to be selected by LLVM before being rejected and 
> finally picked by the Julia project directly: 
> https://summerofcode.withgoogle.com/archive/2016/projects/6197080536121344/ 
> )?

We should encourage proposals that build something *with* 
LLVM/Clang/etc. as well as projects that improve the core compiler 
infrastructure.  Part of LLVM's appeal is that one can build *a lot* of 
tools with it.  We want to encourage students to use LLVM to build 
interesting things.

In some cases, we will have overlap with other communities (the Julia 
and FreeBSD communities come to mind).  I think that's fine.


> - Should we ask that the work is done upstream all along? In the past 
> there have been project developed on GitHub outside the community that 
> have never been merged. The LLVM developer policy has a full section 
> insisting on incremental development ( 
> http://llvm.org/docs/DeveloperPolicy.html#incremental-development ).

It depends on the project.  Projects that enhance the core 
infrastructure should probably follow the developer policy and 
contribute upstream.  Projects that are "trying out" a new idea or are 
research-oriented should probably not worry about working upstream; why 
upstream if you don't even know if what you're trying to do is going to 
work?

>
> Hopefully we should be able to provide a set of guidelines to student 
> that would help them fill the best application, and avoid unfortunate 
> surprise at the end of the process.

I think what actually makes a strong proposal is whether the student 
presents a good idea, whether the proposal convinces the reader that the 
student will be able to perform the work, and whether there is a mentor 
interested in the project.  If you have these three things, then you 
have a project that is more likely to achieve its goals and grow the 
LLVM community.

Regards,

John Criswell

-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170217/dd1c0bb8/attachment.html>