Diff for /wikisrc/projects/code-in.mdwn between versions 1.40 and 1.41

version 1.40, 2012/12/05 22:06:35 version 1.41, 2012/12/12 12:45:06
Line 16  Previous organizations accepted for Code Line 16  Previous organizations accepted for Code
 There is [information from Google](http://code.google.com/p/google-code-in/wiki/GCIMentorInformation2012) about what is suitable as a task for Code-In.  There is [information from Google](http://code.google.com/p/google-code-in/wiki/GCIMentorInformation2012) about what is suitable as a task for Code-In.
 The most important part is to make the task easy enough: It should take approximately two hours of an experienced contributor to complete a single task. There are no difficulties, all tasks should approximately have the same difficulty.  The most important part is to make the task easy enough: It should take approximately two hours of an experienced contributor to complete a single task. There are no difficulties, all tasks should approximately have the same difficulty.
   
   ## Code-In 2012
   Code-In is running till January 14th. This site is *not* up-to-date, as several of the tasks are already solved or not doable in this way.
   
   ### Lessons learned so far
   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.
   
   #### 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.
   
 ## Goals as stated by Google  ## Goals as stated by Google
 1. **Code**: Tasks related to writing or refactoring code  1. **Code**: Tasks related to writing or refactoring code
 1. **Documentation/Training**: Tasks related to creating/editing documents and helping others learn more  1. **Documentation/Training**: Tasks related to creating/editing documents and helping others learn more

Removed from v.1.40  
changed lines
  Added in v.1.41


CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb