[X-POST] KDE and Google Code-In 2010 -- we need Ideas!

[Akarsh Simha]

Hi everybody,

I've attached a file outlining relevant things about Google Code-In,
and summarized the stuff discussed in today's meeting on #kde-soc
(which was announced mostly on the mentors' mailing list).

The application deadline is very soon -- on 29th, and our idea list
(http://community.kde.org/GoogleCodeIn/2010/Ideas) is not as
well-populated as it should ideally be.

Fearing that is mostly because one doesn't know what kind of tasks to
come up with, I've attached some quick and easy-to-read information
and suggestions that a couple of us compiled from details discussed
during the GSoC Mentor Summit 2010 and an IRC meeting held about 6
hours ago.

Please help us get as many ideas as possible, so that we can bring the
success that KDE has been having with SoC to Code-In as well.

Regards
Akarsh
[Proxying for a Lydia who's in transit :)]
-------------- next part --------------
Table of Contents
=================
1 Basics 
    1.1 What's Google Code-In? 
    1.2 How does it work? 
    1.3 Further reading: 
2 Tasks 
    2.1 Guidelines for writing tasks 
    2.2 Relevant Deadlines 
3 Credit 
4 Suggestions / Ideas from the IRC meeting of 26th Oct 
    4.1 Comments on existing Ideas on the community Wiki 
    4.2 Handling build time (for coding tasks) 
    4.3 More suggestions on writing tasks in a manner that will help KDE 
5 Why mentor? 


1 Basics 
~~~~~~~~~

1.1 What's Google Code-In? 
===========================
   + A replacement for GHOP (Google Highly-Open Participation Contest)
   + A contest for 13 to 18 year-old pre-university students

1.2 How does it work? 
======================
   + Mentoring orgs provide tasks
   + Students pick tasks, and solve them
   + Students need not stick to a single mentoring org throughout the
     programme

1.3 Further reading: 
=====================
   + Intro: [http://code.google.com/opensource/gci/2010-11/]
   + Most details are on the FAQs page: [http://code.google.com/opensource/gci/2010-11/faqs.html]
   + Notes from the mentor summit session: [http://etherpad.osuosl.org/Google-Code-In]

2 Tasks 
~~~~~~~~
  + Mentoring orgs set the tasks
  + Mentors are assigned for each task
  + Unlike GSoC, tasks can include (and should :D) documentation,
    artwork, bug triaging etc.
  + New tasks can be added to the pool even during the contest period
  + Tasks can be queued up in Melange and published later time.
  + Independent of age, all students have access to all tasks

2.1 Guidelines for writing tasks 
=================================
   + Tasks should be suitable for 13-18yr olds! They will not have the
     attention span or speed of a frequent contributor.
   + Tasks should have time limits, and ideally, should not take more
     than 2 ~ 3 weeks
   + Tasks should be classified as easy / medium / hard
   + Tasks should be very specific, rather than open-ended, so that
     they can be claimed complete
   + KDE's task collection page is at
     [http://community.kde.org/GoogleCodeIn/2010/Ideas] -- these will be
     moved to Melange when appropriate
   + Tasks should be marked by area (Code / Documentation / Outreach /
     etc)
   + Tasks of a non-coding genre are highly encouraged as well
   + For coding tasks -- remember to include build time! (Also, make
     efforts to reduce build time)

2.2 Relevant Deadlines 
=======================
   + Application deadline for orgs (we need to have as many tasks as
     we can before this) -- 29th October
   + Contest opens -- 22nd November

3 Credit 
~~~~~~~~~
  + There are two kinds of credit / prizes -- cash for completion of
    tasks, and grand prizes for people with maximum number of points
  + Harder tasks fetch more points than easier tasks, but a task
    that's completed is a task completed.
  + Completion of 3 tasks fetches a student $100. They get T-Shirts
    too.
  + Students can complete as many tasks as possible during the contest
    period.
  + The grand prize winner gets a trip to Mountain View!

4 Suggestions / Ideas from the IRC meeting of 26th Oct 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

4.1 Comments on existing Ideas on the community Wiki 
=====================================================
   + Tasks need to be specific -- the end-point / culmination of a
     task should be well defined
   + Tasks should be short -- 1 month might be a bit too long

4.2 Handling build time (for coding tasks) 
===========================================
   + Projects come up with very clear instructions on the fastest way
     to build them
   + This kind of documentation will also help bugsquad.
   + Talk to bugsquad and see if they have suggestions / documentation
     about this already
   + OpenSuSE factory / Amarok Nightly Builds / Project Neon etc.

4.3 More suggestions on writing tasks in a manner that will help KDE 
=====================================================================
   + Helps to see [http://code.google.com/opensource/ghop/2007-8/] to
     get ideas of what tasks were like in the first edition
   + Avoid making all easy tasks available on day 1 -- will give more
     people a chance to claim easy tasks
   + However, make a lot of easy tasks available to start with, so
     that students can gain confidence
   + Students looking at the org page might not come back to us if all
     tasks are hard, so not all, but plenty of easy tasks could be
     made available at start.
   + Make as many tasks as possible, so that KDE gets a lot of
     students!
   + Diverse set of tasks will help KDE attract more students, with
     diverse interests
   + Tasks should be independent of one-another -- both code-wise and
     learning-wise
   + OTOH, if tasks have continuity, maybe from easy to hard within
     the same project, the students gets a gradual introduction to the
     project, knows different aspects, and, hence he will definitely
     stick; I'm just emphasizing the importance of the tasks
     themselves
   + Maybe a good trade-off is to have multiple tasks from the same
     project, and yet have a lot of diverse tasks.

5 Why mentor? 
~~~~~~~~~~~~~~
  A collection of various opinions:
  + Can have non-coding tasks, which are not the case in GSoC
  + Mentoring is required for brief periods of time -- less strain on
    mentors who are constrained for time
  + Specific outcomes, and unlike in GSoC, credit is not awarded if
    task is not complete
  + Great to get specific things done for your project
  + Students in this age group are more likely to stick on, because
    they have more time on their hands, and gain more enjoyment out of
    doing creative things
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://mail.kde.org/pipermail/kde-soc/attachments/20101026/ec73748f/attachment.sig