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

[Amara Emerson via cfe-dev]

Agreed. I think it's worth thinking about what GSoC is actually about,
which according to the website: "Google Summer of Code is a global
program focused on introducing students to open source software
development."

Strongly favouring students with prior experience in community
involvement with LLVM is somewhat missing the point, and I think we
should be mindful of the differences in opportunities that some
students have had.

Amara

On 18 February 2017 at 02:10, Anna Zaks via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> On 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?
>
>
> While students with previous LLVM dev experience will be more productive,
> GSoC is a great way of attracting newcomers to the project! So if a proposal
> is scoped to be completed in time even by someone not familiar with LLVM, we
> should still accept it.
>
> - How should we rank (if any) “research or unbounded projects” vs “project
> with an immediate application”? Should we strive to keep a balance?
>
>
> My preference would be to give priority to projects that are on a trajectory
> to have practical benefit.
>
> - 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 ).
>
>
> An invaluable part of participating in GSoC is for students to learn about
> how open source projects work. Following the developer policy is one of the
> main aspects of development in these codebases. In addition, if a project is
> being developed on a branch it is likely not to get merged and the impact of
> the student, the mentor, as well as the GSoC budget will be minimal.
>
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>