<div dir="ltr">Well, I think you're going a bit too far in the details. <div>There's some liberty on how mentors are managing their student. This helps to have more mentors (and trust me, it's not the easiest part), and it seems to work pretty well considering our past scores. It certainly helps for some culture incompatibilities we "enjoyed" in the past. Typically, German/Nordic vs Latin culture. If mentors want to put a very solid organization & control, they are very welcome to do so (as long as their student don't run away, at least) but if they want to have manage it a different, it's fine too (as long as it gives results, ans as long as the student doesn't run away, obviously).</div><div><br></div><div>I personally do not try to get super small task, because I don't work like that on a daily basis. If it takes me the same effort to describe the tasks than to do it myself, I'll be tempted to do it myself at the end because it would take less time.</div><div><br></div><div>At the opposite, Somaen could certainly describe how he manages his students, and you would appreciate how meticulous he is. But even with his level of professionalism, I'm not sure he would have time on a daily basis to review a pull request and allow the student to go on. Somaen's feedback is required there, obviously. I'm just making assumptions based on how busy people are with real life :)</div><div><br></div><div>The way we work has been refined year after year with the following objectives:</div><div>- Ensure the student may have feedback as fast as possible (thus 2 mentors, which covers also the "disappearing mentor" point required by Google)</div><div>- Ensure we detect as soon as possible issues with the students, or potentially/actually disappearing students, and make sure we don't make them run away. As some of them are 18yo, we can't ask them the same experience than senior devs (that covers several points of Google's application form)</div><div>- Ensure we have something at the end (which also covers a point about code usefulness in Google's Application form)</div><div><br></div><div>It's never perfect, if only because perfection doesn't exist, but we do our best to improve with flexibility in mind. I personally discussed several times with googlers about our way of handling GSoC and I only got positive feedback so far (which also may explain why we have been accepted so many times as a mentoring org. I'm not sure many gaming project can say the same.</div><div><br></div><div>Now to answer your questions: "comprehensive and detailed" and "polished" doesn't mean it's as subjective as you think it is. It only means that all the mentors (we're talking about less than a dozen of persons from ScummVM and ResidualVM) can ask questions or add comments on the same proposal, helping the student to improve it, during the pretty long student proposal period. There's an obvious end to those discussion: the deadline imposed by Google. It's not endless, and it's collaborative.</div><div><br></div><div>After that</div><div><span style="font-size:12.8px">Who is responsible: the two mentors of the task have the last word. In the hypothetical case where they wouldn't agree, the org admins have to deal with it. Google doesn't care about excuses, the deadline *has* to be respected for applications, decisions, evaluations, filling papers, etc.</span></div><div><span style="font-size:12.8px">What should be done: work on the task based on the plan written by the student and validated by the mentors. Consider that if the mentors didn't validate it, it means that the student has been rejected.</span></div><div><span style="font-size:12.8px">Where should it happen: so far: in a student fork on git, with a merge request as soon as it's possible and reasonable (mentors are responsible to determine that. I would recommend not to merge before the 2nd evaluation, because of failed or disappearing student). This of course requires a merge request and the usual 2 weeks (min) delay. This could be very, very useful for tasks impacting the common code. It's more a feeling than a fact, as I mentioned I limit myself to engines.</span><br></div><div><span style="font-size:12.8px">When should it happen: I don't really understand the question. Maybe the answer is "following as much as possible the plans. Planning changes have to be discussed and agreed by the mentors and their student"... but again, I'm not sure I understand it the right way</span></div><div><span style="font-size:12.8px">Why is it done/done in this way: because it was validated in the student application form that way, with, again, possible changes if the student and the mentors judge it's useful</span><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I hope it helps...</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Best regards,</span></div><div><span style="font-size:12.8px">Arnaud</span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 18, 2018 at 9:43 PM, Colin Snover <span dir="ltr"><<a href="mailto:scummvm-devel@zetafleet.com" target="_blank">scummvm-devel@zetafleet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="m_-7907074736540144778moz-cite-prefix">Hi sev, Strangerke, criezy,<br>
<br>
Thanks for your ongoing feedback in helping me to understand how
the current process works, so that I can understand better how the
suggested changes differ from what is happening now. I think I
didn’t explain thoroughly what I was looking for with those
questions, so apologies for any confusion in that regard.<br>
<br>
bgK has proposed some specific items like “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”, and “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”. I’m
still struggling somewhat to understand how these proposals differ
from how things are today (if they even do differ at all), as the
information in the wiki is not so specific in its instruction.<br>
<br>
In general when doing information gathering like this I am always
looking for the Five Ws: Who is responsible, What should be done,
Where should it happen, When should it happen, Why is it done/done
in this way. Trying to discuss using personal assumptions on what
subjective terms like “comprehensive and detailed” or “polished”
mean usually ends up with people talking past one another or a
false understanding that everyone is on the same page when they
are not (and then someone ends up surprised/frustrated/upset later
when someone else says or does something that violates this
apparent agreement), so I am working to avoid this on my end.
Making sure the Five Ws are answered for all the information on
the wiki should also result in better applications from the start
and less work for the GSoC mentors overall, so I hope that
everyone can understand the value in this. (If not, please let me
know that too, since I don’t want to create work which nobody
finds value in.)<br>
<br>
Here is a hypothetical answer which is maybe more illustrative in
getting across what I’m looking for:<span class=""><br>
<br>
* What is the way in which work units are allocated?<br>
<br></span>
During the application process, GSoC applicants give links in
#scummvm or on scummvm-devel to their working proposals on Google
Docs, and the GSoC mentors give feedback to students on these
plans. When finished, the plans need to include a series of tasks
of no more than 8 hours per task, to ensure that the whole project
has been thought through in sufficient detail to reduce the risk
of large time overruns or failure. Here are some past examples of
excellent project plans that show what we aim for: <link>.<br>
<br>
At the start of the project, the tasks from these plans are added
as cards to Trello, since this keeps managing the work simple and
easy, and gives experience to students with real-world project
management tools. The student usually picks one or two cards in
Trello to work on at a time, and talks with their mentors/the team
on #scummvm or scummvm-devel whenever help is needed making a
decision on how to move forward or switch to something else.
Occasionally a mentor will give specific tasks to a student to
complete or ask them to switch to something else, but it is
usually expected that the student will self-manage this process.<br>
<br>
---<br>
<br>
I hope this makes sense, and thanks again for your patience with
my questions as I try to understand everything. I’ve run out of
time for any more feedback today on this topic, and, it does
continue to look like there are already some things which are
agreed on and just not fully written down, so I will try to note
those specifically when I’m next available.<br>
<br>
Best,<div><div class="h5"><br>
<br>
On 2018-01-17 12:08, Eugene Sandulenko wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div class="h5">
<div dir="ltr">OKAY. I'll do it.
<div class="gmail_extra"><br>
<div class="gmail_quote">On 17 January 2018 at 18:58, Colin
Snover <span dir="ltr"><<a href="mailto:scummvm-devel@zetafleet.com" target="_blank">scummvm-devel@zetafleet.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 bgcolor="#FFFFFF">
<div class="m_-7907074736540144778gmail-m_-5119148477050559137moz-cite-prefix">Unfortunately,
I still do not see the answers to the specific
questions I asked about the way ScummVM’s GSoC
operates. Those questions are again:<span class="m_-7907074736540144778gmail-"><br>
<br>
* What is the way in which work units are allocated?<br>
</span></div>
</div>
</blockquote>
<div><br>
</div>
<div><span style="color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">..prepare
a </span><b style="color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">comprehensive
and detailed plan for all 12 weeks of your project</b><span style="color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">.
Include risk mitigation (you might fall ill, a phase in
your project be more complicated than anticipated, etc.)
and any existing commitments such as exams, vacations
etc.</span>
<ul style="list-style-type:square;margin:0.3em 0px 0px 1.6em;padding:0px;color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">
<li style="margin-bottom:0.1em"><i>This plan will help
you and us to decide at any time during the project
how well you are progressing. It forces you to think
about what you need to do beforehand, and provides a
guideline for you while GSoC is progressing.</i></li>
</ul>
</div>
<div><br>
</div>
<div><span style="color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">Create
a timeline for the project</span>
<ul style="list-style-type:square;margin:0.3em 0px 0px 1.6em;padding:0px;color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">
<li style="margin-bottom:0.1em">Again, we don't expect
you to have a full-on, hour-by-hour break down.</li>
<li style="margin-bottom:0.1em">We assume that the
schedule <i>can</i> and <i>will</i> change as the
project goes on.</li>
<li style="margin-bottom:0.1em">That said, we want to
make sure everything can fit into the GSoC timeline
and that you think about how long things will take.</li>
</ul>
</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 bgcolor="#FFFFFF">
<div class="m_-7907074736540144778gmail-m_-5119148477050559137moz-cite-prefix"><span class="m_-7907074736540144778gmail-"> * How and where is the work progress
tracked?<br>
</span></div>
</div>
</blockquote>
<div><span style="color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">...
we ask you to </span><b style="color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">keep
a weblog</b><span style="color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px"> (BLOG)
with posts on a weekly or more frequent basis detailing
your progress and experiences with your project/GSoC.</span>
<ul style="list-style-type:square;margin:0.3em 0px 0px 1.6em;padding:0px;color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">
<li style="margin-bottom:0.1em"><i>This provides a
valuable avenue for feedback and helps involvement
of the wider community. It also helps you to sort
your thoughts and determine your own progress. Note
that the blogs will be aggregated onto <a rel="nofollow" class="m_-7907074736540144778external m_-7907074736540144778gmail-text" href="http://planet.scummvm.org/" style="color:rgb(90,54,150);background:url("http://wiki.scummvm.org/skins/ScummModern/scummmodern/external.png?8ea75") 100% 50% no-repeat;font-size:11px;padding:0px 13px 0px 0px" target="_blank">ScummVM's Planet
site</a> so language and tone should be set
accordingly.</i></li>
</ul>
<div><span style="color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">...
we expect you to </span><b style="color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">commit
early, commit often</b><span style="color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">.</span>
<ul style="list-style-type:square;margin:0.3em 0px 0px 1.6em;padding:0px;color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">
<li style="margin-bottom:0.1em"><i>We judge students'
code based on what is checked in and take the view
that 'if it's not checked in it does not exist'
for the purposes of GSoC reviews. Don't be shy
about this. You may feel your code is not 'good
enough', but the best way to learn whether it
actually is good or not, and also to get valuable
hints on how to improve it, is to show it to us.
Trust us, we will give you constructive feedback
and won't bash you for what you produce.</i></li>
</ul>
</div>
</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 bgcolor="#FFFFFF">
<div class="m_-7907074736540144778gmail-m_-5119148477050559137moz-cite-prefix"><span class="m_-7907074736540144778gmail-"> * 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>
</span></div>
</div>
</blockquote>
<div><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. </span><b style="color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">Failing
to do so for more than three days without arrangement
will cause you to be dropped from the program.</b><span style="color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px"></span>
<ul style="list-style-type:square;margin:0.3em 0px 0px 1.6em;padding:0px;color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">
<li style="margin-bottom:0.1em"><i>Consider that GSoC is
a full time obligation. If you don't show up on a
regular job for three days in a row, without any
prior notice or reporting in as ill, you also run a
high risk of being fired. Now, this is not exactly a
regular day job and you don't have to come into an
office every day. But communication is absolutely
essential to a successful GSoC project and
experience has shown that students that do not check
in with their mentors (and the wider community) tend
to struggle and produce weaker outputs. <span style="background-color:rgb(255,255,0)">In
particular, if you feel you are behind your
schedule or otherwise in troubles, talk to us as
soon as possible.</span> Do not hide from your
mentor -- they are here to help you at all times.
Finally, this obligation doesn't have to be a
burden, but rather should be a fun opportunity to
chat with a nice fellow coder about interesting
topics.</i></li>
</ul>
</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 bgcolor="#FFFFFF">
<div class="m_-7907074736540144778gmail-m_-5119148477050559137moz-cite-prefix"><span class="m_-7907074736540144778gmail-"> * Is there a set criteria for a task
to be considered completed successfully?<br>
</span></div>
</div>
</blockquote>
<div>
<ol style="margin:0.3em 0px 0px 3.2em;padding:0px;color:rgb(0,0,0);font-family:verdana,tahoma,arial,helvetica,sans-serif;font-size:12px">
<li style="margin-bottom:0.1em">
<ul style="list-style-type:square;margin:0.3em 0px 0px 1.6em;padding:0px">
<li style="margin-bottom:0.1em">Using the skelton, <span style="background-color:rgb(255,255,0)">create
Milestones</span> for the project. IE:
<ul style="margin:0.3em 0px 0px 1.6em;padding:0px">
<li style="margin-bottom:0.1em">The engine can
read .scr files</li>
<li style="margin-bottom:0.1em">Create API for
creating a hardware accelerated texture</li>
<li style="margin-bottom:0.1em">The engine can
move the character</li>
</ul>
</li>
<li style="margin-bottom:0.1em">This is makes sure
we all understand the complexities of the project</li>
</ul>
</li>
<li style="margin-bottom:0.1em">Create a timeline for
the project
<ul style="list-style-type:square;margin:0.3em 0px 0px 1.6em;padding:0px">
<li style="margin-bottom:0.1em">Again, we don't
expect you to have a full-on, hour-by-hour break
down.</li>
<li style="margin-bottom:0.1em">We assume that the
schedule <i>can</i> and <i>will</i> change as the
project goes on.</li>
<li style="margin-bottom:0.1em">That said, we want
to make sure everything can fit into the GSoC
timeline and that you think about how long things
will take.</li>
</ul>
</li>
</ol>
</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 bgcolor="#FFFFFF">
<div class="m_-7907074736540144778gmail-m_-5119148477050559137moz-cite-prefix"><span class="m_-7907074736540144778gmail-"> <br>
</span> Since I am still not seeing what you are
seeing, could you please help me and cut and paste the
specific text from the project rules which answers
each of these questions in a response to this email?<br>
</div>
</div>
</blockquote>
<div>I did that, hope it is clearer now.</div>
<div><br>
</div>
<div><br>
</div>
<div>Eugene</div>
</div>
</div>
</div>
<br>
<fieldset class="m_-7907074736540144778mimeAttachmentHeader"></fieldset>
<br>
</div></div><span class=""><pre>______________________________<wbr>_________________
Scummvm-devel mailing list
<a class="m_-7907074736540144778moz-txt-link-abbreviated" href="mailto:Scummvm-devel@lists.scummvm.org" target="_blank">Scummvm-devel@lists.scummvm.<wbr>org</a>
<a class="m_-7907074736540144778moz-txt-link-freetext" href="http://lists.scummvm.org/listinfo/scummvm-devel" target="_blank">http://lists.scummvm.org/<wbr>listinfo/scummvm-devel</a>
</pre>
</span></blockquote>
<p><br>
</p><span class="">
<pre class="m_-7907074736540144778moz-signature" cols="72">--
Colin Snover
<a class="m_-7907074736540144778moz-txt-link-freetext" href="https://zetafleet.com" target="_blank">https://zetafleet.com</a></pre>
</span></div>
<br>______________________________<wbr>_________________<br>
Scummvm-devel mailing list<br>
<a href="mailto:Scummvm-devel@lists.scummvm.org">Scummvm-devel@lists.scummvm.<wbr>org</a><br>
<a href="http://lists.scummvm.org/listinfo/scummvm-devel" rel="noreferrer" target="_blank">http://lists.scummvm.org/<wbr>listinfo/scummvm-devel</a><br>
<br></blockquote></div><br></div>