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?
- How should we rank (if any) “research or unbounded projects” vs “project with 
an immediate application”? Should we strive to keep a balance?
- 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/ )?
- 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 ).

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.

We should have this discussion before receiving the projects proposals, which 
opens on 2/28.

Best,

-- 
Mehdi

_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to