Hackathons


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

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

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 (WMF Developer Relations team, has been a main organizer for 12 Wikimedia Hackathons)
 * Quim Gil (WMF Developer Relations team, has run or helped run 6 Wikimedia Hackathons)
 * Greg Varnum (Wikimania DC Hackathon)
 * Maarten Dammers (Amsterdam Wikimedia Hackathon)
 * Siebrand Mazeland (Wikimania Mexico City Hackathon, Pune Wikimedia Hackathon, Bangalor 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