Hackathons/Handbook/Program

= Program and sessions =

Planning and scheduling content before the hackathon
While hackathons and content planning might seem almost incompatible, there are some content plans that help bringing interesting people with interesting skills to the event. Travel sponsorships and local developer outreach are more effective with a content plan in place. This plan also helps increasing the number of newcomers and diversity in general.

The ingredients of the plan:
 * Community Wishlist tasks. The Technical Collaboration team selects 3 - 5 Community Wishlist tasks with lead developers confirmed, and help recruiting volunteers and organizing the work prior to the event. See Hackathons/Suggesting projects.
 * Development tracks. The Technical Collaboration team reaches out to the Wikimedia tech community in order to identify groups that have a specific goal for the hackathon, from WMF teams to consolidated projects with capacity of mobilization.
 * Local projects. The local organizers have an option to select hackathon goals in line with the priorities of the chapter and their community. The Technical Collaboration team can help finding lead developers and volunteers.
 * Activities for newcomers. A track of introductory sessions is pre-scheduled with all the details and links to resources, allowing newcomers to prepare in advance. For instance:
 * Introduction to Wikimedia tech
 * Introduction to Phabricator
 * Introduction to Wikimedia Labs
 * Translations workshop
 * MediaWiki-Vagrant workshop - or follow Hackathon/Laptop setup before travelling.
 * Other workshops around clonable microtasks, from the Google Code-in pool or similar kinds i.e. Adding TemplateData to templates.

Selecting Community Wishlist recommendations

 * 1) WMF Community Tech team makes a pre-selection of all the relevant tasks suitable for the hackathon
 * 2) Create task in Phabricator to decide the CW tasks to focus
 * 3) Post a comment in these tasks and send an email to Hackathon registered participants asking them to express their interest in tasks (using Phabricator's Slowvote?)
 * 4) Select a very short list of tasks with owners and/or volunteers having expressed interest.
 * 5) Promote these tasks before the Hackathon and help the volunteers getting organized.

Developer outreach before the event
As soon as the content plan starts to show some shape, with the first tasks selected and the first sessions scheduled, it is time to reach out to developers.

It is important to dedicate time for developer outreach beyond the regular Wikimedia tech channels, especially at a local level: Successful contacts with local developer groups should influence the content plan of the event i.e. more Android activities if there is a strong Android developer community interested in the event.
 * local Wikimedia developers
 * local tech ambassadors / technical translators
 * local projects using Wikimedia tech or MediaWiki
 * local developer groups

Preparing the schedule
The availability of an interesting schedule is likely to drive developer attention beyond the usual participants in Wikimedia hackathons. Don't let all then information about logistics obfuscate the schedule.
 * Publish an empty schedule as soon as you have decided rooms and time slots.
 * Schedule the sessions for newcomers, pointing to own pages with all the information about each session. These sessions are quite common across events, it is better to reuse and improve existing pages than to create new ones for each event.
 * Post information about speakers and facilitators, including pictures. Newcomers are more likely to think that those sessions are a good fit for them if they know more about their speakers, and find a way to contact them with questions.
 * (Should we try Phabricator Calendar to allow people to RSVP / subscribe?)

Opening & Closing Sessions
The opening and closing sessions are for all hackathon participants. This is an example of a program

Opening Closing
 * Welcome / introduce the event by local host
 * Welcome / introduce the event by WMF co-organizer
 * If historically interesting introduce the venue
 * How to navigate the event (phab, wikis, sessions sign up, etc)
 * Logistics (social events, timing, transportation, help desk, etc)
 * Save at least 20 minutes for participants to introduce their projects
 * Thank you to hosts
 * Thank you to volunteers!!!
 * Showcase of projects
 * See you next year! Announce next location if it has been decided!

Don't print schedule of sessions in advance
Hackathons sessions are not all scheduled in advance. Many sessions are schedule on the first day of the conference or even an hour before the session will take place. If you print out a hard copy of the session schedule it will be out of date very quickly, but participants will still check it to see what is going on and miss out on session opportunities.

Tips:
 * Projecting the schedule onto a TV screen or well directly from the wikipage (and reloading it regularly) is appreciated. Whenever we don't have this, multiple people request it.
 * You can print out a hard copy of the schedule that does not include specific sessions but instead has meal times, opening/closing session times, social events, and breakout room information.
 * If you can not project the schedule somewhere (reminder to only do this if the page automatically refreshes every five minuites) you can create a large paper schedule at the help desk and have your help-desk-staff check every half hour and write in sessions as they are scheduled.
 * Announce in the opening of the event that they best place for up to date schedule information is on the event wiki

Sessions not edited until event
As an event organizer, don't worry if you have lots of meeting rooms and breakout spaces that look like they will be empty during the event. About half of sessions are not scheduled in advance of the hackathon and the more space you have the more ways people will find to use it. It is better to have more space and a few rooms that go empty sometimes than no space for people to do spur of the moment meetings.

If you end up having breakout room space left over you can still put it to good use
 * Quiet room, a room away from noise where talking is not allowed. If you can, dedicate a room to this for the entire event.
 * Loud groups can move to their own space
 * Your own planning breakout sessions
 * If the weather is nice and wifi works, some people like to move their sessions, discussions and hacking outside