Google Code In 2017 Lessons Learned

This is to document things that admins and mentors learned, for the benefit of future Code-In exercises.

OSGeo's Application document

 * record initial tasks in a shared Google spreadsheet and include a link to that document in the application; do not use a wiki, as those initial tasks have to be made private once OSGeo is accepted as a Code-in organization


 * cvvergara comments:
 * Set up a google spreadsheet that has the correct format for the bulk upload, because if a parameter is missing then the task wont be accepted.
 * For creating "similar tasks" (and so many) I created a spreadsheet where I had a kind of a database structure. (sorry is an ods not a google spreadsheet) and then I copy paste the results to the google spreadsheet

Uploading Tasks

 * recommend that teams upload a single task first, to check their syntax and csv formatting, before uploading multiple tasks in bulk


 * has several undocumented rules:
 * 200 character limit length
 * only 1 url is allowed
 * no commas


 * cvvergara comments:
 * When uploading so many tasks, the ones that were OK got uploaded, so to upload the few 3 or 4 tasks that had something wrong:
 * Duplicated the worksheet tab
 * Deleted from the duplicated tab the tasks that were OK and uploaded: when uploading the verbose shows the titles of the tasks, and they are processed in order, so was a matter of inspecting.
 * Fixed the few tasks that were with some error
 * Processed the bulk upload with the duplicated tab
 * Deleted the duplicated tab
 * Changed the project tab name adding a DONE as a reminder that those tasks were uploaded

Publishing Tasks

 * only Dashboard admins can publish tasks
 * tasks should be published (minimum of 75) at least the day before the contest starts
 * published tasks won't actually be seen publicly until contest kickoff

Abandoned Tasks

 * often kids are shy to ask for help and will just press 'Abandon Task' instead
 * mentors should respond in the task to ask "Can I help you with what you are stuck on?", as most times the student will then re-join the task
 * task activity (comments/attachments) remains in a task that was re-joined after abandoning
 * note that a task can be re-joined only if there are enough Instances available

Mentor Signup Form

 * include timezone in the Google form

Unknown Mentors
Be vigilant when receiving initial volunteers as mentors that are unknown, and request background on their OSGeo activity, and if they are new to the community, politely steer them to ways to contribute, and possibly join the contest next year. Sample reply to use:

''Thank you a lot for being available as a GCI mentor! OSGeo mentors need to be able to guide students. Hence mentors need to be experienced OSGeo contributors and need to know the community and "how things work". Could you please share some information which specific OSGeo projects you have contributed to and worked on so far? How would you describe your areas of expertise within OSGeo? Are there any public OSGeo contributions you could link to (for example your OSGeo wiki page or your Github activity)? This would help us to get a better idea. Thank you! And if you have not contributed to OSGeo yet, we encourage you to start contributing to OSGeo by checking out http://www.osgeo.org/content/faq/how_can_i_help_osgeo.html ! Thank you!''

Mentors withdrawal
Mentors can withdraw at any time, however they should be aware that this does create a problem. In fact, we need to know the mentor capacity before applying for GCI. Giving the availability and then withdrawing after we have been accepted as a mentor organization, or worse, disappearing in the middle of the contest, is not OK, as the team will have to cope with more requests than expected and will have to dedicate extra time to fulfill the gaps. We prefer not to apply to GCI if we don't have enough mentor capacity rather than stressing ourselves beyond our limits. So please, try to avoid to give your availability if you are undecided, and limit withdrawals to very urgent / important cases.

Student evaluation
Try not to discuss in a public channel

Submissions evaluation
Mentors should evaluate submissions within 24 hours, but 12 hours is recommended. After 36 hours the dashboard sens a message to admins to take over and evaluate immediately. This must not happen. It takes years for an organization to build trustability and only 36 hours for a mentor to destroy all the work done. So mentors if you plan to be offline, organize shifts and leave notes about your evaluations so that other can evaluate the same task with the same criteria that you used. E.g. create a private document and share it to your co-mentors and admins, on which keep track of the tasks that you review and the criteria that you use, so that, if needed, others can help sort out the queue using the same criteria that you have used.

Prevent cheating
Always ask students original material such as for example screenshots with their own computer with their name written in it, to prove that they actually performed the tasks ad didn't just rephrase and reuse material taken online.