<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 16 January 2018 at 20:36, Bastien Bouclet <span dir="ltr"><<a href="mailto:bastien.bouclet@gmail.com" target="_blank">bastien.bouclet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The organisational aspect seemed fine to me. Finding project ideas, interacting<br></div><div>with the GSoC team to register the ScummVM organisation. Welcoming, encouraging</div><div>and selecting students.</div></div></blockquote><div>That's good to hear. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The mentoring part seemed good as well with each student being able to find help</div><div>easily.</div></div></blockquote><div>I am glad it is visible even from outside.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>What I'm having trouble with is the lack of transparency of the whole production</div><div>period. To the outsider a GSoC project really begins at the end of the summer</div><div>with a very large pull request being submitted.</div></div></blockquote><div>I fail to see where this comes from.</div><div><br></div><div>We were involved in the program for 10 years, and we always demanded that all development by students is done on public.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Moreover, we require students to blog about their progress in details.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Another pain point for me is that focus seems to be too much on respecting the</div><div>schedule / producing large amounts of features. This sometimes comes at the cost</div><div>of code quality.</div></div></blockquote><div>Could you please be more specific, where did you see this happening? Which projects?</div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>To improve, my proposal is as follows:</div><div>* The student and the mentor periodically decide on the next tasks. Each task</div><div>  is designed to take at most 2 or 3 days of work.</div></div></blockquote><div>This always was like this.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>* Tasks can be either design tasks or implementation tasks. Design tasks result</div><div>  in a short RFC document describing the feature, the chosen implementation, and</div><div>  the motivation for the implementation. Implementation tasks result in code.</div><div>  Both kinds of tasks are reviewed by the team through pull requests.</div></div></blockquote><div>This was encouraged to do every time when applicable. Usually students blogged about their design solutions, the blogs are still online.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>* Design tasks are mandatory for non trivial non engine work.</div></div></blockquote><div>We did not have many non-engine works, and there were designs.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>* A task is 'done' when the associated pull request has been approved by the</div><div>  mentor (or a co-mentor) and at least one other team member.</div></div></blockquote><div>This was always happening.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>* There can be at most two open tasks at any given time (one that's being worked</div><div>  on, and one that's being reviewed).</div></div></blockquote><div>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. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>* Failure to meet the schedule and the amount of produced features are not critera</div><div>  used to evaluate students. This is made very clear to the students.</div></div></blockquote><div>It was always like this. Another option is to discuss the schedule change with their mentor.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>* The focus is on building solid and well designed foundation that can easily</div><div>  be maintained / completed by others (possibly GSoC students the next year).</div></div></blockquote><div>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.</div><div> </div><div>The requirements to the students are clearly written here: <a href="http://wiki.scummvm.org/index.php/Summer_of_Code/Project_Rules">http://wiki.scummvm.org/index.php/Summer_of_Code/Project_Rules</a></div><div><br></div><div><br></div><div>Eugene</div></div></div></div>