GSOC 2018 - overview

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
#1
Congratulations to our students for 2018! We got 9 slots this time out of 12 we were strongly considering, so there were some hard choices to make. There were also other great proposals we just couldn't dig up enough mentors for. Still I appreciate all the volunteers that allowed us to cover as much as possible :) For students not chosen who are still interested in working with us please read the related section below

Student/Mentor meetup next weekend

For the 9 students and all associated mentors I'd like to mark the coming weekend (April 28-29) for an initial meet-up and discussion, although I realize not everybody will be able to make it at the same time or at all. But please try to make an appearance on chat at some point during the weekend and reach out to each other within groups to start getting to know others and talk about your usual availability hours.

Each project should have a work thread here in this forum to post (at least) weekly updates in, will be given a target channel in Slack for weekly meetings, and should end up with a GitHub Project Board to track tasks. That's all somewhat flexible based on student/mentor preferences and not necessarily final yet. For instance if one group prefers meeting on Discord that's probably fine, same story for using a Trello board instead of a GitHub board.

The coming weekend is in part for figuring all that out and finalizing it. We should also start converting the proposals into smaller tasks for the project board. This is another chance to reassess scope and the order in which to implement what (but not to change the overall project)

GSOC - to break API or not to break API?

At the moment we're in a "free fire" API breaking period, as part of the development on engine v2.0.0. One hope was that we'd be able to finish before GSOC started, but the work period is now nearly upon us, and some students are likely to begin early.

Some projects may end up involving backwards-incompatible engine changes that would normally violate our API contract. Another reason for the coming weekend would be getting a better feel for which if any projects are likely to encounter that, and if so could we sort those changes out early and then release v2.0.0 mid-GSOC?

Note that API violations are at present limited to what's exposed in the engine as the "Modding API" - there are likely to be technical violations of API in a variety of modules, maybe especially Behaviors, but those aren't yet part of our "contract" and thus not subject to SemVer. We should still try to bump version numbers accordingly and be watchful for breaking code from other people, especially other student projects.

Other projects

If you were not chosen for a slot please don't feel bad - it is generally impossible to fit every promising student, and plenty don't learn about GSOC early enough to fully prepare the best possible proposal. We've started having a few students show up months in advance, becoming regular contributors before GSOC apps even open. It can be hard to compete against that in a few weeks, but many of you will have the option to try again next year. Whether it be with us or a different org it is never too early to get into open source development, most if not all orgs are happy to welcome you as regular contributors any time of year :)

Sometimes proposals are awesome but for whatever reason we can't fit one into a regular GSOC slot. In this case we sometimes consider if the proposal can still be used in some way. We probably won't have great mentor coverage, maybe the timeline can be spread out over a longer period of time to help that. Community projects instead of single-student projects is also a possibility, especially where multiple students applied for the same idea.

You do miss out on the official GSOC recognition (and stipend) which is hard to replace, but the learning can be much the same and ultimately far more useful. We do have our own org funds and can consider using some of those if it helps, but that gets tricky pretty quick, especially if multiple students are involved in the same effort. One thought has been to put together super swag packages instead of small stipends, as those can be given out more readily and feel more fair regardless of who did how much work.

If anybody is interested in still working with us in a semi-structured fashion like that please do let us know and we can talk about it :)

Edit: Oh and if any student would like feedback for why specifically a proposal was not chosen just ask. I have a rough idea for most proposals but may have to get other details from other mentors.
 
Last edited:

oniatus

Member
Contributor
Architecture
#2

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
#3
Some suggested guidelines for working the projects over the summer. Feedback and ideas appreciated. Thanks to @oniatus for writing up a bunch of notes on this topic earlier, some stuff is copy pasta :)

Ideally students should follow similar approaches, not so much because it is bad to diverge but it makes it easier to get an overview if the projects work about the same.

Due to varying schedules it is fine to reschedule or miss a thing once in a while so long as you give notice about the event, ideally before it happens, but of course life doesn't always give you a warning :)
  • Weekly meeting - every project should have a meeting with the student, main Bureaucrat (does the evals etc), and as many other mentors as can make the time. Expect to spend about an hour. Meeting via text in Slack is ideal but if enough participants favor voice that's fine too just make sure somebody summarizes it after. Time of week is entirely up to participants, the more that can make it the better
  • Project thread - every student should post a thread in this forum with an overview of their project, where to go for what, links to everything relevant, weekly meeting time, and so on. If you already have a thread elsewhere you can just ask to have it moved. You don't need to put every last detail in the thread, just link to whatever
    • Expect that this thread will be the future home of whatever functionality the project provides. It might later be moved to the module forum (if it primarily lives in a module) or engine/core forum as the discussion point for the feature.
  • Weekly report - each student should do a summary write-up once a week, ideally shortly (< 24 hours) before the weekly meeting in case somebody can make the meeting but needs a refresher first. See suggested template below. Minimally post that in your thread, but a better option can be to run your own blog then post a link to each new entry in your thread here (and probably also note it in your Slack channel)
    • Bonus: If you blog in some sort of markdown format we can easily embed in the blog at http://terasology.org (or perhaps more accurately get us a snippet we can embed with a link to the full thing) we'll love you forever since that makes it easier to keep work visible. We'll need to figure out more details on this
  • GitHub Project Board - for tracking specific tasks, good to review and update during the weekly meeting. Convert your proposal into specific tasks on this board, using it Kanban-style (move things further right in the lists as they near completion. See the Master of Oreon board for an example and ideally use the same columns. If you need one ask for somebody to create it and be sure it gets set to public under the board settings (module-centric projects go under the Terasology org, otherwise MovingBlocks org).
    • Favor small tasks. At the most have one card be one week's worth or work, but ideally cut the project into smaller pieces. You can use issues in the associated repos then assign them to the project. Avoid big, vague, or overly critical single items and be sure to describe them well enough so others can understand them at a glance.
    • Trello is comparable to a GitHub Project Board, more fully featured, but less visible and integrated with GitHub. Ideally keep a GitHub board up to date but if you find a Trello board useful to have as well with more details feel free to use one of those as well.
  • Commit often - the student should try to keep work in progress as visible as possible. Don't wait to submit PRs if there is enough work to be reviewed already, it doesn't have to necessarily compile, just keep it in a topic branch. Merge as often as realistically possible between chunks of working code and available test & review efforts.
  • Aim for play tests - we have a monthly scheduled play test on the first Saturday of every month. During GSOC this is an ideal time to share with the community (rather than just the mentors) how work is proceeding. If you can time it right get your latest stuff merged a few days before the play test so it is contained within the target Omega game zip.
    • May 5th - just 6 days away, more of another group meet-up and planning event
    • June 2nd
    • July 7th
    • August 4th - final check, by this point the project should be effectively done (deadline technically the 14th, can start submitting final stuff from the 6th) with just some polish, documentation, video showcase and/or tutorial stuff left :)
Avoid private discussions with any one mentor and use the board review meeting to make sure others are up to speed. If you end up talking in private too much it can be hard for other mentors to follow, increasing risk if one disappears.

Whomever is tagged as the main "Bureaucrat" on the project has the primary responsibility for making sure everything is going well, but won't necessarily be spending most the time on actual code. Delegate when possible! Reach out to "Consultant" mentors as needed. Main bureaucrat is also the default choice for the mentor who'll do the evaluations.

Suggested template for weekly report
  • What have you achieved in the last xxx?
  • What are you currently working on?
  • What problems are you currently facing?
  • Is anything blocking you from making progress?
  • List of PRs and opened/closed Issues
  • Something else (pictures of new content, code snippets, new wiki content, …)
A reporting blog might be based on the https://github.com/MovingBlocks/DevlogTemplate which was used by some students last year. The goal is to have all reports in a central place leading perhaps to some friendly competition between students (seeing that another student made progress and reported about it might motivate to match the effort).

Having visible blog updates also leads to a healthier looking community making it easier to attract more contributors including future students :)
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
#4
Okay, I've just finished a write-up on GSOC process structure from an org admin perspective that I hope will be useful, and have applied it to our shiny "new" roadmap and volunteer tracking Trello board (which isn't actually new, and has gone through several redesigns without really having been pushed hard before)

There is a GSOC 2018 column now with one card per project containing both an overview of each item as well as checklists to go through until final delivery and beyond. That is a way more feature rich version of the Slack post I used last year to help track GSOC, and I'm deleting the partially developed one from this year in favor of the Trello bits.

As for the overall roadmap and volunteering thing that is a story for another time, but by looking at the board you can probably get some ideas ...

Feedback appreciated, as always!

Today is/was the first official day of the 2018 work period, hooray! All 9 students look to be off to a good start, especially those who started early. @Iaron da Costa Araújo claimed the first "GSOC work period" checkmark since his weekly meeting is on Mondays :)

For mentors and students both: use this week to really finalize the initial state of the GitHub project board, and earn that last checkmark in the Pre-GSOC grouping. This doesn't lock you in to a rigid timeline for the summer, but is the final mutually agreed-on state as work starts. No plan survives contact with the enemy (usually time) and they'll all change as needed, but that's a fine and normal part of software development.

Other than @asie (API stability / scope reasons) I think all the projects are pretty close to their original proposals, but if anybody is unhappy with the way their board looks vs what they signed up for with their proposal please let us know! One GSOC concern is students feeling like they end up working on something vastly different from what they were comfortable with, but we'll only know if students speak up. To my knowledge this has never been the case with our org and I'd like to keep it that way :)

Happy coding all!