[Scummvm-devel] GSoC in 2018?

[Arnaud Boutonné]

Hi Colin,

concerning the answers to your questions:
- The student is required to prepare a schedule in their application. At
this point of the process, it means we have been accepted by Google and
that the available mentors have filtered the list of ideas to only propose
the ones with at the very least a mentor (as we can find later a co-mentor,
which is something we do systematically). The student may of course bring
their own idea, but they have to convince someone to become a mentor for
the task. As the application period is pretty long, there's a lot of time
to ask question and challenge this planning. The student application is
visible by all the mentors & org admins, and everybody is welcome to ask
more details or challenge it.
- At the end of this period, we organize a vote, and check who confirms to
be a mentor for this or that task, and we make sure there are 2 mentors per
task. Based on that, we ask to google our low and high number of student
slots. Once we have the number of slots, based on the votes and mentors
available, we allocate the slots to students. After Google announces the
results, the bounding period starts. We use this period to polish the
schedule, ask for more details in analysis or plans, or if things are
already fine we could suggest a student to start coding, which may be used
later to let them finish earlier if they have exams, for example (that
happens a lot with European students).
- During the coding period, students are required to discuss with their
mentors at the very least every two days. I try to communicate at least 2
times per day, for example. For a non-engine task, I expect (at least)
Eugene or Willem Jan to be involved, and it wouldn't be surprising that
wider discussions occur on -devel, though if it had to happen during the
coding period it would be a sign something wasn't prepared properly during
the (very) long bonding period.
- As mentioned before, we have at this point a polished schedule and a
student who is coding. we keep track of progress very regularly (maybe
everyday? The student should be pushing daily anyway) so it's easy to talk
to the student if there's an issue. As the GSoC lasts 3 months with 3
evaluations, we mostly have 3 weeks of coding for 1 week of polishing,
filling papers, and stressing for the result to the point that coding is
complicated. so, once per month, all the mentors discuss about
passing/failing students. Usually, the last word is for the 2 "official"
mentors of the student. one think verified is, of course, the quality of
code and the velocity, and the respect of all the rules we set. Google
insists that we should not (shall not?) pass a student if there's a doubt.
We are slightly more tolerant than that ;) If we have the feeling that the
student is behind schedule but is doing their best, we adapt the scope with
them. This obviously means that ideally the student will have to stay after
GSoC to finish the task, or that we decide to split the task into two, ...
or that the mentors will work on the task to finish it themselves, if
possible.

With the two periods of appraisal, the disappearing students who only
waited for the 1rst or 2nd payment, the failed students, etc, we can't
reasonably merge the code before the 2nd appraisal. After that 2nd
appraisal, we try to merge as soon as possible.

Best regards,
Arnaud



On Wed, Jan 17, 2018 at 5:34 PM, Colin Snover <scummvm-devel at zetafleet.com>
wrote:

> Thanks. Could you please tell me where exactly on that page you linked are
> the answers to the specific questions that I asked? I do not see any
> answers to what I asked about.
>
>
> On 2018-01-17 01:22, Eugene Sandulenko wrote:
>
> On 17 January 2018 at 02:33, Colin Snover <scummvm-devel at zetafleet.com>
> wrote:
>
>> I don’t know anything about how the GSoC process works differently now
>> from what bgK proposes. His methodology sounds like a pretty usual one to
>> me for software development life cycle, especially when training junior
>> developers who don’t have past experience managing projects. Could you
>> describe what is the current methodology that is used by GSoC mentors, so
>> everyone can start with the same amount of knowledge about the current
>> process?
>>
>
> I highly recommend to read the current GSoC documentation, especially for
> those who did not have a chance to work in the program:
>
>    http://wiki.scummvm.org/index.php/Summer_of_Code
>
>
> Eugene
>
>
> --
> Colin Snoverhttps://zetafleet.com
>
>
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.scummvm.org
> http://lists.scummvm.org/listinfo/scummvm-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20180117/c7fa666c/attachment-0001.html>