[Scummvm-devel] GSoC in 2018?

[Colin Snover]

Hi,

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.

On 2018-01-16 17:34, Arnaud Boutonné wrote:
> 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 :)
>

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?

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

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

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:

* What is the way in which work units are allocated?
* How and where is the work progress tracked?
* 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?
* Is there a set criteria for a task to be considered completed
successfully?

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.

Thanks for listening to my feedback, and I look forward hearing from
everyone.

Best,

-- 
Colin Snover
https://zetafleet.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20180116/6b3cee2d/attachment.html>