<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>