Guidelines

• The goal of GHOP 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." You only have 102 slots available, so ensure that they're put against specific goals that you as a project require.
• For coding tasks, it's safe to assume some level of HTML/CSS/JS/PHP knowledge. But remember that most of the students probably have not heard of Plone, or if they have, they're probably not familiar with its underlying APIs. So make sure to allow enough time for them to come up to speed (with help) and still get the task done.
• 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 documentation (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 title

A short description of what the task entails.

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?

• A sentence about what the expected deliverable is (a tutorial reviewed by at least one member of the documentation team and posted to the handbook, a patch in the core issue queue marked ready to be committed...)

Resources

Bulleted list of resources specific to the task. This includes handbook pages, off-site resources, IRC channels, related forums on plone.org, etc.

Estimated time

A "day" range of how long you think the task will take to complete, bearing in mind factors mentioned in the guidelines. Put this in the labels section of the task.

Primary contact

The person we should list as the "owner" of the task, who will monitor student submissions and give the final sign-off. This should be either you or someone who you've talked to about taking this on.

Good task examples

• Produce a set of realistic JMeter performance test plans — Setting up a testing suite is not Plone-specific, so this task has value for the student even after the project is over.
• Create a new theme for Plone — this is a highly valuable contribution to the project, and doesn't even require design skills, since they are porting an existing theme. Has pretty thorough existing documentation — and CSS skills are valuable in any project, so it gives the student great value too.
• Merge documentation issue tracker into main issue tracker — High-value, low threshold task with detailed instructions on how to do it.

"Less good" task examples

• Rewrite the Publisher machinery — obviously much too complex for someone new to Plone, and assumes too much prior knowledge.
• Fix five pieces of documentation — too broad and unspecified, instead locate documents where it would make a huge difference if somebody improved it.
• Create a blog product — there's already enough of this type of projects. ;)