October 2011 Coding Challenge/Judging

SECOND DRAFT: CONTESTANT FLOW

A more page-based flow incorporating feedback, according to the illustration on the right.

1. The Banner Ad.

This is the ad itself. When potential participants click on it, they are sent to 2. The Landing Page. The landing page, and all subsequent pages, will live on mediawiki.org.

2. The Landing Page.

A simple landing page with copy about the contest itself:

• A short paragraph about "why this is awesome"
  • We will note in the text that exceptional contestants may be contacted for interviews
• Text explaining each challenge
• Text and links to jobs and volunteer opportunities
• Link to rules to the challenge (a pop-up? we want to show these rules from many directions)

At the bottom, Challenge links should appear based on user state:

• If the user is logged in, a link straight to the 5. The Challenge Form Page.
• If the user is not logged in:
  • "I want to join, and I have an account." (Link to 3. The Login Page.)
  • "I want to join, but I do not have an account." (Link to 4. The Create Account Page.)

3. The Login Page.

The standard login page, with a callback to the Challenge Form Page. We might want to have a link that points users to the Create Account Page, in case they think they have a login but they actually do not.

4. The Create Account Page.

This should be a standard account creation page, with a callback to the Challenge Form page.

5. The Challenge Form Page.

This is where we collect further form data that is specific to the Challenge itself. Only available to logged-in users.

• Has user already signed up? Redirect to The Contestant Page.
• Pre-populated fields for full name, user name, and email, based on their account info.
• Radio button: "Which challenge are you applying for?"
  • Cannot be changed later!
• Checkbox: "I am interested in volunteer opportunities"
• Checkbox: "I am interested in working for the Wikimedia Foundation"
• Checkbox: "I confirm that I have read, and agree to, the contest rules (link to The Rules Page)

5a. The Rules Page.

The formal, legal rules. A pop-up? A new tab? Open to suggestions here.

6. The Contestant Page.

This is the page where users who have already joined the contest go to upload their code. It should contain:

• Docs/details/hints specific to the chosen challenge;
• Time left before contest close;
• Link to the rules;
• Links to help;
• The upload form, and a link to their previously uploaded submission (if any);
• Optional fields allowing the user to enter data about themselves:
  • CV for participants interested in job openings
  • See foundation:Special:CommunityHiring (OPEN: should we simply replicate this?)

In my opinion, the upload form should be open for the length of the contest, until the moment the contest closes. If a contestant wants to resubmit, we should allow it. This implies that no entry is "final" until the moment the contest ends.

6b. The Contestant Email.

The initial contestant email should contain content nearly identical to the content on the Contestant Page.

We should also send reminders based on this email at specified periods leading up to the project's conclusion.

7. The Judging UI.

A separate flow that the user never sees; just noting that participant data goes here as part of the submission process. More here soon; for now, the judging UI will be the same as in the first draft.

FIRST DRAFT

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.