On 02/17/2017 12: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?
I think that the quality of the proposal is the most important thing,
however, we should be realistic about the amount of time it will take to
bring a newcomer up to speed on our coding conventions, quality
standards, review process, etc. and factor that into the decision-making
process.
- How should we rank (if any) “research or unbounded projects” vs
“project with an immediate application”? Should we strive to keep a
balance?
Given the short time period involved, I favor projects of more immediate
utility. This does not mean that there can't be interesting open
questions, but in our judgment, these should be answerable in a matter
of weeks (i.e. choosing between clear alternatives, understood tuning
parameters, and the like).
- 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/
)?
I think we need to base this on the overall benefit to the community. If
working on a project built on top of LLVM will bring additional users,
end up making LLVM more robust, etc. then there might be significant
anticipated value. That having been said, in practice, justifying this
value will probably be more difficult than for a project contributing to
LLVM, Clang, etc.
- 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 ).
I think we should insist on incremental upstream development.
Thanks again,
Hal
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
--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
