- Wrap up mentor feedback from T154374;
- go through (beginner?) tasks and/or documents (workflows) of other organizations to get some ideas what we can improve;
- identify those cloneable tasks that we could easily have again next year and how to identify those tasks earlier;
- think about a concept how to have "more advanced/challenging" tasks towards the end of the contest instead of remaining only with good first task tasks;
- maybe have mentors providing feedback about students already earlier than only at the end (decision on winners);
|Resolved||Aklapper||T154620 Summarize and document Lessons Learned from GCI 2016|
|Resolved||Aklapper||T154374 Gather feedback from GCI mentors after GCI 2016 (around 2017-01-14 to 2017-01-18)|
- Mentioned In
- T154374: Gather feedback from GCI mentors after GCI 2016 (around 2017-01-14 to 2017-01-18)
T144273: Organize and coordinate Wikimedia's participation in Google Code-In 2016
- Mentioned Here
- T149564: Better recommending of tasks suitable for new technical contributors
T154198: Get rid of support for IE8 and earlier for DuskToDawn
T154201: Get rid of support for IE7 and below and Opera 9.5 and below for Truglass
T154374: Gather feedback from GCI mentors after GCI 2016 (around 2017-01-14 to 2017-01-18)
Some retrospective notes:
- I would have also loved to see tasks like T154198 to T154201, but they did not even get marked as easy. :( cf T149564: Better recommending of tasks suitable for new technical contributors
- Marking a task on the GCI site as "ready" did not always work. Having to ping admins to publish a task on the GCI site was cumbersome.
- Mailing list or IRC channel to contact org admins specifically, instead of random private pings on IRC and emails answering mentor questions and publishing tasks when wanted in a timely manner, plus also to gather feedback in the end?
- We had no "concept how to offer harder tasks at the end"; cf. learning curve. Pure luck that we got mentors for harder tasks at the end
- We had way more mentors this year at the beginning. but I was naive expecting that this also results in more tasks :(
- Hangout session for mentors at the beginning worked well. (Srishti's idea)
- We need better examples for really well written tasks; e.g. jayvdb pointed to https://github.com/coala/coala/wiki/Google-Code-In-Task-Use-coala
- In 2016, we went 16 times over the 36h review/feedback deadline which is way more than in previous years (however never longer than 44h; I've heard stories of 72h from other orgs).
- Some input from TTO (not always exact quotes):
- a lot of the tasks that have been offered have been almost too trivial even for GCI... Maybe before GCI 2017 we (as Wikimedia) should discuss what standard the GCI tasks should aim to be. Obviously there will always be a mix of easier and harder tasks, but tasks that require changing one or two lines of code don't seem suitable as standalone non-beginner tasks.
- A recurring issue in our participation in GCI is availability of org admins. Last year I pointed out that all the org admins were in Europe, creating difficulties for mentors and students in the US and Asia. This year, the situation was a lot better, as mentors could now edit and accept tasks they weren't mentoring. But it still proved challenging to get new tasks published; waits of more than 24 hours, during periods when we were short on tasks, were often experienced. [...]
- Provide clear list of org admins and ways to contact them on MediaWiki.org. It would be useful to place a separate table on the mentors subpage with this info.
- The biggest issue for me, though, was the statement on the mentors subpage that "Tasks are supposed to take 2-3 hours to an experienced contributor." A number of the tasks created by other mentors were trivial, and would have taken the best part of 5 or 10 minutes for an experienced contributor to fix. Most of the students I worked with felt that they weren't learning anything from these tasks, and they were clamoring for some more juicy tasks to sink their teeth into. The fact that one student completed tasks at a rate of more than one per day on average is another sign that some tasks were too simple or involved too little work. I think org admins might need to take a bit of a harder line on task difficulty next time around, to ensure Wikimedia's GCI effort stays high-quality and more students remain engaged right through to the end. For example, a task could have required the student to remove a deprecated method in three extensions instead of one, or six extensions instead of three, etc.
- <jayvdb> https://codein.withgoogle.com/tasks/5785685814411264/ says "Set up a Vagrant instance (your development environment) - see instructions." ; it is tagged "vagrant". Rather than change that task, maybe retitle it to be vagrant, and create other tasks about installing the Docker, installing from the package manager, and have the participant report any problems. In each of these "setup a [dev|prod] environment" tasks, we should say something like "if you run into an unreported bug in the process, you should abandon this task and do [this task](link to create a bug) task instead, and then maybe re-start this task again later."
- AFAIK Dan/Analytics wanted a earlier heads-up for GCI (at least one month before) to prepare tasks.
- Optional Hangout session at end of Jan/Feb about Lessons Learned??
Closing as resolved when it comes to summarizing and documenting. (Not necessarily when it comes to how to improve / resolve some problems.)