Difference between revisions of "Google Summer of Code 2017 Administrative"

Back to the main OSGeo Google Summer of Code 2017 @ OSGeo wiki page.
Visit our Google Summer of Code 2017 Ideas and our Google Summer of Code Recommendations for Students pages

This is the central page for OSGeo administrative information in Google Summer of Code 2017.

GSoC general information

Contacts

Would-be mentors and students: you are invited to sign up to the OSGeo SoC mailing list right away. The list is the central communication channel for mentors, students and administrators. It is used for general GSoC announcements, specific OSGeo announcements, and for clarification about the program. As soon as you subscribe it, you are encouraged to introduce yourself and your role. We look forward to hear from you!

To contact OSGeo's GSoC admin team directly:
- send an email to gsoc-admin@osgeo.org
- join the #osgeo-gsoc channel on irc.freenode.net (connect directly in your browser via webchat)

Margherita Di Leo acts as chair of the Admin team, which includes Florin-Daniel Cioloboc, Anne Ghisla, Helmut Kudrnovsky, Werner Macho, Jeff McKenna. Feel free to email us with any questions, we're here to help mentor the mentors as much as anything else!

Mentors

If you're interested in mentoring / supervising a student for one of the software participating this year under OSGeo's umbrella, please add your name, email, OSGeo/guest software and the projects you're interested in mentoring here:

Number	Name	Surname	Nickname (IRC)	email	Software community	Idea(s) you are available to mentor (please write down the title of the idea, not link to ideas page!)
1	Tom	Kralidis	tomkralidis	tomkralidis at gmail.com	pycsw	pycsw filter abstraction, Elasticsearch backend, admin HTTP API
2	Gabriele	Prestifilippo	gabry501	gabriele.prestifilippo at gmail com	ESA-NASA WebWorldWind	HeatMap Layer, Plug-in, Create Your Own
3	Vicky	Vergara	cvvergara	vicky at georepublic de	pgRouting	Develop new functionality into pgRouting
4	Daniel	Kastl	dkastl	daniel at georepublic de	pgRouting	Connect more boost functions to pgRouting
5	Rohith	Reddy	sankepallyrohithreddy	rohithreddy2219 at gmail com	pgRouting	Connect more boost functions to pgRouting
6	Patrick	Hogan	HamletAlive	patrick.hogan at nasa gov	ESA-NASA WebWorldWind	CitySmart Urban Infrastructure Management
7	Anna	Petrasova		kratochanna at gmail com	GRASS GIS	3D rendering, 3D viewer
8	Vaclav	Petras		wenzeslaus at gmail com	GRASS GIS	Jupyter Notebook, Benchmarking, Testing, ...
9	Jakub	Balhar		jakub at balhar net	ESA-NASA WebWorldWind	CitySmart Urban Infrastructure Management
10	Alexandre	Dubé		adube at mapgears com	OL3-Google-Maps	Develop new features in the OL3-Google-Maps library
11	Raphaël	Gagnon		rgagnon at mapgears com	OL3-Google-Maps	Develop new features in the OL3-Google-Maps library
12	Stefan	Steiniger		sstein at geo-uzh-ch	OpenTripPlanner	Extending OpenTripPlanner with Real Time Modelling Functions
13	Jorge	Rocha	Jgrocha	jgr@di.uminho.pt	QGIS	Improve QGIS style interoperability, by reading and writing cartographic styles from other projects.
14	Massimiliano	Cannata	maxi	massimiliano.cannata at gmail com	istSOS	Data analysis and statistical tools from sensor data
15	Milan	Antonovic	mantonovic	milan.antonovic at gmail com	istSOS	Upgrade and finalize the istSOS JavaScript Core Library
16	Martin	Landa		landa.martin at gmail com	GRASS GIS	GUI, rendering
17	Alexander	Bruy	alexbruy	alexander dot bruy at gmail dot com	QGIS	Processing Framework improvements
18	Barry	Rowlingson		b.rowlingson at gmail com	QGIS	R/QGIS Interface for Mapping
19	Maria Antonia	Brovelli		maria dot brovelli at polimi dot it	ESA-NASA WebWorldWind	CitySmart Urban Infrastructure Management
20	Jonas	Eberle		jonas dot eberle at gmx dot de	PyWPS	Publishing data to MapServer and pycsw, Process chaining capabilities, Web-based administration & process management
21	Joaquin	Del Cerro		jjdelcerro at gvsig dot org	gvSIG	Data model for visualizations in gvSIG
22	Alvaro	Anguix		aanguix at gvsig dot com	gvSIG	Data model for visualizations in gvSIG
23	Julia	Wagemann		wagemann dot julia at gmx dot de	QGIS / GRASS GIS	WCS 2.0 plugin for QGIS, Jupyter Notebook examples with QGIS / GRASS GIS
24	Tais	TaGri		tgrippa at ulb dot ac dot be	GRASS GIS	Additional GUI tools for image analysis (co-mentor for content)
25	Nadia	Chaer		nadiachaer at gmail dot com	gvSIG	Educational games addon for gvSIG Batoví/Educa
26	Francisco	Puga		fpuga at icarto dot es	gvSIG	Educational games addon for gvSIG Batoví/Educa
27	Sean	Barbeau		barbeau at cutr dot usf dot edu	OpenTripPlanner/OneBusAway	Bikeshare Information for Transportation Apps
27	Óg	Crudden		og dot crudden at gmail dot com	OpenTripPlanner/OneBusAway	Bikeshare Information for Transportation Apps
28	Aaron	Brethorst		aaron at brethorsting dot com	OpenTripPlanner/OneBusAway	Bikeshare Information for Transportation Apps
29	Adam	Steer		adam dot steer at anu dot edu dot au	QGIS / GRASS GIS	WCS 2.0 plugin for QGIS, Jupyter Notebook examples with QGIS / GRASS GIS
30	Luca	Delucchi		lucadeluge gmail com	GRASS GIS	SOS tool for GRASS GIS
31	Matteo	De Stefano		matteo dot destefano at nina dot no	GRASS GIS	SOS tool for GRASS GIS
32	Mario	Carrera		mcarrera at gvsig dot com	gvSIG	Data model for visualizations in gvSIG
33	Gérald	Fenoy		gerald dot fenoy at geolabs dot fr	ZOO-Project	SOS datastore for MapMint
34	Sittichai	Choosumrong		sittichai dot ocu at gmail dot com	ZOO-Project	SOS input for MapMint4ME

A Mentor's Responsibilities

Being a mentor can take anywhere from 2-10 hours a week of your time depending on the student (it really is in your best interest to take on the strongest students you can find). You must have the time to be responsive and an advocate for the student. No matter how cool the project is and how much your team needs the job done, if you can't commit to supporting it, experience shows that the best thing to do is not start it, i.e. even with the best of intentions don't set a student up to fail. Long story short, student projects simply can't go ahead without proper mentoring support.

Every student project will also have a backup mentor, this person should come from your dev community and should at minimum keep up to date with the student's weekly developments. Both mentors need to appoint themselves officially. The best way is if the student is well integrated into your development team from the start, it lessens the workload on you and betters the buy-in from the rest of the community once you're ready for the final code merge.

You must be available at some time during the evaluation periods. If you will be away during these time periods please arrange with the OSGeo org admins and your backup mentor so that one of us can fill in your answers for you. These are hard cutoffs -- evaluations must be filed within these dates. There are 3 evaluation periods this year where mentors are required to complete an evaluation of their student. After the first 4 weeks of coding, after 8 weeks of coding and then at the end (after 12 weeks of coding). The evaluation forms are shorter than previous years so they should take less time to complete.

Guides for mentors

The GSoC Mentoring Guide - A must. Do get all useful info and tips from many years of experience from GSoC mentors.
GNOME GSoC Mentoring HOWTO
An excellent summary of mentoring, from A. Jesse Jiryu Davis

Tips for mentors

This section is for collecting suggestions on best practices, from mentors to other mentors. If you have good / bad experiences in mentoring, please share here! Remember that this is a public page, respect the privacy of the people.

Good ideas

Test students before selection. Challenge them with small programming tasks or bug fixes. This will help them getting familiar with the dev environment well before GSoC starts, and helps mentors understand their capability. Think about coding tasks much earlier than the deadline, and connect the task to the idea in the ideas page, as tasks should reflect the skills required to develop a certain idea.
Time management tip: Try not to mentor more than one project per year. In any case, you can be primary mentor only for one project. Consider carefully the time that you can allocate on GSoC.
A former mentor reported: "In my experience, it's most effective to require an accepted pull request of developed code by end of summer and write the proposal in terms of getting there."
It is key getting to know the students before the project starts, in order to adapt the workload to their capabilities. In the proposal template, students are asked basic information about their background, studies and experience, but some mentors report that it can be good to get in touch via hangout or similar voip and make a sort of general interview, beside challenging them with a coding challenge.
If the student struggles during the GSoC, get in touch and try to understand what is wrong and try to adjust the objectives according to what is possible for the student to achieve.
It is often convenient to split the work into smaller tasks / clear deliverables. This way, it is easier to track the progress, both for student and mentors.
If the student doesn't feel oppressed with nearly impossible requests, (s)he is more likely to learn with a fresh mind and stick in the community after GSoC ends and perhaps become a mentor or somehow help out with the GSoC subsequently.
Talking in conferences does attract quality students to apply to GSoC
GSoC activities span during all year, beside the coding, it's advertising the program, attracting students, drafting ideas, cultivating mentor capacity, etc

Bad ideas

If you do not always meet the deadlines, and do not always read the emails, if you feel that you don't have time, even if you really want to see a certain GSoC idea developed, it is a bad idea to consider becoming a mentor. GSoC deadlines are hard deadlines. All GSoC instructions are given via email. We do not much care of having many projects developed, but we'd rather have less, quality, well mentored projects, and students cannot be abandoned halfway.
If you are the kind of person always whining about the rules, please abstain becoming a mentor. GSoC has many rules, and most of them are set by Google so there is no way to change them, at least for the current GSoC. In general, GSoC rules are set for a reason, that you may or may not know, so the simplest way is either to accept them as a matter of fact or not participating at all.
It is a bad idea not paying attention to confidential information. Proposals ranking, comments on students work and background are exchanged via email. You need always to pay attention to the confidentiality of the content when you forward bits of emails to someone else that was not in the receivers in the first place. Furthermore, even if you know beforehand the results of selection or student evaluation, you must pay attention not to break the news to the students before they are informed by Google.

Mentor Summit

Each year Google hosts the "Mentor Summit" event at their headquarters. The tentative date for this year is: October 13-15 2017. This year we are developing guidelines for who can represent OSGeo at the summit: see Google Summer of Code 2017 Mentor Summit

Learn more

Previous years SoC involvement: 2016 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2008

OSGeo GSoC wiki pages: 2016,2015,2014,2013,2012,2011,2010,2009,2008

OSGeo Applications: 2016,2015,2014,2013,2012,2011,2010,2009

@@ Line 1: / Line 1: @@
 <center>
-[[Image:GSoC2016Logo.jpg|400px|link=https://developers.google.com/open-source/gsoc/]] <font size="+3"> @ </font> [[Image:OSGeo_300_127_pixel.png|300px|link=http://www.osgeo.org]]
+[[Image:GSoC2016Logo.jpg|400px|link=https://developers.google.com/open-source/gsoc/]] <font size="+3"> @ </font> [[Image:Osgeo-logo.png|300px|link=http://www.osgeo.org]]
 </center>
@@ Line 23: / Line 23: @@
 ** join the #osgeo-gsoc channel on irc.freenode.net (connect directly in your browser via [https://webchat.freenode.net/?channels=osgeo-gsoc webchat])
-* [[User:Madi|Margherita Di Leo]] acts as chair of the Admin team, which includes [[User:Masterflorin|Florin-Daniel Cioloboc]], [[User:Aghisla|Anne Ghisla]], [[Helmut Kudrnovsky]], [[User:Macho|Werner Macho]], [[Jeff McKenna]], and Guillermo Pizarro. Feel free to email us with any questions, we're here to help mentor the mentors as much as anything else!
+* [[User:Madi|Margherita Di Leo]] acts as chair of the Admin team, which includes [[User:Masterflorin|Florin-Daniel Cioloboc]], [[User:Aghisla|Anne Ghisla]], [[Helmut Kudrnovsky]], [[User:Macho|Werner Macho]], [[Jeff McKenna]]. Feel free to email us with any questions, we're here to help mentor the mentors as much as anything else!
 <!-- Admins: please add your pictures here -->
@@ Line 355: / Line 355: @@
 === Good ideas ===
-* '''Test students before selection.''' Challenge them with small programming tasks or bug fixes. This will help them getting familiar with the dev environment well before GSoC starts, and helps mentors understand if they are capable. Think to a task much earlier to the timeline, and connect the task to the idea in the ideas page.
+* '''Test students before selection.''' Challenge them with small programming tasks or bug fixes. This will help them getting familiar with the dev environment well before GSoC starts, and helps mentors understand their capability. Think about coding tasks much earlier than the deadline, and connect the task to the idea in the ideas page, as tasks should reflect the skills required to develop a certain idea.
 * Time management tip: Try not to mentor more than one project per year. In any case, '''you can be primary mentor only for one project.''' Consider carefully the time that you can allocate on GSoC.
-* A earlier mentor reported: "In my experience, it's most effective to require an accepted pull request of developed code by end of summer and write the proposal in terms of getting there."
+* A former mentor reported: "In my experience, it's most effective to require an accepted pull request of developed code by end of summer and write the proposal in terms of getting there."
-* It is key '''getting to know the student before the project starts''', in order to adapt the workload to his/her capabilities. It can be good to get in touch via hangout and make a sort of general interview, beside challenging them with a code test.
+* It is key '''getting to know the students before the project starts''', in order to adapt the workload to their capabilities. In the proposal template, students are asked basic information about their background, studies and experience, but some mentors report that it can be good to get in touch via hangout or similar voip and make a sort of general interview, beside challenging them with a coding challenge.
-* If the student struggles during the gsoc, get in touch and try to understand what is wrong and try to '''adjust the objectives''' according to what is possible for the student to achieve.
+* If the student struggles during the GSoC, get in touch and try to understand what is wrong and try to '''adjust the objectives''' according to what is possible for the student to achieve.
-* It is often convenient to '''split the work into smaller tasks''' corresponding to clear deliverables. In this way, it is easier to track the progress, both for student and mentors.
+* It is often convenient to '''split the work into smaller tasks''' / clear deliverables. This way, it is easier to track the progress, both for student and mentors.
 * If the student doesn't feel oppressed with nearly impossible requests, (s)he is more likely to learn with a fresh mind and '''stick in the community''' after GSoC ends and perhaps become a mentor or somehow help out with the GSoC subsequently.
 * '''Talking in conferences''' does attract quality students to apply to GSoC
-* '''GSoC lasts all year long''', beside the coding, there is advertising the program, attracting students, drafting proposals, thinking about mentor capacity, etc
+* '''GSoC activities span during all year''', beside the coding, it's advertising the program, attracting students, drafting ideas, cultivating mentor capacity, etc
 * ...
 === Bad ideas ===
+* If you do not always '''meet the deadlines''', and do not always '''read the emails''', if you feel that you '''don't have time''', even if you really want to see a certain GSoC idea developed, it is a bad idea to consider becoming a mentor. GSoC deadlines are hard deadlines. All GSoC instructions are given via email. We do not much care of having many projects developed, but we'd rather have less, quality, well mentored projects, and '''students cannot be abandoned halfway'''.
+* If you are the kind of person always whining about the rules, please abstain becoming a mentor. '''GSoC has many rules''', and most of them are set by Google so there is no way to change them, at least for the current GSoC. In general, GSoC rules are set for a reason, that you may or may not know, so the simplest way is either to accept them as a matter of fact or not participating at all.
+* It is a bad idea not paying attention to '''confidential information'''. Proposals ranking, comments on students work and background are exchanged via email. You need always to pay attention to the confidentiality of the content when you forward bits of emails to someone else that was not in the receivers in the first place. Furthermore, even if you know beforehand the results of selection or student evaluation, you must pay attention '''not to break the news''' to the students before they are informed by Google.
 * ...
+== Mentor Summit ==
+Each year Google hosts the "Mentor Summit" event at their headquarters.  The tentative date for this year is: [https://groups.google.com/forum/#!msg/google-summer-of-code-mentors-list/OTwNTCujKDA/HuhFQQauAgAJ October 13-15 2017].  This year we are developing guidelines for who can represent OSGeo at the summit: see [[Google Summer of Code 2017 Mentor Summit]]
 == Learn more ==