Google Code-In 2017

We're happy to see you here :-)
(come here often, we will update this page until the end of Code-In).

We've been accepted to Code-In 2017, along another 24 amazing organizations. Last year was fantastic by all possibly metrics and we're really excited about being invited again.

Most likely you came here so see what kind of tasks we have. Well, we cannot show you the actual list as they will be published in Code-in's website when the time comes, and it's important that no one has an unfair advantage, but we can tell you this:

- We value all categories. We will have tasks for developers (of course), web designers (our website could use a new theme, couldn't it), graphic designers (for example, a new logo is in order), documentation writers (tutorials are highly useful), project organizers (yes, getting everyone on the same page is not always trivial) and more. To sum it up, if you want to work, we will have tasks for you no matter what your interests or skills are.
- If you are looking for sample code tasks, check the currently open issues at GitHub. Most or all of them will become one or more tasks (depending on difficulty or amount of work required). This is probably true for most organizations so we aren't disclosing a big secret here.
- We have a slack channel in which everyone is welcome. You will find members of the core team, past Summer of Code students and mentors, past Code-In students including the winners, etc. Feel free to come talk to us. You can invite yourself from our support page.

A video of our two winners from Code-In 2016 talking at Google's offices in San Francisco about what they did:

Do you want to be one of the two students that visit California next year?

Useful resources (come here often, we will update as new resources are added).

Playground repository in GitHub
Use it to submit beginner tasks that use GitHub.

Playground wiki page
Use it to learn the basics of dokuwiki and to submit documentation tasks.

Designers welcome.
What to expect if you want to participate in Code-in as a designer.

As you probably know, tasks in Code-in have tags. We will try to have tags consistently so you that you easily find new tasks in areas that interest you. This list will be updated often, as we add new tasks. The following tasks are official as of now, meaning that tasks related to the following topics will have a correct tag for you to find them:

DVB: DVB is the subtitle format used in most of Europe these days for digital TV. It's bitmap based, which means that instead of the subtitles being “text” (as in a string of characters) they are an image. This has the advantage of being more powerful (they are not limited by a character set, for example) but the disadvantage that in order to get the text we need to use a OCR (optical recognition) library. In general, our DVB support is decent, thanks a lot of the work by last year winners in code-in and previous Summer of Code students, but it's still not perfect. There are a few corner cases and some weird crashes.

708: CEA-708 (previously called EIA-708) is the subtitle format in digital TV in North America and a few other countries. It's widely adopted now, even though due to legal regulations the old analog format (CEA-608) is still in use. We do support 708, but implementation is not yet perfect. There are a number of tasks about correcting this. All of them are high value and classified as hard.

Korean: If you're from Europe or America you're probably surprised that we want to support Korean. Well, it's not really about Korean, but rather about all languages, and Korean is one of the hard cases for which we have some samples that aren't working or aren't working perfectly. Possibly fixing all the issues with Korean means fixing most of the issues with everything else, too. So why to give it a try?

Bug: Quite self explaining. These are non-trivial (not necessarily hard, but not immediately obvious or they would have been fixed) issues reported in GitHub.

CI: We have our own custom Continuous Integration (CI) tool that helps us ensure that we don't break things when we add new code. It's a nice tool that tests changes against our video repository. As everything else, it's useful but not perfect, and we want to improve it.

Hardtask: High risk, high reward tasks. They are likely to take time and patience, however successfully completing these tasks give you a lots of points for the ultimate prize. By the way, we may say that a task is hard but we can be mistaken in our estimation, so don't take our word for it. Check it out, and decide for yourself.

Feature: Tasks with this tag are about implement something new, so usually they are also classified as hard.

Winning strategies
Definitely reading documents like this one up to the end is a good start.
If you've read Code-in rules you have probably figured out that, unless you are a rock star with lots of free time, the safest best is to pick one organization and focus on their tasks. This is because each organization gets to pick exactly two winners and whatever work you do for one organization doesn't count for any other. So spending your time in two orgs doesn't multiply your chances - it reduces them.
Blatant advertisement: Because each org chooses two winners regardless of the organization popularity, focusing on smaller orgs (like ours) also increases your chances of becoming a winner.
Whatever organization your choose, becoming a winner requires two things: a) Being in the top ten by number of tasks done for that organization, and b) Being chosen by the organization as a winner.
We cannot speak for other organizations, but we select our winners based on task value, not task count. For example, doing all the tasks from one of the big “task groups” (you can figure what are those by checking our tags) is very high value. Fixing a lot of bugs from our github issue tracker is also high value. Of course, those hard tasks have a gamble component, as it's possible you spend a lot of time of them but are unable to completely solve them.
Another thing that gives big points is collaboration with other developers. This includes other GCI participants. Everyone working on CCExtractor is part of the team, and we compete among each other for motivational purposes, to produce better code that benefits the project in the long run. GCI runs for a few weeks, but we're open all year round. So consider the GCI prizes a perk that comes with being part of an open source community rather than the final goal.

  • public/codein/welcome_2017.txt
  • Last modified: 2021/03/14 21:07
  • (external edit)