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.

The Wikimedia Hackathon model
The 2015 European 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 Engineering Community Team and experienced volunteers.


 * Lightweight organization focused on simplicity and effectiveness, with almost no overhead.


 * Budget for the organization approved in advance 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 and tangible outcome. The number of attendees is not a goal per se.

Demo-able projects
We want to 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.

Organizers may plan for prizes or other types of incentives. 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 are experimenting with buddies, pairs of participants complementing each other. For instance, all Wikimedia Foundation employees are asked to find a non-WMF buddy. Potential participants requesting travel sponsorship will have higher chances of being accepted if they have a buddy. Hackathon organizers can help with establishing connections.

Some good buddy pairings:


 * newcomer - insider
 * volunteer - professional
 * Wikimedia - non-Wikimedia / upstream
 * developer - non-developer
 * contributors to common projects
 * speakers of common languages
 * different countries
 * different ages
 * different gender

Finding your buddy
Think who is submitting patches to your repos, who is helping in your tasks, who contributes to your mailing list discussions... People out there are spending some of their time on your projects, when there are so many other interesting things to do. They will be honored if you send them an email proposing to be their hackathon buddies. Think also who is bringing criticism to your projects, invite them for some face-to-face collaboration.

Event organizers can help, offering a page to find buddies (e.g. Wikimedia Hackathon 2015/Buddies) and proposing connections based on the registration information.

Note that this is not only about looking among people who has registered to the event. You can think of experienced and productive buddies that you would like to work with at the event. A community developer you have never met in person, a colleague in an upstream project that would benefit from knowing more about Wikimedia, an experienced editor that will bring other perspectives and get involved... Buddy selection will increase the possibilities of travel sponsorship of both buddies.

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

Community

 * How many participants?
 * Diversity of participation (origin, affiliation, sponsored, newcomers, gender)
 * How many buddies?

Hacking

 * How many projects are showcased?
 * 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.

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.
 * Don't use clips which allow the badges to rotate. A badge which is flipped around so that only a blank back shows is useless.
 * Use the back for 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