Perlyglot Mentors Guide
This is TPFs guide for people that want to mentor a project in the Perl / Raku ecosystem. It is important to understand the responsibilities becoming a mentor brings about. Google has some excellent documentation about GSoC in general and specifically for mentors.
Adding ideas
To add project ideas create a pull request for this repository. Just
copy the project idea template into the perl
or raku directory (or create a new one if it does not fit exactly in
any of them) and fill it out. Use a separate file for each project
idea. Please also add your project idea to the Project ideas list
above, itemized. If you have an idea but no mentor or the idea is not
entirely fleshed out, add it to
the incomplete-ideas.md file instead and try to
complete it. Ideas without a mentor or otherwise not fleshed out will
have to be removed before this list is submitted to Google.
Project ideas need to meet certain criteria described on this Google page. When you use the template you should be good to go. If you have an idea and want to discuss it before adding anything, discuss it here or add a new issue.
Becoming a mentor
You can volunteer to become a mentor without having a specific idea or project that you suggested. But please make sure you understand what it means to be a mentor. To list yourself as available for mentoring, just add your name to mentors-list.md.
Backup mentors
It would be wise, given the number of slots we might be assigned and the difficulty of consistency in being a mentor, that we have the luxury of giving each student two mentors to reduce the load. This will also provide the student with more feedback and to be able to detect problems early.
However, each project can only have one assigned mentor. I’ll refer to that mentor as the “primary mentor”. The second mentor is the “backup mentor”.
Backup mentors are, of course, free to get involved into the mentoring process as much as they like. However, the minimum a backup mentor has to do will be monitoring the status of the project as well as the communication between the primary mentor and the student, as described later on in “Keep in touch with the student”.
Primary mentors and backup mentors should get in touch with each other well before the coding period starts and discuss how exactly they plan to handle the mentoring tasks.
Make sure your student is ready to start working before he has to
After the participating students have been announced go and talk to your students and help sort out possible problems they might have getting started on their projects.
Some of the projects require some prelimary work to be done. For others the student might still have to familiarise themselves with the version control system being used, the coding style their expected to use, and similar things. Make sure that happens - help out as necessary.
If you’ve not already done so, work with the student to ensure that the schedule for the first few weeks of the project is agreed on..
Keep in touch with the student
In order to avoid surprises, it’s necessary to keep track of what exactly the student is up to. For that, students will be required to send weekly progress reports to their mentors as well as the mailing list used this year. This method allows all mentors and interested parties to keep track of progress and keep us all on track.
Keep track of those progress reports. If possible, provide the student with feedback on their report. That includes correcting a wrong path the student might have chosen, providing feedback for the code written that week, as well as setting your expectations for next week.
Try to figure out what problems the student is faced with and provide guidance. Don’t assume the student will always proactively ask for help.
If the student fails to provide their report in a timely fashion without giving prior notice with a good reason, find out why and also drop the organisation mentors (orgas) an email.
If a mentor fails to provide feedback on the student’s report, the backup mentor should be filling in to prevent the student from being blocked from doing further work. If this happens, or if there’s any other communication problem observed by any mentor, we’d also appreciate being notified by email so we can work out a plan to fix things.
Maintain a schedule
The students have already provided a project schedule with their applications. Use that as a basis and maintain it throughout the summer, amending it based on the progress of your student. Any changes to the schedule should be made in agreement with the student. Make sure the student always has an up-to-date copy of the schedule.
This is particularly important because the completion of the schedule is an essential criterion for student evaluation, both mid-term and at the end of the summer.
Evaluate the student
The student being paid entirely depends on their mentor’s evaluations. You’ll have to submit two of those to Google - a mid-term evaluation, due on June 27, and a final evaluation, due on August 22. In those evaluations you’ll have to answer a couple of questions about the student’s work and your interaction with them, as well as give them either ‘pass’ or ‘fail’ as a grade. When failed, the summer of code is over for the student.
Only the primary mentor is able to fill out evaluations.
The grades in the evaluations should never be a surprise to the student. Based on the weekly feedback to their progress report as well as the current progress on their schedule, the student should already have a good idea on where they stands. It’s the mentor’s job to make sure they have that understanding. Additionally, if things aren’t going well, be sure to get in touch with your backup mentor and orgas early on, so we can try to come up with a plan for rescuing the project without failing it.
If in doubt as to whether to pass or fail your student, err on the side of failing. A project that has got badly off track tends to be very hard to rescue. It’s often better to cut your losses than to prolong suffering on both the mentor and the student-side.
Mentor Summit Google will not allow any mentor who misses an evaluation deadline to attend the mentor summit. Also, any org that misses two or more evaluation deadlines (for the midterm, final, or midterm and final combined) will be uninvited from the mentor summit entirely. Evaluations are incredibly important to the program, so please keep the deadlines in mind.
Suggestions Avoid to miss deadlines, for whose that uses regularly Google Calendar, I suggest to import the GSoC calendar (there is a “+” button on the bottom-right corner)