<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi,<br>
<br>
I share in bgK’s concerns regarding transparency and quality and
think that there is value in having a small discussion about
possible tweaks to the GSoC process to make it work better for
everybody. I know it can seem surprising that others don’t see
things the same way, and I think this email offers an opportunity
for everyone to talk and achieve a better mutual understanding. To
me, there isn’t a requirement for anything to definitely change
from this discussion. It is possible things are already as good as
they can be. I think of this as just a friendly exploration, since
there do seem to be multiple people sharing the same concerns.<br>
<br>
On 2018-01-16 17:34, Arnaud Boutonné wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CABojxEt8ASCTHTBPV=k6fHGH50ipQb=+sSH8piZqp_BD2geVWA@mail.gmail.com">
<div dir="ltr">Hi Bastien,
<div><br>
</div>
<div>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.</div>
<div>We list each year the points on our application form, which
is public on the wiki (<a
href="http://wiki.scummvm.org/index.php/Summer_of_Code/Application/2017"
moz-do-not-send="true">http://wiki.scummvm.org/index.php/Summer_of_Code/Application/2017</a>).
We also defined a set of rules for the students (<a
href="http://wiki.scummvm.org/index.php/Summer_of_Code/Project_Rules"
moz-do-not-send="true">http://wiki.scummvm.org/index.php/Summer_of_Code/Project_Rules</a>).
One of those rules is about communication: "<span
style="color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">we
require you to </span><b
style="color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">communicate
with your mentor</b><span
style="color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px"> 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.</span></div>
<div>If one have enough motivation, (s)he could make code
reviews and add comments on the commits on a daily basis :)</div>
<div><br>
</div>
</div>
</blockquote>
<br>
It is encouraging to me already that everyone agrees that
transparency is an important part of GSoC. You note the GSoC
students are required to communicate with their mentor. I think it
was (and is) a great idea to have this requirement. Since it is only
a requirement to communicate with the mentor, these conversations
are still allowed to be private and therefore opaque to the rest of
the team. Blogs and commits only show the outcomes of these
conversations. This rule could be tweaked by adding just one word so
the rule says that students are required to communicate *publicly*
with their mentors, so those conversations are open. I feel like
this would also give a better chance of students forming
relationships with people other than their mentor, which might help
keep them around later. What do you think about this idea?<br>
<br>
<blockquote type="cite"
cite="mid:CABojxEt8ASCTHTBPV=k6fHGH50ipQb=+sSH8piZqp_BD2geVWA@mail.gmail.com">
<div dir="ltr">
<div>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</div>
</div>
</blockquote>
<br>
I can validate that it is difficult to make the right calls about
when things are “good enough” all the time. As software developers I
think we all have been in this position in the past on one project
or another. I am glad to see an acknowledgement that there is still
the potential for improvement in this regard. One smaller process
tweak I don’t remember seeing suggested yet might be to have the
student open a PR with their *first* commit for each work unit. I
think this would improve visibility without making any more work for
the mentor or the student and give access to GitHub’s nice review
interface. What do you think about this approach?<br>
<br>
<blockquote type="cite"
cite="mid:CABojxEt8ASCTHTBPV=k6fHGH50ipQb=+sSH8piZqp_BD2geVWA@mail.gmail.com">
<div dir="ltr">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.
<div>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.</div>
</div>
</blockquote>
<br>
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? In particular, I am interested
to understand these things:<br>
<br>
* What is the way in which work units are allocated?<br>
* How and where is the work progress tracked?<br>
* What is the process for making adjustments to the scope of the
work if it appears that the schedule is too aggressive and
milestones are not being met?<br>
* Is there a set criteria for a task to be considered completed
successfully?<br>
<br>
I apologise in advance if this information is on the wiki and I just
don’t see it. Please feel free to point me specifically to where
this information exists if it is so. If not, it would be great once
these questions are answered to have the information posted on the
wiki for future reference and so potential new mentors have an idea
of how to approach the process.<br>
<br>
Thanks for listening to my feedback, and I look forward hearing from
everyone.<br>
<br>
Best,<br>
<pre class="moz-signature" cols="72">--
Colin Snover
<a class="moz-txt-link-freetext" href="https://zetafleet.com">https://zetafleet.com</a></pre>
</body>
</html>