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

[Davide Italiano via llvm-dev]

On Thu, Feb 16, 2017 at 10:16 PM, Mehdi Amini via llvm-dev
<llvm-dev at lists.llvm.org> 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 really think that past contributions are *very* important and *a big plus*.
When I was involved in FreeBSD we ended up with people submitting
high-quality proposals, got accepted and then we realized at day 1 of
coding they didn't even set up a VM or knew how to build things. In
other words, I'm under the impression that students need to be well
aware of the development workflow and being able to show up some
involvement in the community.

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

Again, my opinion, but we should give high(er) priority to projects
which can produce something reasonable in 3 months.
If it's a research project, it's fine, but I think there should be a
bound (e.g. tune the thresholds for unrolling).

> - 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 ).
>

Yes, I think incremental patches are the way to go. If there are
bugfixes, etc.. they should be merged immediately (after code review).
If it's a larger chunk of work it should be in a state where others
can take over if the student stops being interested after the summer
(or we want to remove the thing altogether, e.g. a pass).

> 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.
>

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare