Difference between revisions of "GSOC Mentoring Guide"
(Created page with "For potential mentors: students work remotely and will typically communicate with you electronically. Students are expected to be self-motivated and responsible for getting wo...") |
m |
||
| Line 14: | Line 14: | ||
*[http://en.flossmanuals.net/GSoCMentoring/ GSoC Mentoring Guide] | *[http://en.flossmanuals.net/GSoCMentoring/ GSoC Mentoring Guide] | ||
*[http://groups.google.com/group/google-summer-of-code-mentors-list GSoC Mentors-Only List] | *[http://groups.google.com/group/google-summer-of-code-mentors-list GSoC Mentors-Only List] | ||
| + | |||
| + | The following information comes from the [http://en.flossmanuals.net/GSoCMentoring/defining-a-project/ GSoC manual on what makes a good GSoC project]: | ||
| + | |||
| + | ===What makes a Good GSoC Project=== | ||
| + | There are many ways to define a good GSoC project—probably as many ways as there are student-mentor pairings. Here are just a few: | ||
| + | |||
| + | '''Low-hanging fruit:''' These projects require minimal familiarity with the codebase and basic technical knowledge. They are relatively short, with clear goals. | ||
| + | '''Risky/Exploratory:''' These projects push the scope boundaries of your development effort. They might require expertise in an area not covered by your current development team. They might take advantage of a new technology. There is a reasonable chance that the project might be less successful, but the potential rewards make it worth the attempt. | ||
| + | '''Fun/Peripheral:''' These projects might not be related to the current core development focus, but create new innovations and new perspective for your project. | ||
| + | '''Core development:''' These projects derive from the ongoing work from the core of your development team. The list of features and bugs is never-ending, and help is always welcome. | ||
| + | '''Infrastructure/Automation:''' These projects are the code that your organization uses to get its development work done; for example, projects that improve the automation of releases, regression tests and automated builds. This is a category in which a GSoC student can be really helpful, doing work that the development team has been putting off while they focus on core development. | ||
| + | |||
| + | ''source: [http://en.flossmanuals.net/GSoCMentoring/defining-a-project/ GSoC manual]'' | ||
| + | |||
| + | Prospective students are interested in "new" technologies and languages, such as iOS and Android apps, and fancy, flashy, web-based projects. | ||
| + | |||
| + | |||
| + | '''Project idea format''' | ||
| + | |||
| + | ===Name of the Project== | ||
| + | *Research Group | ||
| + | *Goal of the idea: describe the outcome of the project idea | ||
| + | *Brief description of the idea, including any relevant links, etc. | ||
| + | *Languages and skills: programming language(s) to be used, plus any other particular computer science skills needed | ||
| + | *Mentors: ''name + contact details of the lead mentor'', "name + contact details of backup mentor" | ||
Revision as of 22:07, 6 February 2015
For potential mentors: students work remotely and will typically communicate with you electronically. Students are expected to be self-motivated and responsible for getting work done. Your average time investment is about one-four hours per week.
When a student contacts you, please tell the student a bit about your project. Here's some questions you might want to answer:
- What software are you creating?
- Why is it interesting?
- Who uses it?
- What languages is it written in?
- How is it going to change the world?
Include any instructions or information about communicating, e.g. your time zone.
Resources and Guides
The following information comes from the GSoC manual on what makes a good GSoC project:
What makes a Good GSoC Project
There are many ways to define a good GSoC project—probably as many ways as there are student-mentor pairings. Here are just a few:
Low-hanging fruit: These projects require minimal familiarity with the codebase and basic technical knowledge. They are relatively short, with clear goals. Risky/Exploratory: These projects push the scope boundaries of your development effort. They might require expertise in an area not covered by your current development team. They might take advantage of a new technology. There is a reasonable chance that the project might be less successful, but the potential rewards make it worth the attempt. Fun/Peripheral: These projects might not be related to the current core development focus, but create new innovations and new perspective for your project. Core development: These projects derive from the ongoing work from the core of your development team. The list of features and bugs is never-ending, and help is always welcome. Infrastructure/Automation: These projects are the code that your organization uses to get its development work done; for example, projects that improve the automation of releases, regression tests and automated builds. This is a category in which a GSoC student can be really helpful, doing work that the development team has been putting off while they focus on core development.
source: GSoC manual
Prospective students are interested in "new" technologies and languages, such as iOS and Android apps, and fancy, flashy, web-based projects.
Project idea format
=Name of the Project
- Research Group
- Goal of the idea: describe the outcome of the project idea
- Brief description of the idea, including any relevant links, etc.
- Languages and skills: programming language(s) to be used, plus any other particular computer science skills needed
- Mentors: name + contact details of the lead mentor, "name + contact details of backup mentor"
