| Re: [soc-dev] Fwd: GSoC 2017: Evaluations of your students are now open! |
Hi Mentors,Just a heads-up, student evaluations are due in 3 days! Please take a moment to fill out your student evaluations. The deadline is June 30th 16:00 UTC.For more information, please see the email below or email us anytime.Thank-you,Stephanie------------ Forwarded message ----------
From: Google Summer of Code <summerofcode-noreply@google.com >
Date: Mon, Jun 26, 2017 at 5:45 PM
Subject: GSoC 2017: Evaluations of your students are now open!
To: stephanie.swart@xxxxxxxxxxx
![Google Summer of Code]()
Hi Stephanie Swart,
First Evaluations
First evaluations are now open!
One mentor for each student project must complete an evaluation of their student before June 30th at 16:00 UTC. If you haven't done so already, go to your dashboard on the GSoC program site and complete your evaluation of your student before June 30th at 16:00 UTC. We encourage you to complete the evaluations ASAP so you don't forget to do it - it should take you less than 10 minutes to complete.
If your org misses an evaluation your org will lose $1100 of the mentor summit travel stipend and one less person will be able to attend the summit.
Org Admins -- we encourage you to verify all evaluations for your org's student projects are complete 48 hours before the deadline, giving you time to contact the mentors directly if they have outstanding evaluations. Org Admins can complete the evaluation if needed.
To fail or not to fail?
Every year we tell organizations and mentors to fail students who are not doing their work. Often people will want to give the student the benefit of the doubt that they will improve - this rarely happens. 12 years of experience has taught us if you are considering failing a student then you probably should.
Google Summer of Code requires students to write quality code for the open source organizations they are working with while meeting their scheduled milestones. Students should not receive a stipend for being good proposal writers and nice people. They must also produce quality code that lives up to the expectations of your community. If they don't they should be failed. Period.
In the evaluation there is a section where you can leave feedback directly for the student that they will see after the evaluation deadline passes. This is the place to say what they did well and also why you failed them (what they should have been doing - example: communicating with the mentor/community and meeting their scheduled milestones, etc.).
Failing students is expected and encouraged (when appropriate)
Each year, when Google admins are considering the Org Applications we look at the pass/fail status of an org's previous GSoC experience(s). We expect to see some failures from orgs who have participated several times. Orgs who never fail anyone makes us wonder if the they are being too lenient with their students. Failing a student can be a good thing for the student. It can teach them the importance of deadlines, responsibilities, and also not over-committing or overselling their skills. Many students have said they failed their first GSoC and then reapplied the next year and succeeded, because they learned from where they went wrong.When deciding whether to pass or fail your student you should be considering the actual code produced and their involvement in the community. It is your responsibility to your organization, to all of the other students participating in GSoC, to yourself, and to Google, to evaluate the student on the quality of their code contributions they have produced during these first 4 weeks of the program. Things happen and students get sick or have other issues pop up that don't allow them to work as much on GSoC as they planned. This happens. But just like with a job, if you don't do your work and meet the requirements of your job you are let go. Students that aren't meeting their deadlines and producing quality code should be failed.
The mentors list has had several productive discussions about whether failing is appropriate in certain circumstances. You can find them in the archive.
Only 1 mentor can submit an evaluation for a student. If there are multiple mentors for a single student project you should decide in advance which mentor will complete the evaluation.
Important Dates
June 30th 16:00 UTC: First Evaluation Deadline (for both mentors and students)
July 24-28: Second Evaluation (for both mentors and students)
August 1: Deadline for designated finance person from Org to complete Payoneer registrationIf you have any questions please contact us at gsoc-support@xxxxxxxxxx
Thanks!
Google Summer of Code team
This email was sent to stephanie.swart@xxxxxxxxxxx.
You are receiving this email because of your participation in Google Summer of Code 2017.
https://summerofcode.withgoogle.com To leave the program and stop receiving all emails, you can go to your profile and request deletion of your program profile.
For any questions, please contact gsoc-support@xxxxxxxxxx. Replies to this message go to an unmonitored mailbox.
© 2017 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA
Project Coordinator- Memberships and Open Source Projects
Eclipse Foundation--Stephanie Swart
Project Coordinator- Memberships and Open Source Projects
Eclipse Foundation
_______________________________________________
soc-dev mailing list
soc-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/soc-dev
-- Dr. Jonas Helming Senior Software Architect / General Manager EclipseSource Munich Email: jhelming@xxxxxxxxxxxxxxxxx Web: http://eclipsesource.com/munich Phone: +49 89 21 555 30 - 11 Mobile: +49 170 31 51 698 Fax: +49 89 21 555 30 - 19 Skype: jonas.helming EclipseSource München GmbH Agnes-Pockels-Bogen 1 80992 München General Managers: Dr. Jonas Helming, Dr. Maximilian Kögel Registered Office: Agnes-Pockels-Bogen 1, 80992 München, Commercial Register München, HRB 191789