<div dir="ltr">Hi Colin,<div><br></div><div>concerning the answers to your questions:</div><div>- The student is required to prepare a schedule in their application. At this point of the process, it means we have been accepted by Google and that the available mentors have filtered the list of ideas to only propose the ones with at the very least a mentor (as we can find later a co-mentor, which is something we do systematically). The student may of course bring their own idea, but they have to convince someone to become a mentor for the task. As the application period is pretty long, there's a lot of time to ask question and challenge this planning. The student application is visible by all the mentors & org admins, and everybody is welcome to ask more details or challenge it.<br></div><div>- At the end of this period, we organize a vote, and check who confirms to be a mentor for this or that task, and we make sure there are 2 mentors per task. Based on that, we ask to google our low and high number of student slots. Once we have the number of slots, based on the votes and mentors available, we allocate the slots to students. After Google announces the results, the bounding period starts. We use this period to polish the schedule, ask for more details in analysis or plans, or if things are already fine we could suggest a student to start coding, which may be used later to let them finish earlier if they have exams, for example (that happens a lot with European students).</div><div>- During the coding period, students are required to discuss with their mentors at the very least every two days. I try to communicate at least 2 times per day, for example. For a non-engine task, I expect (at least) Eugene or Willem Jan to be involved, and it wouldn't be surprising that wider discussions occur on -devel, though if it had to happen during the coding period it would be a sign something wasn't prepared properly during the (very) long bonding period.</div><div>- As mentioned before, we have at this point a polished schedule and a student who is coding. we keep track of progress very regularly (maybe everyday? The student should be pushing daily anyway) so it's easy to talk to the student if there's an issue. As the GSoC lasts 3 months with 3 evaluations, we mostly have 3 weeks of coding for 1 week of polishing, filling papers, and stressing for the result to the point that coding is complicated. so, once per month, all the mentors discuss about passing/failing students. Usually, the last word is for the 2 "official" mentors of the student. one think verified is, of course, the quality of code and the velocity, and the respect of all the rules we set. Google insists that we should not (shall not?) pass a student if there's a doubt. We are slightly more tolerant than that ;) If we have the feeling that the student is behind schedule but is doing their best, we adapt the scope with them. This obviously means that ideally the student will have to stay after GSoC to finish the task, or that we decide to split the task into two, ... or that the mentors will work on the task to finish it themselves, if possible.</div><div><br></div><div>With the two periods of appraisal, the disappearing students who only waited for the 1rst or 2nd payment, the failed students, etc, we can't reasonably merge the code before the 2nd appraisal. After that 2nd appraisal, we try to merge as soon as possible. </div><div><br></div><div>Best regards,</div><div>Arnaud</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 17, 2018 at 5:34 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">
Thanks. Could you please tell me where exactly on that page you
linked are the answers to the specific questions that I asked? I do
not see any answers to what I asked about.<div><div class="h5"><br>
<div class="m_-5075782495454882916moz-cite-prefix"><br>
On 2018-01-17 01:22, Eugene Sandulenko wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On 17 January 2018 at 02:33, 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_-5075782495454882916gmail-m_3795263164766222316moz-cite-prefix">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?</div>
</div>
</blockquote>
<div><br>
</div>
<div>I highly recommend to read the current GSoC
documentation, especially for those who did not have a
chance to work in the program:</div>
<div><br>
</div>
<div> <a href="http://wiki.scummvm.org/index.php/Summer_of_Code" target="_blank">http://wiki.scummvm.org/<wbr>index.php/Summer_of_Code</a> </div>
<div><br>
</div>
<div><br>
</div>
<div>Eugene</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
</div></div><span class=""><pre class="m_-5075782495454882916moz-signature" cols="72">--
Colin Snover
<a class="m_-5075782495454882916moz-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>