[Scummvm-devel] GSoC in 2018?

Colin Snover scummvm-devel at zetafleet.com
Thu Jan 18 21:43:14 CET 2018


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
> <mailto: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:
>           o The engine can read .scr files
>           o Create API for creating a hardware accelerated texture
>           o 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 list
> Scummvm-devel at lists.scummvm.org
> http://lists.scummvm.org/listinfo/scummvm-devel


-- 
Colin Snover
https://zetafleet.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20180118/19b79904/attachment.html>


More information about the Scummvm-devel mailing list