[GSoC-mentors] How do I tell if my student should be failed?

Terri Oda terri at toybox.ca
Mon Jun 20 04:39:42 EDT 2016


Midterm reviews are opening this week!  Don't forget that PSF midterm 
reviews are due June 25th at 1900UTC (48h before the google deadline).

Assuming that the new system is much like the old, only one person can 
fill out the review, so if you need to discuss the students together 
before the reviews are written so everyone's feedback gets in, please do 
so now ASAP!

One of the biggest question that comes up at this time is "How do I tell 
if my student should be failed?"  While lots of students are doing fine 
at this stage, there are always a few students who are borderline, 
started late but are "trying really hard," hit problems because of 
unforseen architecture issues out of their control, etc.  It can be very 
hard to decide if a student should pass or fail when there's no grading 
rubric, and when failing them at midterms means they're out of the 
program for this year.

So here's a few things you should ask yourself while trying to decide:
1. Has the student produced any code?
2. Has the student been active?
3. Are you happy with their progress?
4. Do the mentors want to continue working with this student?

If the answer to any (or worse, many!) of these questions or no, you 
should strongly be considering failure as an option.

Hopefully you've all been having great experiences with your students 
and we won't fail too many at midterms, but please don't feel afraid to 
fail the students if that's the right choice for your organization!

More explanation about what you should be looking for in your answers below:

1. Has the student produced any code?

If your student has not published any code in a publicly accessible 
repository at this point, they MUST be failed.  I've heard all sorts of 
sob stories about university firewalls and failed hard drives and 99% of 
the time we find out later that the student just hasn't done the work. 
If they're having technical difficulties, have them email you a tarball 
and you can put it up for them, but also consider seriously if they're 
able to do the job with such technical issues.   It doesn't have to be 
great, mergable code, but there needs to be evidence of around 40h/week 
of work since the coding period started, with some flexibility for 
student exams or other schedule issues worked out in advance.  (Lying 
about schedule issues in the application is a valid reason for failure, 
if that's an issue.)

Public code is a requirement from Google this year.  You need to fail 
the student if no code is visible, no matter the reason.

2. Has the student been active?

Are you having regular meetings?  Does the student post to your mailing 
lists or otherwise communicate with developers and the community?  Have 
they been blogging?  Or are you getting a last-minute code dump right 
now?  Google is paying for a summer worth of 40hr weeks, not one week at 
the end of term, and if you're unhappy with your student's activity 
level, that is a valid reason for failure.

Incidentally, the following students haven't really been keeping up 
their blogs and should potentially be considered for failure unless 
their other work and activity has been exceptional:

Nelson Liu (scikit-learn) - last blog post 2 months ago
Pranjal Agrawal (MyHDL) - put in a last minute post today, 10 days
	after the last deadline
Sheikh Araf (coala) - Last blog post May 6
Yashu Seth (pgmpy) - Last blog post May 29
tmrts (ScrapingHub) - No blog posts, and I talked to him about that
	earlier this week.

And those are just the students who got caught by the auto-warn system, 
which would easily be evaded.  Please look at your students' blog posts 
and make sure they're happening.  They should have at least two at the 
moment, one before May 22nd (but after acceptances), and one before June 10.

Now, sometimes we knowingly let students start a bit late due to exams, 
so do feel free to take anything you discussed prior to acceptance into 
account, but you definitely need proof that they're working hard if they 
got a late start.

3. Are you happy with their progress?

Take a look at their original proposed timetable.  Have they 
accomplished what they planned to do?  Have they accomplished something 
reasonable for their skill level?

Students don't have to stick exactly to their original timetable, but 
they should be communicating with you regularly so that you can agree on 
any changes.  It's pretty common for students to bite off more than they 
can chew, so ask yourself mostly if you feel that they're still 
progressing, and if you're happy with how that's going.


4. Do the mentors want to continue working with this student?

Sometimes you have a student who's a good programmer but terrible at 
listening to the community and keeps producing code that doesn't fit 
with your project.  Sometimes you have a student who requires constant 
nagging to get anything done.  Sometimes you just have a bad personality 
fit.  Very rarely, the student is exhibiting sexist, racist, or 
otherwise problematic behaviour.  (Violating the Python Code of Conduct 
repeatedly or willfully is a valid reason for failure.)

If the answer to "Do I still want to work with this student?" is no, 
discuss with other mentors and your org admin.

There's two options here if the answer is no: If you feel like the 
student should continue but you aren't ready to, this is a good time to 
replace or supplement mentors.  It's fine to do this: sometimes a mentor 
is more busy than expected, the time zone difference proves to be 
problematic, there's a personality or communication clash that is 
frustrating both parties, but they might flourish with another mentor.

But if *no one* wants to work with the student, this may be a time to 
consider failing them.  While the students are very important, I also 
don't want mentors being pushed to the point of burnout.  If you're 
still having to spend time every week nagging your student or arguing 
about stuff that you don't feel you should argue about and you're 
exhausted, that's not necessarily a sign you need more mentoring time, 
that's a sign that the student isn't ready for this kind of independent 
work.


Still not sure?  Please feel free to email any or all of the org admins 
with questions about your student situation; we'd be happy to help.


  Terri



More information about the GSoC-mentors mailing list