Re: [GSoC 2020] Extraordinary circumstances and early birds

From: David Bellot (david.bellot_at_[hidden])
Date: 2020-03-29 12:52:48

Hi Boost community,

as I'm in charge of the admin of Google Summer of Code for Boost, I will
simply said that I mostly agree with the answers from Pranam, Mateusz and
Christopher. To resume in a few points:
1- we expect students to contact us early. Not only because we want to have
motivated students, but also because we need time to know them and help
them writing a good proposal, making ideas clear and answer their questions
(I mean their technical, precise and accurate questions). If students
contact us at the very end of the initial process, I'm sorry but we won't
have time to devote to them. It would be unfair for all the others.
2- we expect students to have a good level in C++, I mean a really good
level. We don't have time to babysit or teach them C++. The fact they had
published good academic papers or received excellent grades in various
topics is mostly irrelevant. It is relevant for other things, not for being
selected as a GSoC student. We made it clear that we want code to be
delivered and code to be contributed to the master branch of Boost. This
code will be packaged in the next versions of Boost and should be of the
same quality as the rest of the Boost libraries. It's challenging but we
aim at excellence. Nothing less. And there are excellent C++ students. A
lot!
3- for many years, we asked students to do a competency tests. It is used
to give us an idea of who can and cannot do C++. I know it's far from
perfect, but we use it more as a filter than a definitive way to prove a
student should be chosen. And in general, many students cannot complete the
test.
4- as far as I'm concerned, I do consider the academic level of the
students. In the past, I had much better results with 4/5th year of PhD
students as far as I'm concerned. But it is not a rule and not part of our
selection process. It's just an observation. But if I have a last-minute
poor proposal from a PhD student with 10 papers in international journals,
and an excellent early proposal from a 1st year student, chances I will
select the 1st year student anyway.

Every year, my first task is to remove all the bad proposals. I don't even
ask the rest of the mentors what they think about it, because it's too
obvious the students will not be accepted. How do I know the students don't
have what it takes to make a good GSoC? It's very simple: if I receive an
empty document, it's a no. If I receive a resume without a proposal in it,
it's a no. If I receive a proposal saying: I want to participate to
open-source projects, it's a no. If I receive an email telling me they
didn't have time to post the proposal before the last day, it's a no. I'm
not caricaturing. Every year we have dozens of "proposals" (please allow me
to put this word in between quotes) like what I described. You understand
why I don't bother asking the other mentors now. Then we have the proposals
of those students who took time to contact us, who took time to speak with
us, who took time to show and convince use they can write good C++. These
are the students we love to work with.

I know our selection process is far from perfect (Mateusz has a lot of
great ideas to improve it for example), but I think it is on average fair
to all the students.

Finally, I would like to thank Madhur for his excellent questions and I
hope I answered to all of them. I found this debate very interesting and
absolutely spot on. It's what I love about open-source!

Cheers,
David

On Sun, Mar 29, 2020 at 7:13 PM Christopher Kormanyos via Boost <
boost_at_[hidden]> wrote:

>  > The point I'm trying to make here is that in these extraordinary
> > circumstances:
> > - should Boost neglect the "early bird" and treat all applicants
> equally?
> > - should Boost compensate for the lack of work samples with the history
> of
> > the student (like academic records, academic projects, research papers)?
> Thanks for your observations, Madhur.
> I think it makes sense to look at all proposals that satisfy theformal
> requirements of timing and form.
> That being said, the proposal quality seems to be
> relativelyself-regulating. This is evident in the sense that the early
> birdshave already been in contact with us and asked detailedquestions. They
> have had an opportunity to incorporate theknowledge gained through this
> question-asking phase withinthe works of their proposals and their
> programming competencies.
> There is also an unremovable human factor. I think mostpeople dedicated to
> open source code have a certain(maybe even a large) portion of compassion
> about it.It is fun and pleasant to see this kind of passion growin the
> community. In general, the sudents who participatedactively early seem more
> into it in this non-written sense.This can be partly revealed in the
> proposals, but is alsocertain to be present within the mentor's mental
> recollectionsto some extent.
> Keep going in Boost!
>
> Kind regards, Chris
>
>    On Saturday, March 28, 2020, 9:15:19 PM GMT+1, Mateusz Loskot via Boost
> <boost_at_[hidden]> wrote:
>
>  On Sat, 28 Mar 2020 at 15:34, madhur4127 via Boost
> <boost_at_[hidden]> wrote:
> > This is a huge loss to brilliant and enthusiastic students as they will
> not be able to gain
> > experience.
>
> Past years experience and statistics may form a basis to challenge
> your enthusiasm.
>
> > This could be an opportunity for Boost to mentor these students who don't
> > have prior experience with open source or with a rich C++ background. If
> a
> > student is ready to devote himself/herself then I guess there's enough
> time
> > to learn (till Jun 1) about C++/Project to get things rolling.
>
> No, there is not enough time.
> Let me put it straight: readiness to devote is not enough to guarantee
> successful completion of GSoC project as not enough are highest
> grades on completion of a mathematics or algorithms course.
>
> The current phase is the Student Application Period which
> lasts from March 16, 2020 until March 31, 2020.
>
> It is March 28 and students appear out of the blue "looking for contact
> with mentor" with a long list of achievements, with 8/10 score in C++
> and with zero idea about what they want to develop. They often don't
> even know which Boost library they want to apply with.
> That clears all the rockstar grades from their CS courses, doesn't it.
>
> On the other hand, there is a handful of students who arrive early,
> in January/February, find bugs they want to fix, features they want to
> develop, who give it a try hacking something for a Boost library
> (I'm speaking of GIL here), who know how to run g++ from command line,
> who seek help asking specific questions, who eventually submit pull
> requests and who are persistent enough to endure the nitpicking
> process the review of their PR.
> And they do it before the Student Application Period even starts!
>
> I wish Boost GSoC introduced this policy next year [1]
>
>     "Some organizations make it a must for you to fix a bug in their
>     code base before submitting a proposal but some do not.
>     Your chances are always high if you can fix a bug in the code."
>
> [1]
> https://medium.com/@akshikawijesundara/google-summer-of-code-dos-and-do-not-s-896f05e29ac0
>
> > > FYI, you are late.
> >
> > Mateusz posted in other thread about the student being late (as of today)
> > but the GSoC application deadline is due March 31, which I would
> > wholeheartedly agree in case of normal circumstances.
> > [...]
> > The point I'm trying to make here is that in these extraordinary
> > circumstances:
>
> FYI, the GSoC does not recognise any extraordinary circumstances
> https://opensource.googleblog.com/
> https://summerofcode.withgoogle.com/
>
> > If a student performs well in the competency test then it indicates that
> the
> > student would do the job
>
> No, solving the competency test gives no guarantees.
> The competency test is equivalent of "show me, tell me" questions
> at the start of driving licence test in UK [2], before you start driving!
> Answering those questions brilliantly does not guarantee a learner
> will not crash the car in the first junction after leaving the car park.
>
> [2]
> https://www.gov.uk/government/publications/car-show-me-tell-me-vehicle-safety-questions/car-show-me-tell-me-vehicle-safety-questions
>
> > and I think the selection criteria should be
> > tweaked so as to consider that students who lost internships and
> otherwise
> > who could be a great value to the library (even for a short time - GSoC)
> > don't get neglected.
>
> IMO, Boost cannot afford to be a backup plan for any students.
> If students had not planned to apply for GSoC with a project for Boost in
> 2019
> or very early in 2020, they will not be ready to develop and complete a
> project.
>
> No tweaking is necessary and it any changes would be unfair, unless
> Google/GSoC makes any official changes, then we will have to comply.
> FYI, the selection process is clear and publicly available:
> https://google.github.io/gsocguides/mentor/selecting-a-student
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>