Contents
Quick How To
Steps to propose a new task for GCI when GNOME has been accepted:
Read this whole page first.
Go to Google's ticket system and add a new task. (If you need mentor status first, check this section in our wiki.)
- Wait for an administrator to review and accept your task.
- You're done!
Guidelines
The goal of GCI is to get students interested and involved in open source, not to get free child labour.
The tasks should reflect that. Try and form your tasks around ideas that are fun, interesting, of high importance for the project, and/or would look great on a college application. - Each task should take a student approx. 2-5 days to complete, in between normal school work. If you have a great task idea, but it's going to take longer than that, consider turning it into a research task which can then be handed off to the larger community for execution.
- Tasks don't need to be limited to coding! Tasks can be pretty much anything, including QA, marketing, design, usability, documentation, research...
- Avoid "wildcard" tasks like "go fix any bug in the queue." Ensure that they're put against specific goals that you as a project require.
- For coding tasks, remember that most of the students probably have not heard of GNOME, or if they have, they're probably not familiar with the underlying APIs. So make sure to allow enough time for them to come up to speed (with help) and still get the task done.
For UI tasks like new icons, please mention that icons must respect the Tango specification. Mention that the student is encouraged to first attach some sketches of icon ideas.
Each task needs to make it clear exactly what you're looking for, which includes a detailed description of what the work entails and a clearly-defined deliverable. It also should include references to existing documentation specific to the task, unless this information is already covered in the Wiki (coding standards, etc). This helps students not waste time spinning their wheels looking for information, and helps ensure their efforts meet your expectations, leading to a more positive experience all around.
Task template
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.
Difficulty: (easy, medium, hard)
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.
Bad task examples
- not do-able within the time-frame
- "personal" itch to scratch that doesn't have a lot of impact in the project overall.
- no required skills or helpful resources described and/or linked
- this task has already been done by the community
Potential description snippets for specific task categories to consider for future tasks
Translation
LimeSurvey uses this snippet for their translation tasks: "Do not use automated machine translation because that is cheating and usually of bad quality. We will check your translation. If we find out that you cheated by using machine translation we will make sure that you will be disqualified for the contest."
Adding the following comments is recommended:
- Translating is easier with specialised tools, such as gtranslator, poEdit, Virtaal, or Lokalize.
- A spelling check is always a good idea.
- User interface translations can and should be taken from the corresponding UI .po file.
- Provide some style guidelines and a list of common mistakes as required reading. Fixing such subtle problems afterwards can be time consuming. Inexperienced translators tend to translate word-for-word, forgetting that grammar and phrasing differ between English and the target language. Before being given a full task, the participant should translate a small test file with common pitfalls, and the mentor should give detailed feedback. Simply making pupils aware of the issues increases their performance significantly.
Tasks from previous years
To get some ideas and inspiration: