GCI 2018 - task preparation


Org Co-Founder & Project Lead
GSOC season is over! Which means it is time for GCI instead, with even less rest for the weary than last year as it got moved up a month this time, meaning it starts for students in about three weeks. Coincidentally that also means it will partially overlap with Hacktoberfestwhich starts tomorrow

For a quick summary: Google Code-In (GCI) is a Google program for high school-level students all over the world to complete small tasks for swag. As an open source org we make lots of tasks available and later on pick finalists for the nicest prizes. New this year is that we have to pick 6 (not 5) finalists from the top 20 (not 10) and the "User Interface" category was renamed to "Design" without much added detail about what that really could extend to :)

With the amount of new content work that came out of this year's GSOC we enter GCI with a huge amount of momentum, as those favoring buzzwords and phrases might put it. That was a big factor in the decision to apply, along with several very eager mentors I'm going to have to lean on to help make a ton of tasks now that we got picked again

We thus have particularly high task creating potential in the following areas:
  • Master of Oreon - new buildings, Oreon specialties, farms, tasks, research, food, attributes + effects, etc
  • GooKeeper - new creature types, more pens, vendor type booths (snack stands, bathrooms, etc), more utility items
  • GooeyDefence - new towers, new enemies
  • Light & Shadow - world features to liven up the battlefield, weapons, powerups, team features (auto-balancing, delayed start till teams are valid ..)
  • Server facade - more API features (likely to be more advanced tasks)
  • Recording & Replay (RR) - various recordings, like automating some of the test plans from the past (if so we should publish such tasks after test plan work)
  • KComputers - new peripherals, scripts that do interesting things (again likely to be advanced + requires running the game with the permissiveSecurity flag)
  • UI - review and offer constructive criticism for the new create game flow and the expanded game and module details, add more UX tweaks
Some of the easier ones we should add sections for at https://github.com/MovingBlocks/Terasology/wiki/GCI#content-focus-areas (first 3? R&R?)

Beyond GSOC there are some more areas that are frequently popular:
  • DestinationSol - all the things! Ship / module making lines and probably a bunch of individual tasks we can come up with
  • Traaaaaaaaaaaaaaaaaaaaains
  • StructureTemplates are all over the place including some task chains - but we need to check them for bugs around facing/rotations.
    • DynamicCities (new cultures) and GooeysQuests (new structure lines) are two important consumers of STs. DC has an outstanding issue with weird placing
  • World generation - classic task chain here. We should make sure its tutorial is accurate and clear
  • UI introductory stuff, like making throwaway UIs in the Sample module to start learning
  • Test plans - review and update existing, make new ones. Might be able to chain from here to the ModuleTestEnvironment and/or R&R
  • Adding documentation, both in wikis or via javadoc. Try out and enhance the tutorials
  • Making new plants like crops, bushes, fruit trees, etc
  • Enhance GooeyJr but only if we can prepare a good enough dev setup to test and merge in improvements
  • Adding new blocks that have some sort of functionality attached (FunnyBlocks had some good additions in past GCIs although we might need to be specific)
  • Find and report a bug might be plausible, likethis instance from a past year, but needs to be written really well to result in good (and non-dupe) bug reports
Unusually for this year I've got some bullet points that are probably not ideal task making areas:
  • Artwork. Yeah ... multiple reasons.
  • Crafting - we just don't have a unified vision or generic systems that are stable right now. Adding equipment etc is closely related (artwork and subjective/arbitrary)
  • Categorization or other "soft" and subjective tasks (hey there's artwork again) - this really requires a lengthier impression of the overall project first
  • Fixing code style issues or other things detected by scanners - often there are false positives or bad rules that can lead students astray
  • Translations - the stability of Weblate is in question and we need to improve the overall system (character set switching, translate prefab bits)
Making tasks

We're using an org-private Trello board for organizing tasks before entering them in the GCI site itself. Tasks can still be entered directly into the site just be sure any associated cards are moved to the processed side of the board. There are lots of task ideas in there already, along with the fields to consider here. Plenty of tasks from our two prior years (2016 and 2017) can be reused with a bit of review and tweaking. We have a public GCI wiki page with overview details we could probably improve further. I'm suggesting mentors commit to writing one task every x days so we can ideally launch with 100+ using a little repeater card trick in Trello.

You can contribute tasks without committing to mentor - just let me know so you can be added to the board. Of course anybody still willing to do full mentoring would be welcome to volunteer, so long as you can do so decently for one or more areas :)

Rather than specifically making GCI tasks anybody can also help by simply writing good issues on GitHub, especially those we can mark as First Good Issue items or Hacktoberfest items.

Reviewing tasks

After the GCI start date we will be swamped with students eager for work. For the first week or two extra effort and volunteers will be needed on chat, again that's something even non-mentors (and indeed even other students) can help with. If you have spare paid time off burning a hole in your pocket with no idea for what to use it on this period is such a candidate, I've done it myself ... ;)

For task review try to focus on the student making something available to prove that they've done the work covered in the task, or at least have taken advice to heart and made progress. If a task asks for a screenshot and outlines how to get one yet a task is submitted for review without then send it back immediately. The student can certainly ask for help if they're stuck, but make them earn actual task review time and approval - don't spend time on something if the student didn't. They're here to learn not just click buttons for t-shirts. We do have a decent amount of introductory material they should be able to spend some time on independently to learn the basics.

  • October 23rd: Students can start on tasks
  • December 12: Task deadline (give or take a day or two for sub-deadlines)
  • December 27th: Deadline to pick winners
  • January 7th: Results announced
Last edited: