Re: GSoC in 2018?

On 16 January 2018 at 20:36, Bastien Bouclet <[email protected]>
wrote:

> 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.
>
That's good to hear.

The mentoring part seemed good as well with each student being able to find
> help
> easily.
>
I am glad it is visible even from outside.



> 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.
>
I fail to see where this comes from.

We were involved in the program for 10 years, and we always demanded that
all development by students is done on public.

Last years it was done on github in cloned repositories, and in the latest
couple of years we were even always looking for merging their work ASAP and
continue in-tree. And we always merge whole history. And of course, we use
github as the review platform along the GSoC project course, and were
always inviting everyone to help.

Could you please be a bit more specific, where did you see these large pull
requests as a beginning, not the end of the students' work?

Moreover, we require students to blog about their progress in details.

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.
>
Could you please be more specific, where did you see this happening? Which
projects?

We often review the project scope as they go and descope features for the
sake of quality. It was happening with every successful projects so far.



> 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.
>
This always was like this.



> * 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.
>
This was encouraged to do every time when applicable. Usually students
blogged about their design solutions, the blogs are still online.

* Design tasks are mandatory for non trivial non engine work.
>
We did not have many non-engine works, and there were designs.

* 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.
>
This was always happening.



> * There can be at most two open tasks at any given time (one that's being
> worked
>   on, and one that's being reviewed).
>
We were not spending time on putting tasks in any kind of backlog. The
students were obliged to blog about their progress according the schedule
(remember, it is part of their proposal, the schedule), and update the
schedule along the way if needed.


> * 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.
>
It was always like this. Another option is to discuss the schedule change
with their mentor.



> * The focus is on building solid and well designed foundation that can
> easily
>   be maintained / completed by others (possibly GSoC students the next
> year).
>
We had solid and well designed foundation for the last 10 years, and
maintained it for these 10 years. Moreover, we participate every year in
the Google Mentor Summit where we both share and discuss our achievements
and success with the program.

The requirements to the students are clearly written here:
http://wiki.scummvm.org/index.php/Summer_of_Code/Project_Rules


Eugene

_______________________________________________
Scummvm-devel mailing list
[email protected]
http://lists.scummvm.org/listinfo/scummvm-devel