NetBSD Wiki/projects/ code-in 2012

Google Code-In 2012 (GCI)

Contents

  1. Google Code-In 2012 (GCI)
    1. Introduction
    2. Goals as stated by Google
    3. Lessons learned
      1. Coding tasks are interesting
      2. Add maintenance tasks
      3. Have a clear outline of the task
      4. No creative tasks, but design tasks
      5. Watch out for plagiarism
      6. Don't add extra requirements
      7. Make tasks small projects
      8. Make stand-alone projects
      9. Combine tasks to a larger project
      10. Be clear about your expected formats
      11. Stay in touch with the students
      12. Look into the tasks yourself before submitting them
      13. Don't underestimate the required effort!
      14. Be demanding
    4. Fulfilled tasks
      1. Edit, wiki integration
      2. Advocational tasks
      3. Informational and external tasks
      4. Code tasks

Introduction

Code-In was running till January 14th. This page now contains the list of tasks which were actually done. You can see the results (open tasks as well as closed ones) on the Google Melange page. There were 88 tasks done and 23 were left open.

We provided a Virtualbox image for testing, such students didn't have to spend time on installing the system when they just wanted to complete a task where they needed NetBSD running.

Previous events by Google: Code-In 2010, Ghop 2007

Previous organizations accepted for Code-In: Code-In 2010 Code-In 2011

There is information from Google about what is suitable as a task for Code-In.

Goals as stated by Google

  1. Code: Tasks related to writing or refactoring code
  2. Documentation/Training: Tasks related to creating/editing documents and helping others learn more
  3. Outreach/Research: Tasks related to community management, outreach/marketing, or studying problems and recommending solutions
  4. Quality Assurance: Tasks related to testing and ensuring code is of high quality
  5. User Interface: Tasks related to user experience research or user interface design and interaction

Lessons learned

The effort needed for Code-In struck us unexpected. There were several things to be learned about Code-In and about the kind of work that can be done in the scope of Code-In.

Coding tasks are interesting

The students are mostly interested in coding tasks. They do not want to write documentation, and they don't want to research things. With coding tasks, students would even spend more time on a task than they would do with something else, and maybe even stick to that task when GCi has finished.

Add maintenance tasks

Another kind of task which was often claimed were the ones about maintenance jobs, in this case conversion of articles from XML to Markdown. They're easy to do, but require a lot of effort - suitable for GCi.

Have a clear outline of the task

Tasks with an unclear description often led to results which were not as expected. Students of this age are more used to have a task which has a clear result, and not something open. Though there were some good results, it's still difficult to understand the tasks and sometimes the tasks were only solved with the second or third approach.

No creative tasks, but design tasks

Don't do creative tasks, i.e. creating images. On the other side, the design or layout tasks went very well - so if you want to know how a student would imagine the interface for a program or website or book format you need, then make that a task - but be clear about the results and what you expect. You should have thought yourself about how you would do this in advance, such that you can explicitly state what requirements the task has. You'll get nice results with new ideas.

Watch out for plagiarism

Especially in the research or documentation tasks, you have to be careful about plagiarism. Several students just copied texts from other sources and tried to submit them.

Don't add extra requirements

When the student has to download or configure extra requirements first, the task gets much harder. You should not add tasks which rely on src, pkgsrc or pkgsrc-wip or whatever large or difficult extra things to do before being able to work on the task.

Make tasks small projects

The coding parts are more appealing when they are small autonomous projects. The tasks involving creating your own binary had a larger acceptance than the once which were about fixing bugs of existing programs. You can and should tasks for small programs even if you only want them for research, i.e. you want to look at the possibility of a larger project involving this. Even if the task is about another project, but which would or could add benefits for NetBSD, it is possible.

Make stand-alone projects

This is not the same as making small projects. The described small projects should be in such a way that you can run them on any operating system and they don't require a speical setup to be written, i.e. many preinstalled packages. The students are most likely not running NetBSD, and forcing them to install NetBSD, install some pkgsrc packages and spend time configuring the system discourages doing a task. Even the Virtualbox images were no great help for some of these tasks.

Combine tasks to a larger project

Maybe contrary to making small projects, tasks should have a connection. Students are more engaged if they did something, and when approving the work you already point them to other tasks which are similar to the one they just did, or work together with this one.

Be clear about your expected formats

You should be very clear about the formats you expect for input! If there is an image, tell t hem to upload the "sources" (gimp xcf file or so); if there is a text, it should be plain-text; if it is a program, the final submission should be an archive with the code and not a link to github.

Stay in touch with the students

The best way of communication with the students is via IRC. Everything else is too slow, and when a task is meant to be 48 hours, but half of the time is spent waiting for communication, the task is likely to fail or waste student's time.

Look into the tasks yourself before submitting them

Though it might be charming - when you want students to fix a PR, you should look at the bug yourself and have a slight idea how to fix it before submitting it. There was a task which was not possible to fix (for the student) and was duplicate. And the students might have questions and then having to research things yourself before you can help is not good.

Even with all the other tasks, you should have an idea what you want, and what effort it requires. There were some tasks which resulted in much work though they seemed easy in the beginning, while other tasks stated as difficult could be performed within a few minutes.

Don't underestimate the required effort!

You should not underestimate the effort needed by Code-In. On the one hand, when you're young, you're not as patient as later. Waiting several hours to get a task confirmed is a lot of time in a student's mind.

On the other hand, there was a great run in the first week of Code-In. You have to read several tens of mails every hour, especially in the beginning.

When a student needs help, you have to care for him and help him with that, even with configuring the system.

Be demanding

If you have an engaged student, you can be demanding. Don't hesitate to send back his work and be explicit about what you don't like. But be careful you don't frighten him. There were also students which just unclaimed a task because they didn't understand the review.

Fulfilled tasks

The work done by GCi has not yet been integrated to NetBSD. Especially the documentation tasks have to be put into the wiki, but also need modifications in the NetBSD website infrastructure.

These are the tasks which were completed:

Edit, wiki integration

These tasks created or converted articles for the wiki. We have to edit and commit them to the wiki.

Advocational tasks

These tasks created advocacy material and have to be integrated to the website or to a new wiki page.

Informational and external tasks

These tasks just provided information, we have to see how we handle them. They maybe also created code or information which should be used for something, but currently has nothing equivalent in NetBSD. They were done by developers who had project ideas, and wanted students to research or code them.

Code tasks

These tasks created code, i.e. fixed bugs or wrote a new program, or did something that should be integrated to src/ or pkgsrc/.

Add a comment
Last edited late Saturday evening, May 25th, 2013
Preferences | Logout