[Scummvm-devel] GSoC in 2018?

[Arnaud Boutonné]

Hi Bastien,

I'm really surprised by your mail, as we put a lot of things in place to
avoid this tunnel effect / feeling of lock of transparency.
We list each year the points on our application form, which is public on
the wiki (http://wiki.scummvm.org/index.php/Summer_of_Code/Application/2017).
We also defined a set of rules for the students (
http://wiki.scummvm.org/index.php/Summer_of_Code/Project_Rules). One of
those rules is about communication: "we require you to *communicate with
your mentor* every second day.", another one is about a weekly blog post to
keep everybody aware of the progress. Add to that the fact that students
use gitHub to commit, and that this fork is mentioned on the very first
blog post, and I sincerely think the situation is really transparent.
If one have enough motivation, (s)he could make code reviews and add
comments on the commits on a daily basis :)

Concerning the delay before the code is in a merge request (which is less
critical as it's in github anyway), In order to try to keep the students,
we decided several years ago to merge as soon as possible, which ideally
means as soon as after the second evaluation (it was after mid-term
evaluation before last year's GSoC). In the case of Supernova, we didn't
manage to do it for various good and bad reasons, so it's only coming now
that the game has been translated in English and the engine has been
polished. Sludge at the opposite was merged early in the process. We'll try
to improve, as usual. But merging before the second evaluation may be
annoying when we have the case of a disappearing or failed student. We have
to think about it

I understand your feeling concerning the focus during GSoC because, well,
that's precisely what happens! GSoC is about 3 months, students are
sometimes trained and experienced, but sometimes they are not, and several
times I spent after GSoC a lot of time on refactoring and polishing. It's
not that bad for engines, as long as mentors are around for the polishing
and for the maintenance afterwards (or even better, when the students stay
in the team and do that too). We are not blocked on feature completeness:
it happens that students are passed despite the task isn't completely done:
we may have underestimated the task, for example. Sadly, based on our
experience, when that happens, we rarely manage to complete the task
afterwards and we end with useless code.

What you propose is, I think, perfect for a professional environment but
far too much for the GSoC: we won't have time, really. For non-engine
tasks, I would says that at the opposite it's absolutely mandatory, and we
already do that in a slightly different way. The student works on the
detailed design document during the bonding period, with his mentors. If
Sev and Wjp aren't mentors, it's obvious they'll be included in the
discussions too. For engine tasks, design discussion occur too during the
bonding period, but the formalism is different as the impact is very local
(the engine itself) and easy to refactor afterwards.
After the bonding period, it'll be very difficult to have more documents:
as the GSoC lasts 3 months and includes 3 evaluation periods (which involve
some lost time), time flies crazily during the period.

That said, it's very nice that you're available for mentoring. maybe you
could try the more formal approach you propose if you have a student (but
please, during the bonding period!) :)

I hope I covered your points and answered to some of your problems

Best regards,
Arnaud



On Tue, Jan 16, 2018 at 8:36 PM, Bastien Bouclet <bastien.bouclet at gmail.com>
wrote:

> Hi all,
>
> I've never been involved with GSoC (and it's fine). As an outsider, I would
> like to provide my feedback on what went well during the previous seasons
> and what could be improved for this year. I don't mean to put the blame on
> anybody. Quite the opposite, really. A lot of good work has been
> accomplished.
>
> The organisational aspect seemed fine to me. Finding project ideas,
> interacting
> with the GSoC team to register the ScummVM organisation. Welcoming,
> encouraging
> and selecting students.
>
> The mentoring part seemed good as well with each student being able to
> find help
> easily.
>
> What I'm having trouble with is the lack of transparency of the whole
> production
> period. To the outsider a GSoC project really begins at the end of the
> summer
> with a very large pull request being submitted. This is a problem because:
> * Very large pull requests are hard to review.
> * Once all the code has been written and tested, it's too late to provide
>   feedback on the design.
> * It's too late to provide advice so the next bits are produced with a
> better
>   quality.
>
> Another pain point for me is that focus seems to be too much on respecting
> the
> schedule / producing large amounts of features. This sometimes comes at
> the cost
> of code quality. Unfortunately history has shown that a lot of students
> disappear at the end of the summer and don't stay to maintain the code.
> The regular team members are left to deal with large amounts of hastily
> written code.
>
> To improve, my proposal is as follows:
> * The student and the mentor periodically decide on the next tasks. Each
> task
>   is designed to take at most 2 or 3 days of work.
> * Tasks can be either design tasks or implementation tasks. Design tasks
> result
>   in a short RFC document describing the feature, the chosen
> implementation, and
>   the motivation for the implementation. Implementation tasks result in
> code.
>   Both kinds of tasks are reviewed by the team through pull requests.
> * Design tasks are mandatory for non trivial non engine work.
> * A task is 'done' when the associated pull request has been approved by
> the
>   mentor (or a co-mentor) and at least one other team member.
> * There can be at most two open tasks at any given time (one that's being
> worked
>   on, and one that's being reviewed).
> * Failure to meet the schedule and the amount of produced features are not
> critera
>   used to evaluate students. This is made very clear to the students.
> * The focus is on building solid and well designed foundation that can
> easily
>   be maintained / completed by others (possibly GSoC students the next
> year).
> * All discussion relevant to GSoC is public for the whole team to see
>   (IRC, mailing list, ...)
>
> I'm all in favor of ScummVM participating in GSoC this year.
>
> I'm available to mentor or co-mentor OpenGL or ResidualVM-related tasks if
> desired.
>
> Bastien
>
> 2018-01-16 10:47 GMT+01:00 Einar Johan Trøan Sømåen <
> einarjohants at gmail.com>:
>
>> I'll check my calendar, but tentatively I'm fine with mentoring either of
>> those tasks (or co-mentoring both for that matter)
>>
>> Einar Johan
>>
>> tir. 16. jan. 2018 kl. 10.43 skrev Arnaud Boutonné <
>> strangerke at scummvm.org>:
>>
>>> Hi somaen
>>>
>>> Would you have some time to mentor it? T0by, the same question to you?
>>>
>>> btw, who could mentor the ICB task?
>>>
>>> Best regards,
>>> Arnaud
>>>
>>>
>>> On Tue, Jan 16, 2018 at 10:40 AM, Einar Johan Trøan Sømåen <
>>> einarjohants at gmail.com> wrote:
>>>
>>>> There is also the wintermute 3D task, which I still think is a decent
>>>> one. So I'm in favour.
>>>>
>>>> Einar Johan
>>>>
>>>> tir. 16. jan. 2018 kl. 10.13 skrev Arnaud Boutonné <
>>>> strangerke at scummvm.org>:
>>>>
>>>>> Hey Pawel :)
>>>>>
>>>>> Congratulations for the release of v0.3 ... And also, it shows
>>>>> activity on the project which is really cool.
>>>>> Did someone consider the Penumbra engine, yet? :)
>>>>>
>>>>> See you
>>>>> Arnaud
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jan 16, 2018 at 9:21 AM, Paweł Kołodziejski <
>>>>> aquadran at xtr.net.pl> wrote:
>>>>>
>>>>>> ICB for ResidualVM is still valid task.
>>>>>>
>>>>>>
>>>>>> On 16 Jan 2018, at 09:18, Arnaud Boutonné <strangerke at scummvm.org>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Eugene, hi everybody
>>>>>>
>>>>>> I'm in favor of applying this year again. We can work on last year's
>>>>>> list (http://wiki.scummvm.org/index.php/Summer_of_Code/GSoC_Ideas
>>>>>> _2017). Sludge engine and Supernova's first game are done, and the
>>>>>> 2nd supernova game can be used as a task.
>>>>>> Of course, we have to check the list in order to remove the obsolete
>>>>>> one (typically, I have no idea of the status of ICB for ResidualVM, and I
>>>>>> don't know if it's still an option to get a student for Director).
>>>>>>
>>>>>> My favorite task is the one about shaders/scalers. It's been lying
>>>>>> there foreever, and could give us a really nice outcome.
>>>>>>
>>>>>> The deadline for org application forms is in 2 weeks, so we really
>>>>>> have to work on that if I'm not the only one thinking it's a good idea.
>>>>>>
>>>>>> Oh, and I volunteer to be a mentor this year.
>>>>>>
>>>>>> Do you want me to spend some time at looking if there are other
>>>>>> low-hanging fruits we could find for potential mentors (like existing
>>>>>> engines lying around, or source code availability for other games?)
>>>>>>
>>>>>> Best regards,
>>>>>> Arnaud
>>>>>>
>>>>>> On Tue, Jan 16, 2018 at 12:40 AM, Eugene Sandulenko <sev at scummvm.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Team,
>>>>>>>
>>>>>>> Should we apply for the GSoC this year? Do we have enough ideas and
>>>>>>> mentors?
>>>>>>>
>>>>>>>
>>>>>>> Eugene
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Scummvm-devel mailing list
>>>>>>> Scummvm-devel at lists.scummvm.org
>>>>>>> http://lists.scummvm.org/listinfo/scummvm-devel
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Scummvm-devel mailing list
>>>>>> Scummvm-devel at lists.scummvm.org
>>>>>> http://lists.scummvm.org/listinfo/scummvm-devel
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Scummvm-devel mailing list
>>>>> Scummvm-devel at lists.scummvm.org
>>>>> http://lists.scummvm.org/listinfo/scummvm-devel
>>>>>
>>>>
>>>
>> _______________________________________________
>> Scummvm-devel mailing list
>> Scummvm-devel at lists.scummvm.org
>> http://lists.scummvm.org/listinfo/scummvm-devel
>>
>>
>
> _______________________________________________
> 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/749efa68/attachment-0001.html>