[Scummvm-devel] GSoC in 2018?
Arnaud Boutonné
strangerke at scummvm.org
Fri Jan 19 00:32:42 CET 2018
Well, I think you're going a bit too far in the details.
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).
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.
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 :)
The way we work has been refined year after year with the following
objectives:
- Ensure the student may have feedback as fast as possible (thus 2 mentors,
which covers also the "disappearing mentor" point required by Google)
- 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)
- Ensure we have something at the end (which also covers a point about code
usefulness in Google's Application form)
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.
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.
After that
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.
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.
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.
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
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
I hope it helps...
Best regards,
Arnaud
On Thu, Jan 18, 2018 at 9:43 PM, Colin Snover <scummvm-devel at zetafleet.com>
wrote:
> Hi sev, Strangerke, criezy,
>
> 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.
>
> 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.
>
> 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.)
>
> Here is a hypothetical answer which is maybe more illustrative in getting
> across what I’m looking for:
>
> * What is the way in which work units are allocated?
>
> 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>.
>
> 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.
>
> ---
>
> 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.
>
> Best,
>
>
> On 2018-01-17 12:08, Eugene Sandulenko wrote:
>
> OKAY. I'll do it.
>
> On 17 January 2018 at 18:58, Colin Snover <scummvm-devel at zetafleet.com>
> wrote:
>
>> 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:
>>
>> * What is the way in which work units are allocated?
>>
>
> ..prepare a *comprehensive and detailed plan for all 12 weeks of your
> project*. 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.
>
> - *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.*
>
>
> Create a timeline for the project
>
> - Again, we don't expect you to have a full-on, hour-by-hour break
> down.
> - We assume that the schedule *can* and *will* change as the project
> goes on.
> - That said, we want to make sure everything can fit into the GSoC
> timeline and that you think about how long things will take.
>
>
>
>> * How and where is the work progress tracked?
>>
> ... we ask you to *keep a weblog* (BLOG) with posts on a weekly or more
> frequent basis detailing your progress and experiences with your
> project/GSoC.
>
> - *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 ScummVM's Planet site <http://planet.scummvm.org/> so language and
> tone should be set accordingly.*
>
> ... we expect you to *commit early, commit often*.
>
> - *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.*
>
>
>
>
>> * 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?
>>
> ... we require you to *communicate with your mentor* every second day. *Failing
> to do so for more than three days without arrangement will cause you to be
> dropped from the program.*
>
> - *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. In particular, if you feel you are behind your schedule or
> otherwise in troubles, talk to us as soon as possible. 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.*
>
>
>
>
>> * Is there a set criteria for a task to be considered completed
>> successfully?
>>
>
> 1.
> - Using the skelton, create Milestones for the project. IE:
> - The engine can read .scr files
> - Create API for creating a hardware accelerated texture
> - The engine can move the character
> - This is makes sure we all understand the complexities of the
> project
> 2. Create a timeline for the project
> - Again, we don't expect you to have a full-on, hour-by-hour break
> down.
> - We assume that the schedule *can* and *will* change as the
> project goes on.
> - That said, we want to make sure everything can fit into the GSoC
> timeline and that you think about how long things will take.
>
>
>
>
>>
>> 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?
>>
> I did that, hope it is clearer now.
>
>
> Eugene
>
>
> _______________________________________________
> Scummvm-devel mailing listScummvm-devel at lists.scummvm.orghttp://lists.scummvm.org/listinfo/scummvm-devel
>
>
> --
> Colin Snoverhttps://zetafleet.com
>
>
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.scummvm.org
> http://lists.scummvm.org/listinfo/scummvm-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20180119/0eba73e4/attachment-0001.html>
More information about the Scummvm-devel
mailing list