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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
