The Google Code-In program is Google's "Winter Break" program for 13-18 year old pre-college students, and is geared towards much shorter projects than the Summer of Code program.
Like the Summer program, the primary goals are to teach students about open source development - working in a community, with the common tools, on real-world code - and not just getting free developer time.
The program pays students for completing between 3 and 15 tasks during the program period from November 22 to January 10, during which time many students will also have classes, exams, and holidays, so tasks should not be things that will take hundreds of hours of development work, nor require expert knowledge of the system/programming.
Google's guidelines are "The primary requirement for a new task is that it be specific. It helps if it's relatively small, but there's nothing wrong with challenging students with bigger tasks ;). The idea is to have tasks take students at most 2-4 days with 2-3 hrs of work a day, but obviously that will vary with student skills."
Google breaks down tasks into 8 categories, listed below with ideas from developers about tasks we could list in each of those categories. Before the program starts, we'll have to make these tasks well enough defined that a student can claim a task off the list and finish it, and when they're done it won't be available for other students - so while "Add driver options to the man page" works for brainstorming, the task list would specify which drivers to do this for (and may split different drivers into different tasks).
If you can mentor for an idea, please add your name next to it in parentheses. Your idea is unlikely to happen without a mentor. As noted above, projects will be small, completed in a few days, so it's not a major ongoing commitment. Multiple people can be listed for each task, to help provide coverage across different times during the holidays, so feel free to add your name to tasks that already have names.
Like the GSoC program, the X.Org task list may contain tasks for Mesa, DRI, Wayland, & xcb projects as well the core X.Org-hosted code base.
The X.Org love bugs may have some suitable work as well.
- Code: Tasks related to writing or refactoring code
Convert any remaining modules that still use K&R C to ANSI C (following safe ansification guidelines)
- Export KMS connector attributes via sysfs so they can be adjusted outside X
- Add support for randr output attributes to the gnome/kde display applets
- Add support for Xv attributes to the gnome/kde display applets
Convert instances of xcalloc/xalloc/xfree to calloc/malloc/free (TrevorWoerner)
- Documentation: Tasks related to creating/editing documents
- Add missing driver options to their man pages, for example:
Write man pages for the X Damage extension (AlanCoopersmith)
Make man pages for libSM out of the API spec, hopefully using XML includes to share text between both (AlanCoopersmith)
- Outreach: Tasks related to community management and outreach/marketing
- Quality Assurance: Tasks related to testing and ensuring code is of high quality
- Write test cases for Xserver unit tests or X Test Suite
Go through the list of bugs with patches attached and for each patch, check if it's already been applied, and if so, close the bug. Otherwise see if the patch still applies to a fresh git checkout - if not, and you can't figure out how to fix it, note that in the bug report. If it does apply & compile, submit to xorg-devel for review. Need to break into reasonable subsets, such as per module.
- Research: Tasks related to studying a problem and recommending solutions
- Training: Tasks related to helping others learn more
- Translation: Tasks related to localization
- User Interface: Tasks related to user experience research or user interface design and interaction