Introduction

This page aims to be a brainstroming page for the tasks list that will be presented to the Google Code-In. Tasks are divided into categories (5 in total), and each category should have at least 5 tasks. These are the categories:

Code: Tasks related to writing or refactoring code
Documentation/Training: Tasks related to creating/editing documents and helping others learn more
Outreach/research: Tasks related to community management, outreach/marketing, or studying problems and recommending solutions
Quality Assurance: Tasks related to testing and ensuring code is of high quality
User Interface: Tasks related to user experience research or user interface design and interaction

Here are some advices/recommendations to take in account before creating a task:

This is not just about code. We also need other tasks (likely even more than coding tasks)
A task should take a normal GNOME contributor about 2 hours (This is to give you some idea of how much work a task should be.)
We get to choose 2 grand-price winners among our best students. This means students are much more likely to stick with one org this time.
The students do not receive money for completed tasks (but a t-shirt).
Google expects mentors to respond on comments and to review contributions within 36 hours, also on weekends.

This year there are no translation tasks, so do not add them.

Yu can find a template for tasks in each category. Please fill it with the required information.

If you have any doubt or question about GCI, please contact with Daniel Mustieles

Many thanks for your collaboration!!

Tasks from previous years

To get some ideas and inspiration:

Tasks List

Code

Task description: Consists of:
- An initial sentence or two that describes what the task entails and why a student would want to spend their time on it (emphasize importance to project, transferable skills...).
- Several sentences/bullets that provide more detail into the task: What approach should students use? What level of detail are you looking for?
Expected results: For example a patch, document, wikipage, SVG graphics, etc.
Requirements: A small list of skill requirements. This helps the students know if they might be able to complete the task, for example e.g. Git, programming languages, jhbuild, potential guidelines (Tango, gnome-icon-theme, HIG) etc. Some links to relevant resources could also help, plus e.g. mentioning the IRC channel of your product etc.
Estimated Time: The deadline (maximum time in hours) how long you think the task will take to complete in total, bearing in mind factors mentioned in the guidelines.
Mentor's name and email address: The person who will feel responsible for the task, who will monitor student submissions and give the final sign-off. This should be either you or someone who you have talked to about taking this on. It's also helpful if you mention your IRC nickname and your timezone.

Documentation/Training

Task description: Consists of:
- An initial sentence or two that describes what the task entails and why a student would want to spend their time on it (emphasize importance to project, transferable skills...).
- Several sentences/bullets that provide more detail into the task: What approach should students use? What level of detail are you looking for?
Expected results: For example a patch, document, wikipage, SVG graphics, etc.
Requirements: A small list of skill requirements. This helps the students know if they might be able to complete the task, for example e.g. Git, programming languages, jhbuild, potential guidelines (Tango, gnome-icon-theme, HIG) etc. Some links to relevant resources could also help, plus e.g. mentioning the IRC channel of your product etc.
Estimated Time: The deadline (maximum time in hours) how long you think the task will take to complete in total, bearing in mind factors mentioned in the guidelines.
Mentor's name and email address: The person who will feel responsible for the task, who will monitor student submissions and give the final sign-off. This should be either you or someone who you have talked to about taking this on. It's also helpful if you mention your IRC nickname and your timezone.

Outreach/research

Task description: Consists of:
- An initial sentence or two that describes what the task entails and why a student would want to spend their time on it (emphasize importance to project, transferable skills...).
- Several sentences/bullets that provide more detail into the task: What approach should students use? What level of detail are you looking for?
Expected results: For example a patch, document, wikipage, SVG graphics, etc.
Requirements: A small list of skill requirements. This helps the students know if they might be able to complete the task, for example e.g. Git, programming languages, jhbuild, potential guidelines (Tango, gnome-icon-theme, HIG) etc. Some links to relevant resources could also help, plus e.g. mentioning the IRC channel of your product etc.
Estimated Time: The deadline (maximum time in hours) how long you think the task will take to complete in total, bearing in mind factors mentioned in the guidelines.
Mentor's name and email address: The person who will feel responsible for the task, who will monitor student submissions and give the final sign-off. This should be either you or someone who you have talked to about taking this on. It's also helpful if you mention your IRC nickname and your timezone.

Quality Assurance

Task description: Consists of:
- An initial sentence or two that describes what the task entails and why a student would want to spend their time on it (emphasize importance to project, transferable skills...).
- Several sentences/bullets that provide more detail into the task: What approach should students use? What level of detail are you looking for?
Expected results: For example a patch, document, wikipage, SVG graphics, etc.
Requirements: A small list of skill requirements. This helps the students know if they might be able to complete the task, for example e.g. Git, programming languages, jhbuild, potential guidelines (Tango, gnome-icon-theme, HIG) etc. Some links to relevant resources could also help, plus e.g. mentioning the IRC channel of your product etc.
Estimated Time: The deadline (maximum time in hours) how long you think the task will take to complete in total, bearing in mind factors mentioned in the guidelines.
Mentor's name and email address: The person who will feel responsible for the task, who will monitor student submissions and give the final sign-off. This should be either you or someone who you have talked to about taking this on. It's also helpful if you mention your IRC nickname and your timezone.

Triage 12 bug reports and provide a fix for one

Task description: GNOME receives lots of bug reports by users. Reading these reports and trying to improve their quality before a developer looks at them, and trying to reproduce the described problem is called "triaging". Triage twelve bug reports (maximum four of them with the severity "enhancement") and provide a fix for one of those twelve reports.
Expected results: Retesting twelve existing bug reports (they don't have to be recent ones, you can also triage old ones) and provide a fix in form of a tested, git-formatted patch for one of those reports. Good starting points to find bug reports are https://bugzilla.gnome.org/page.cgi?id=weekly-bug-summary.html or for a specific project with https://bugzilla.gnome.org/browse.cgi. Think for a moment which applications you are interested in, or which ones you have used already, as this could make it easier.
Requirements: You should have a recent version of GNOME (3.6) - if you don't have one, you could also use a live CD (see http://www.gnome.org/getting-gnome/). Read the triage guide at https://live.gnome.org/Bugsquad/TriageGuide. Knowledge of the Git code repository system (http://live.gnome.org/Git/Developers) and the buildtool jhbuild (http://developer.gnome.org/jhbuild/) is helpful in order to create a patch. You don't need to know specific programming languages as this depends on the application that you write the patch for (most applications in GNOME are written in C, Python, JavaScript, Vala). You can ask for help at any time on GNOME IRC (https://live.gnome.org/GnomeIrcChannels) in the #bugs channel for triaging-related questions, and in #gnome-love for code beginners. If you triage bug reports of a specific project, there might also be a project-specific IRC channel. Most people are not in front of their computers all of the time so please be patient on IRC: Just ask your question and wait (and don't ask whether you can ask). Mailing lists (https://mail.gnome.org/mailman/listinfo/) can be also helpful, but answers might take a little bit longer.
Estimated Time: 120 hours
Mentor's name and email address: AndreKlapper (https://live.gnome.org/AndreKlapper), European timezone

User Interface

Task description: Consists of:
- An initial sentence or two that describes what the task entails and why a student would want to spend their time on it (emphasize importance to project, transferable skills...).
- Several sentences/bullets that provide more detail into the task: What approach should students use? What level of detail are you looking for?
Expected results: For example a patch, document, wikipage, SVG graphics, etc.
Requirements: A small list of skill requirements. This helps the students know if they might be able to complete the task, for example e.g. Git, programming languages, jhbuild, potential guidelines (Tango, gnome-icon-theme, HIG) etc. Some links to relevant resources could also help, plus e.g. mentioning the IRC channel of your product etc.
Estimated Time: The deadline (maximum time in hours) how long you think the task will take to complete in total, bearing in mind factors mentioned in the guidelines.
Mentor's name and email address: The person who will feel responsible for the task, who will monitor student submissions and give the final sign-off. This should be either you or someone who you have talked to about taking this on. It's also helpful if you mention your IRC nickname and your timezone.