Hackathons


 * For an introduction about hackathons, see Hackathon 101.
 * For detailed information about this year's hackathon, see Wikimedia Hackathon 2024.
 * For information about this year's Wikimania event, see wm2024:Hackathon.

Wikimedia hackathons play an important role energizing our engineering community and connecting it to local groups. We need more of them in different places.

Main goals of our hackathons:


 * 1) Work on prototypes, sprints, and other collaborative efforts to be showcased at the end of the event.
 * 2) Strengthen community health and developer ties through projects, buddies, and other ways of mingling.
 * 3) Reach out to new developers, onboard them during the event, and turn them into regular contributors.
 * 4) Make progress on the most recent community wishlist.

The Wikimedia Hackathon model
The 2015 Wikimedia Hackathon has become a reference:


 * Unconference model focused on hands-on work, training, and technical discussions.


 * Run in a different location every year, with different local organizers supported by the Wikimedia Foundation's Developer Relations team and experienced volunteers.


 * Lightweight organization focused on simplicity and effectiveness.


 * Budget for the organization approved by the Developer Relations and complemented by travel sponsorship support from the Wikimedia Foundation, the local organizers, and other organizations.


 * Local organizers focus on local work. Global aspects like travel sponsorships and the program can be delegated to the community. The WMF helps where is needed.


 * Goals are measured by participants' satisfaction, on-boarding of newcomers and tangible outcome. The number of attendees is not a goal.

Demo-able projects
We focus our hackathons on teaming, prototyping, and a showcase at the end of the event. A hackathon provides a good environment to accelerate the development of new ideas, to collaborate on tough problems, and to identify contributors capable of leading independent projects.

The Wikimedia Foundation will look at the projects showcased, seeking opportunities to support the productization of interesting concepts.

Pairing buddies
In our hackathons and many events, participants have a natural inertia to clusters with others they know well, while other participants have a hard time mingling in. To solve this problem, we have experimented with buddies, pairs of participants complementing each other. Participants are giving the opportunity to volunteer to be part of a buddy pair. Potential participants requesting travel sponsorship will have higher chances of being accepted if they have a buddy. Hackathon organizers can help with establishing connections.

The most important goal of the buddy system is to help mentor and onboard newcomers. It has been our experience that if newcomers have a dedicated and willing buddy they feel more welcome and are able to integrate and begin contributing more easily.

Finding your buddy
Hackathon organizers will provide a list of people willing to mentor and a list of newcomers wanting a buddy. Ideally buddies find each other, although hackathon organizers can help. Ideally every newcomer who wanted a buddy will have one.

Welcoming newcomers
Hackathons are good opportunities to reach out to new contributors. The buddy system mentioned above can be useful to connect newcomers with insiders. Specific activities must be planned in order to introduce them to Wikimedia tech and the activities of the event. The registration form should help identifying newcomers and other participants welcoming an introduction, as well as more experienced contributors willing to help welcoming them. See T89392.

Note that there are different types of newcomers:


 * Junior developers interested in Wikimedia.
 * Not so junior developers interested in an international developer hackathon happening nearby.
 * Developer communities strong in technologies used in Wikimedia: PHP, JavaScript, Android, iOS... (T76325)
 * Local or international contributors of upstream projects used in the Wikimedia stack. (T76325)
 * Tech-curious contributors, not necessarily developers, but experts in some related area (web publishing, open data, geolocation, etc).

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.
 * 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
 * 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?)

Proposing a hackathon
More information about proposing and running hackathons in partnership with WMF here.

Also see Hackathon tips for organizers.

Hackathon location decision process for 2017
The decision committee for the 2017 Wikimedia Hackathon location is: Except for Rachel and Quim, everyone on the committee is acting in their volunteer capacity.
 * Rachel Farrand (Wikimedia Foundation Developer Relations team, has been a main organizer for 12 Wikimedia Hackathons)
 * Quim Gil (Wikimedia Foundation Developer Relations team, has run or helped run 6 Wikimedia Hackathons)
 * Greg Varnum (Wikimania DC Hackathon and Wikimania Hong Kong Hackathon)
 * Maarten Dammers (Amsterdam Wikimedia Hackathon)
 * Siebrand Mazeland (Wikimania Mexico City Hackathon, Pune Wikimedia Hackathon, Bangalore Wikimedia Hackathon, Amsterdam Wikimedia Hackathon)
 * Alex Cella (Lyon Wikimedia Hackathon)
 * Denise Jansen (Amsterdam Wikimedia Hackathon)

Information about the 2017 decision process can be found here.

Community

 * How many participants? (this is just a metric and not a measure of success).
 * Diversity of participation (origin, affiliation, sponsored, newcomers, gender).
 * What percentage of newcomers requesting a buddy received one?

Hacking

 * How many projects are showcased?
 * Progress made on community wish list items?
 * How many driven by volunteers?
 * Any projects that the WMF decides to support after the event?
 * Tasks resolved?

Training

 * Overview of Wikimedia tech priorities and ongoing projects welcoming contributors.
 * How many newcomers & welcomers in welcoming session?
 * Participation and results in other training sessions.

Meeting

 * Community decisions worth a face to face meeting.
 * Social meetings and events.

Organization

 * Costs and final balance.
 * How much funds pooled for volunteer travel sponsorship, and from whom.
 * Participants survey and summary report.

Suggestions / Ideas from Hackathon Participants
Feel free to add your ideas for improving hackathons here!

Name badges
At hackathons, the primary purpose of name badges is to reduce the stress of having to remember dozens of new names. Therefore, the names on the badges should be huge—at least 1.5 centimeters high. Other best practices for name badges include: For other advice, see "6 inspiring conference badges" and Mike Davidson, "Building a better conference badge".
 * Emphasize the person's given name, which is what you actually use to talk to them.
 * Add extra information like the person's hometown, organizational affiliation, or interests (for example, "Mediawiki Core", "Bots", or "Wikisource"). But remember: if the information isn't big enough to read from several meters away, it won't actually be useful.
 * Names on both sides of the badge in case it rotates
 * Consider making the badge four sided, two visible sides with the participants name and interests, two hidden inside pages with useful reference information like the Wi-Fi password, contact information for the organizers, and highlights from the schedule

Stand up to get an idea of your audience
A hackathon idea stolen from the Swizz:
 * Take a room and clear it of any chairs
 * Draw two lines in the room to divide it in three parts
 * Ask people for who it is the first hackathon to stand in the first square, 1-3 hackathons in the middle one, 4+ in the last square
 * Ask people who know what to work on to stand near the window, not clue on the other side and in doubt in between
 * You know subdivided the room in different groups by experience and what to work on
 * Do a regular idea pitching session, but start with the people who are near the window
 * Have two microphones so you can start from both the very experienced and the newbies and work to the middle