How to run a Hackathon

This page outlines best practices and recommended steps for running a Hackathon.

Previously, Hackathons have run twice a year with one coinciding with MatterCon. In future, Hackathons may be run three or four times a year.

T-minus counts measure "working days" (weekdays other than major holidays concurrent in US and Canada) prior to the Hackathon day. All times are based on 8:00am (Palo Alto Time) unless otherwise stated.

A. (T-minus 40 working days)

1. Decide dates for the Hackathon. Some things to take into consideration:

   • Avoid overlap with major holidays in US, Canada, Europe, or Asia (including Australia and Japan).

   • Avoid overlap with significant release dates, such as release testing or feature complete. Recommended time is starting a Hackathon within a week after feature complete.

   • Avoid overlap with significant company dates that take significant amount of developers' time, such as performance evaluations.

   • Avoid overlap with significant community dates, such as major developer conferences/events.

   • Avoid starting on a Friday - this results in a kick-off call in the late evening for Europe/Asia, effectively meaning the Hackathon starts on a weekend in those areas.

   • Previous Hackathons ran for two days with presentations on the third date. At the end of the most recent Hackathon participating developers suggested adding a third day to allow more time for polish and increased quality.

2. Identify at least one or two developers to partner with during the Hackathon. Start by reaching out to either VP Engineering or Dev Leads to hear their recommendations.

B. (T-minus 30 working days)

1. Put together a project plan, including task description, start date, due date, owner, and any additional notes. See an example.

2. Identify one or two members in Marketing to partner with, who can help with tweets, blog posts, and other marketing content to generate awareness of the Hackathon.

3. Identify one or two members in Ops to partner with, who can help with meeting scheduling, SWAG, and other operational tasks.

C. (T-minus 25 working days)

1. Work with Ops to decide on what SWAG to send for participation - both for contributors and staff.

2. Create a landing page for the Hackathon, which contains all information and to which other communication items are linked.

   • This can be a webpage such as one for Feb/2019 Hackfest or a GitHub repository such as one for Nov/2019 Hackathon.
   • All processes and documentation should be clearly included on this landing page, including a process for finding and assigning teams and project submission guidelines. FAQs can be incorporated as needed.

3. Create a GitHub repository for submitting Hackathon projects. This can be the same as the landing page if a GitHub repository is used for it.

D. (T-minus 20 working days)

1. Announce the Hackathon internally by posting in Private Staff Discussion channel and sharing in the R&D weekly meeting.
2. Schedule a kick-off call with all Hackathon stakeholders, including

   the developer, Marketing, and Ops members identified previously.

3. Define and set up metrics to measure impact of the Hackathon. Examples include: Number of participants (staff + community separately), number of submissions, number of submissions shipped as a core feature or as a plugin in the Marketplace.

E. (T-minus 15 working days)

1. Create Meetup links for Hackathon idea presentation, kick-off, and demos. For examples, see Mattermost Meetup page.
2. Share the Hackathon externally via Reddit, GitHub, Discourse, and the community server. For examples, see previous Reddit post, and GitHub issue.
3. Publish a blog post announcing the Hackathon to the Mattermost community, which links back to the landing page for details on how to participate.

F. (T-minus 10 working days)

1. Schedule a series of tweets announcing and reminding community of the upcoming Hackathon. See this Google Doc for examples.
2. Work with Ops team to get SWAG prizes ready and set up with Printfection.

G. (T-minus 5 working days)

1. Hold a Hackathon idea presentation call, scheduled for 60 minutes, with an additional 30 minutes for extra time. This time is used to gather feedback about ideas and to attract others to work as a team. To see previous slides and meeting recording, see Hackathon Nov/2019 Google Drive.

H. (T-minus 0 working days)

1. Hold a Hackathon kick-off call, scheduled for 30 minutes. To see previous slides and meeting recording, see Hackathon Nov/2019 Google Drive.

I. (T-plus 3 working days)

1. Hold a Hackathon demo call, scheduled for 2 hours, with an additional hour for extra time. This time is used for participants to present their project. Invite the entire Mattermost organization to the call as optional attendees.

   • Provide guidelines and best practices for creating presentations (both for staff and community).

   • Three minutes allowed per Hackathon participant. For participants with multiple submissions, five minutes total is allowed for the presentations.

   • Ask participants who can't attend to submit a demo video, which is shared during the call.

J. (T-plus 5 working days)

1. Ask developers to hold a Hackathon retrospective and share feedback for future improvements.

2. Hold a Hackathon post-mortem call among key stakeholders (developers, marketing, ops).

3. Work with ops to gather a list of winners and send SWAG prizes via Printfection.

4. Gather a list of submissions and separate them by R&D feature teams. Product Managers on the respective teams will be responsible for discussing with Dev Leads on which submissions make sense to ship as core features or plugins, and scope out remaining work.

K. (T-plus 7 working days)

1. Publish blog post sharing insights of the Hackathon.

2. Update this process doc for changes in running a Hackathon.

Tips and Best Practices

1. Do not use your own Zoom link for Hackathon calls. Recommend using a company Zoom link, or one created specifically for Hackathon.

2. In Zoom, go to Settings > Recording and set Recording consent to true. This prompts participants to consent to be recorded when recording starts.

Note that the list below contains suggestions or questions that are not yet incorporated into the above process. For developer feedback from November/2019 Hackathon, see this retrospective.

1. How will Hackathon presentations be handled in the future at scale? The presentations took two hours in November/2019 with 44 participants (3 minutes per presentation), and some suggested the presentations took too long.

2. Clear process and documentation for new members (both in staff and community).

3. Clear process for non-developers to participate, e.g. documentation, UX, QA, support. Overall, offer better cross-communication among team leads and ensure those who want to participate are able to.

4. Promote Hackathon by using examples from previous hackathons, and tweet about them. Highlight projects that made it into the core product or as supported plugins.

5. Nominate mentors from within staff or contributors who can provide additional guidance, talk through ideas and help get members going during the Hackathon. Mentors would ideally be contacts from different areas, e.g. mobile, plugins, webapp. Publish the list from which new members (either core or staff) can then sign up to work with.

6. Provide more opportunities to plan projects, such as setting up meeting invites with interested people.

7. Make it easier to get community involved in specific projects, and work with staff.

8. Improve social aspects. For instance, incorporate physical meetups timed with Hackathon, or virtual hangouts in Discord.

9. Activity feed. Have people talk about their projects (e.g. share screenshots or daily updates) during the Hackathon. Consider promoting in progress work in social media or other public facing sites to increase awareness of the Hackathon.

10. Promote physical hackathons at universities and have staff or community help run them and get people involved.

11. Clearly track next steps both for community and staff. One possibility is a shepherding program to encourage submissions to "cross the finish line" as a core feature or certified plugin where appropriate.