GSOC 2018 - done! Summary blog posted

[Cervator]

Edit: Summary blog post is up!

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.

 

[oniatus]

Projects overview

@asie "Developing an assortment of sandbox-friendly framework and content modules"
@dacharya64 "Extending “Light and Shadow” Gameplay and Functionality"
@Iaron da Costa Araújo "Event Recording Feature"
@Inei1 "Improving the Server Facade"
@jellysnake "Tower Defence Gameplay Template"
@l0ftyWhizZ "GooKeeper Implementation"
@Naman Tiwari "Renovation of MasterOfOreon"
@Sarthak Khandelwal "Multiple Worlds"
@Serj "Game / saved world / module preview image content"

 

[Cervator]

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
  • Set up a recurring calendar event when you have a target time. Send an extra invite to terasology@gmail.com to make the meeting show up on our forum's calendar tab.
• 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]

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!

 

[Cervator]

After a long productive time we're now nearing in on the end of GSOC - what a time is has been

All 9 projects have been doing well, with a few bumps and bruises here and there. Mentor activity has been problematic at times, unusually so this year. I've got more notes and theories on that, but suffice to say we fell short at times and on the behalf of the overall project I apologize to the affected students. That being said it does sound like all 9 students have had an eventful, educational, and productive summer

There'll be more to come on write-ups, follow-ups, and so on, but for now a few important things to cover:

• Monday August 6th is the start of the student evaluation period, with the even due August 14th. Critical note: this can only be submitted once - be sure it is complete and fits the requirements of Google before you submit. You are free (and encouraged!) to share your work review submission URL (final blog, final forum post, etc) with your mentors for review and confirmation before submitting.
• The last regular weekly meetings take place this week, however other than the Sunday (the 5th) students others will have done work since the previous meeting, and may even continue to do work until the 14th, although I think in the spirit of the program that'd mainly be final polish. I suggest aiming to make the next regularly scheduled update for finishing out any loose ends, or even keep going through August if you're staying active
• "Wait what there's more?" - well, that's up to you! Part of the idea of GSOC is to get excited about open source and continuing to contribute! It doesn't have to be with us but of course we'll love you forever if you do So if you don't want to stop even by the 14th nothing keeps you from continuing. Really, keep going! If August meetings help that then great
• One particular later meeting is the retrospective with student + mentors. That's an optional thing we like to do as an org and could be defaulted to the next regular occurrence of the weekly meeting after August 22nd, or any other time that's good. But it has to be after Aug 22nd. We want to know from both sides what seemed to work well and what needs improvements.
• Next play test is August 4th - ideal target for trying out the new stuff made through GSOC (although a few pieces might still be pending). I hope to see as many students and mentors there as possible, will go all weekend if there's interest. Any students wanting to prepare better testing notes for what to play with please do
• GSOC Mentor Summit is October 12-14th in Silicon Valley. We can send 3 mentors plus however many more make it on the wait list. We have the funds. I've also got a ticket for GitHub Universe which is right after on Oct 16-17 plus a code for $400 off another ticket - anybody else interested? We ideally need to figure this out over the next week or two
• Possible meet-up on October 15th between the two other events. Like the summit attendance I'm trying to organize this via Post in Slack please fill it in even if you can't make it so we have some data. Again we can fund this, although I'd expect we'd be limited to mentors already making it to the summit (unless anybody else is near enough to where showing up is easy - even non-mentors!)

Despite the bumps and bruises I believe it has been a good and productive summer. Lessons have been learned, on both sides. I would love to keep going and flow into GCI and GSOC next year, but will need to get some more feedback from the community on how we can keep up our energy. The meet-up idea is one way to encourage this, the one we did in January certainly raised some spirits there.

See you all on Saturday!

 

[Cervator]

Maybe final bump! Summary blog post is now up for what happened over the summer: https://terasology.org/2018/09/02/gsoc-2018-results.html

GSOC Mentor Summit is in about a month and a half and as a SURPRISE the GCI signup is less than a week away, starting a month early this year, ack! Haven't really started tracking potential volunteers and whether we should submit or not yet, but feel free to let me know somewhere if interested.

We haven't even done the retrospectives yet, but I've created a Doodle pollasking our students and mentors for available time to finish out 9 final project meetings. My goal there is something like the following:

• What went well and what could've gone better? Somewhat answered already via evals and such. Anything missed or still useful to discuss?
• What do you wish could have happened? Do we have it written down somewhere? If not, can we has? If another GSOC student were to work on your stuff next year what do you think they might spend their time doing?
• Is everything written down in the right places, or could it be please? Remaining board cards turned into issues in the right tracker etc
• Are you up for continuing work on something specific? Most are happy to contribute, GSOC or not, but actually committing to something (not necessarily a timeline, just something assigned we can follow up on later) is a whole other thing and hugely helpful
• How can we recruit others to help working on stuff in your area? Bribe family members, shower strangers with documentation, show your friends how cool it can be to contribute to open source ...
• Would you be up for writing a post-GSOC blog entry sometime over remainder of the year? This would be a look back on what's ready and being worked on, where more help could be useful, how to get started, how to use the very latest from the project, and so on

Since I'm trying to organize it I've picked times semi-randomly indicating my preference with "for sure" vs "if need be" (two clicks) over a wide range. If none of the times work please let me know. If a time is an hour or two off from a good time let me know and I can probably add it.