October 2011 Coding Challenge/Judging

In order to administer the Weekend of Code challenge effectively, we need to build a simple system for gathering information about contest participants. This is the first cut at building those requirements.

= Gathering Contestant Data =

Asterisk indicates required field, all others optional, question mark means "do we really want to ask this?"


 * Full Name (*)
 * User name (*)
 * Email Address (*)
 * Interest in volunteer participation
 * Country (*)
 * Code Submission (*)
 * Assigned UID

Submitting this form puts the user's info into the system. They should be able to change this info at any time until the contest closes, at which point this data should be locked.

We need to work out the details of code submission, but the general idea is that the user can submit code at any time, just like other fields, and when the contest closes, this data is locked. Emphasis on simple.

The Assigned UID is the mechanism that will allow judges to identify contestants for anonymous judging purposes.


 * How are we forcing uniqueness? By name, email address...? Sumanah 20:48, 23 September 2011 (UTC)
 * I'm leaving the details here to JeroenDeDauw. --Gregdek 21:47, 26 September 2011 (UTC)

= Contestant Communication =


 * Initial email to individual contestants upon registration: "Thanks for joining up!" (FIXME: need copy.)
 * Reminder emails sent as deadline nears (14 day, 7 day, 3 day, 1 day?)
 * Congrats/thanks emails afterwards Sumanah 20:51, 23 September 2011 (UTC)
 * Will we also put those messages on a miniblog, a status section of the webpage, or some other public place on the code challenge homepage? I'm fine with manually editing a wiki page & duplicating effort a bit, if Greg is. Sumanah 20:51, 23 September 2011 (UTC)

= Getting/Setting Contestant Status =


 * Should allow for multiple judges.
 * During the period of the contest, personally identifiable information should be unavailable to the judges.
 * Should be able to set notes and flags for each contestants.
 * Notes: just simple text field.
 * Flags:
 * Not yet reviewed
 * In Process (currently being reviewed) (locked for other judges)
 * Rejected (reviewed and does not meet basic requirements)
 * Accepted (reviewed, meets basic requirements, passed on to second stage)
 * +1s (a simple way of recording a judge's +1 vote)
 * Winner (big winner!)
 * Need the ability to track who set the flag!
 * Simple sortable views by flags (i.e. show me all users with Flag X)
 * Basic mail merge functionality
 * i.e. send this email to all users with Flag X
 * fallback: give me csv of email addresses of all users with Flag X
 * Some kind of super-admin role should be available for Greg & me that can read everything, remove or add judges, etc. Sumanah 20:52, 23 September 2011 (UTC)
 * this is in the spec, yes. --Gregdek 21:49, 26 September 2011 (UTC)

= Flow: Contestant =


 * User sees banner and clicks on the banner, comes to signup page
 * User signs up
 * Require creation of wikipedia account to lessen need for new infrastructure. FIXME: what is a "Wikipedia account" in this context?
 * If user has already signed up for contest, receives messaging accordingly
 * User receives email thanks for signing up, with useful links
 * URL of their contest page for making submission
 * Links to rules, documentation for MW install, gadgets, mobile, extensions. FIXME: find & write these docs/links
 * Links to mailing list / IRC chat for help (Sumana)
 * User hacks away!
 * User receives a reminder: submit soon!
 * User submits code
 * Goes to URL of contest page
 * Upload button for code
 * Radio button: gadget/extension/mobile app
 * Text field: basic description of what their code does
 * User decides "whoops, I need to change that code", can overwrite contest data at any time
 * THE CLOCK STRIKES MIDNIGHT. Contest page is *locked*!
 * User eliminated: receives email thanking them for participating. FIXME: write messaging for this.
 * User accepted: receives email congratulating them and links to ACHIEVEMENT. FIXME: write messaging for this.
 * User wins! Receives personal email from a head honcho.
 * Winning user is passed to whomever to handle prize logistics. FIXME: who handles prize logistics?

= Flow: Judge =


 * Greg & Sumana recruit judges. FIXME: messaging for invitations, including "if you judge then you can't submit an entry".
 * Person signs up as judge. (Or maybe is simply appointed.)
 * Judge is given access to judging interface.
 * How? passwords?  LDAP something?  Need lost-password interface/flow.
 * Judging interface is read-only until judging period begins?
 * Judge selects an entry to review.
 * Entry is locked and assigned to that judge.
 * Judge, and only judge, may set flags on entry at this point.
 * Admin may break locks if necessary.
 * Upon full completion of judging, messaging is handled by admin. Judges lose access to judging interface.
 * After competition: admins write thank-you notes to judges. FIXME: write messages.

= Possible judging criteria (note separately later) =

Not sure we necessarily want separate categories, but we should definitely spell out what we're looking for in a good entry. Here are some ideas.


 * Exceptional documentation award. People love to build on worked examples, and a great worked example with great documentation might be worthy of its own award.
 * Most functionality in the tightest code.
 * Best UI enhancement.