Change Details

//Anybody please add bullet points by editing the task description!// Update https://www.mediawiki.org/wiki/Google_Code-in_2015 and https://www.mediawiki.org/wiki/Google_Code-in/Admins * How did our onboarding tasks work out? Nemo_bis wrote about the "Get on IRC task" that "60 task instances later, I think we proved that the IRC task is not so easy at all for the students. I think one third of them needed to resubmit their work after receiving additional instructions, or to have an extension, or abandoned the task."" * @AKlapper: Not many students claimed the "Triage some #testme bug reports", maybe that choice was too limited? * Ubuntu had a beginner task to set up a wiki user home page (and get used to wikitext editing?), should we have that too? * Document "beginner task" definition better for mentors? IMHO we have still seen mentors creating tasks as beginner which require setting up the complete development environment. ** Have dedicated beginner task to set up dev environment via Vagrant (and add successfully managing that task as a requirement to other non-beginner coding tasks?), but Vagrant docs might need better documentation for Windows platform? * Any ideas how to encourage having more tasks with more than one mentor? * Document better Recurring / cloneable task instances vs. creating separate tasks to allow students to claim more than one single instance? (cf. Nemo's "Make translatable another time" tasks) * better workflow for mentors creating tasks to tell admins they are ready to publish? Or is [[ https://www.mediawiki.org/wiki/Google_Code-in_2015 | "Either add a "[READY]" prefix to the task summary to let org admins know, or contact them explicitly." ]] sufficient? * TODO: Incorporate email "[GCI-mentors] Tips and Info for Mentors and Org Admins for these 2 weeks pre-GCI start" from Google on Fri, 20 Nov 2015 and others sent by Google * <tgr> Can we add all GCI students to the CI whitelist? https://gerrit.wikimedia.org/r/#/c/261322/ and make a note to do it at the beginning of the contest next year. Without that only a subset of the tests is run by jenkins and that can cause confusion. * Some tasks may actually not be beginner tasks and less attractive for GCi students (example: https://phabricator.wikimedia.org/T120366#1915886 ?) How to make it clearer to recognize for mentors?

== For WM org admins, etc: == * Find org admins from more than one timezone! * The CI whitelist caused confusion (and waste of time as the student had to wait for half a day due to timezone differences just so someone else can say "recheck"). Either need more documentation on how to run tests locally, or ideally add all students to the whitelist at the beginning. https://gerrit.wikimedia.org/r/#/c/261322/ Without adding, only a subset of the tests is run by jenkins and that can cause confusion. * The last two weeks, potentially be a bit "stricter" with prospect finalists to get more "quality". * Document that "test your patch before you submit it" is a strong requirement. In some cases it was pretty clear that the student had no idea what they were doing and code wouldn't even run, but submitted it for review nevertheless. ** Document "beginner task" definition better for mentors! IMHO we have still seen mentors creating tasks as beginner which require setting up the complete development environment. Some tasks may actually not be beginner tasks and less attractive for GCi students (example: https://phabricator.wikimedia.org/T120366#1915886 ?) * Document better Recurring / cloneable task instances vs. creating separate tasks to allow students to claim more than one single instance? (cf. Nemo's "Make translatable another time" tasks) * Better workflow for mentors creating tasks to tell admins they are ready to publish? Or is [[ https://www.mediawiki.org/wiki/Google_Code-in_2015 | "Either add a "[READY]" prefix to the task summary to let org admins know, or contact them explicitly." ]] sufficient? == Tasks and mentors == * Beginner tasks: ** Need a beginner task that relates to setting up a development environment / Vagrant. Set up a repository in Gerrit and have a beginner task that requires students to clone that repo, create a file named with their GCI username or something, commit the file to their local Git clone, and submit the patch for review? Might also help start making students test their patches themselves earlier. Maybe a beginner task of "set up vagrant, install this extension, make a screenshot" would help? *** Vagrant docs might need better documentation for Windows platform? ** "Get on IRC task" was helpful: "60 task instances later, I think we proved that the IRC task is not so easy at all for the students. I think one third of them needed to resubmit their work after receiving additional instructions, or to have an extension, or abandoned the task."" ** @AKlapper: Not many students claimed the "Triage some #testme bug reports", maybe that choice was too limited? ** Ubuntu had a beginner task to set up a wiki user home page (and get used to wikitext editing?), should we have that too? * How to encourage having more tasks with more than one mentor? == For Google (contest rules, GCI site): == * have something like an "org dashboard" where one can create tasks without assigning a mentor yet. That would open the possibility for a mentor to take over a task, which was already created, but not "claimed" by a mentor so far, or, co-mentor a task. == What else did we learn / realize? == * Part of GCI is "getting work/tasks done", part is "recruiting new contributors / community members" * We miss a "pipeline" how to direct students to further stuff (try GSoC if you are 17?) Point to local hackathons? / "GCI is missing a follow-up program for the best contributors. (Or maybe the MediaWiki/Wikimedia technical community is missing a non-time-limited mentorship system?)" Every year there are GCI participants with a "hire on sight" competence level and it would be great to keep them engaged. * Students sometimes still have no way to gauge the complexity / required skill level of a task, and making a task description perfect can be the enemy of good.

//Anybody please add bullet points by editing the task description!//== For WM org admins, etc: == Update https://www.mediawiki.org/wiki/Google_Code-in_2015 and https://www.mediawiki.org/wiki/Google_Code-in/Admins * How did our onboarding tasks work out? Nemo_bis wrote about the "Get on IRC task" that "60 task instances later, I think we proved that the IRC task is not so easy at all for the students. I think one third of them needed to resubmit their work after receiving additional instructions, or to have an extension, or abandoned the task."" * @AKlapper: Not many students claimed the "Triage some #testme bug reports", maybe that choice was too limited?* Find org admins from more than one timezone! * Ubuntu had a beginner task to set up a wiki user home page (and get used to wikitext editing?)The CI whitelist caused confusion (and waste of time as the student had to wait for half a day due to timezone differences just so someone else can say "recheck"). Either need more documentation on how to run tests locally, or ideally add all students to the whitelist at the beginning. https://gerrit.wikimedia.org/r/#/c/261322/ Without adding, should we haveonly a subset of the tests is run by jenkins and that too?can cause confusion. * Document "beginner task" definition better for mentors?* The last two weeks, IMHO we have still seen mentors creating tasks as beginner which require setting up the complete development environmentpotentially be a bit "stricter" with prospect finalists to get more "quality". ** Have dedicated beginner task to set up dev environment via Vagrant (and add successfully managing that task as a requirement to other non-beginner coding tasks?) Document that "test your patch before you submit it" is a strong requirement. In some cases it was pretty clear that the student had no idea what they were doing and code wouldn't even run, but Vagrant docs might need better documentation for Windows platform?submitted it for review nevertheless. * Any ideas how to encourage having more tasks with more than one mentor?* Document "beginner task" definition better for mentors! IMHO we have still seen mentors creating tasks as beginner which require setting up the complete development environment. Some tasks may actually not be beginner tasks and less attractive for GCi students (example: https://phabricator.wikimedia.org/T120366#1915886 ?) * Document better Recurring / cloneable task instances vs. creating separate tasks to allow students to claim more than one single instance? (cf. Nemo's "Make translatable another time" tasks) * b* Better workflow for mentors creating tasks to tell admins they are ready to publish? Or is [[ https://www.mediawiki.org/wiki/Google_Code-in_2015 | "Either add a "[READY]" prefix to the task summary to let org admins know, or contact them explicitly." ]] sufficient? == Tasks and mentors == * Beginner tasks: ** Need a beginner task that relates to setting up a development environment / Vagrant. Set up a repository in Gerrit and have a beginner task that requires students to clone that repo, create a file named with their GCI username or something, commit the file to their local Git clone, and submit the patch for review? Might also help start making students test their patches themselves earlier. Maybe a beginner task of "set up vagrant, install this extension, make a screenshot" would help? *** Vagrant docs might need better documentation for Windows platform? ** "Get on IRC task" was helpful: "60 task instances later, I think we proved that the IRC task is not so easy at all for the students. I think one third of them needed to resubmit their work after receiving additional instructions, or to have an extension, or abandoned the task."" ** @AKlapper: Not many students claimed the "Triage some #testme bug reports", maybe that choice was too limited? ** Ubuntu had a beginner task to set up a wiki user home page (and get used to wikitext editing?), should we have that too? * How to encourage having more tasks with more than one mentor? == For Google (contest rules, GCI site): == * have something like an "org dashboard" where one can create tasks without assigning a mentor yet. That would open the possibility for a mentor to take over a task, which was already created, but not "claimed" by a mentor so far, or, co-mentor a task. == What else did we learn / realize? == * TODO: Incorporate email "[GCI-mentors] Tips and Info for Mentors and Org Admins for these 2 weeks pre-GCI start" from Google on FriPart of GCI is "getting work/tasks done", 20 Nov 2015 and others sent by Googlepart is "recruiting new contributors / community members" * <tgr> Can we add all GCI students to the CI whitelist? https://gerrit.wikimedia.org/r/#/c/261322/ and make a note to do it at the beginning of the contest next year. Without that only a subset of the tests is run by jenkins and that can cause confusionWe miss a "pipeline" how to direct students to further stuff (try GSoC if you are 17?) Point to local hackathons? / "GCI is missing a follow-up program for the best contributors. (Or maybe the MediaWiki/Wikimedia technical community is missing a non-time-limited mentorship system?)" Every year there are GCI participants with a "hire on sight" competence level and it would be great to keep them engaged. * Some tasks may actually not be beginner tasks and less attractive for GCi students (example: https://phabricator.wikimedia.org/T120366#1915886 ?) How to make it clearer to recognize for mentors?tudents sometimes still have no way to gauge the complexity / required skill level of a task, and making a task description perfect can be the enemy of good.