Originally forked from the official MLH Hackathon Rules.
After hacking finishes, teams will show their projects each other and to the judges.
You are strongly encouraged to present a demo of what you have built. Pitches or presentations are discouraged. You are not judged on the quality of your pitch or the quality of your idea. As you are judged on what you built, you'll only hurt yourself by not showing a demo.
You are encouraged to present what you have done even if your hack is broken or you weren’t able to finish. It's okay if you didn't finish your hack—that happens all the time! Completion is only one part of the judging criteria, so you might still do well. Also, demoing is not just about the competition. It's a chance to share with others what you learned and what you tried to build—that's what hacking's all about! In the case that you don't have anything to demo, you can give a presentation about what you tried and what you learned. Hearing what other people learned is interesting and inspiring for other attendees.
Teams will be judged on these four criteria. Judges will weigh the criteria equally. During judging, participants should try to describe what they did for each criterion in their project.
The following criteria will be used to judge the Best Overall, Best Rookie College Hack, and Best High School hack prizes:
-
Technology: How technically impressive was the hack? Was the technical problem the team tackled difficult? Did it use a particularly clever technique or did it use many different components? Did the technology involved make you go "Wow"?
-
Design: Did the team put thought into the user experience? How well designed is the interface? For a website, this might be about how beautiful the CSS or graphics are. For a hardware project, it might be more about how good the human-computer interaction is (e.g. is it easy to use or does it use a cool interface?).
-
Completion: Does the hack work? Did the team achieve everything they wanted?
-
Learning: Did the team stretch themselves? Did they try to learn something new? What kind of projects have they worked on before? If a team which always does virtual reality projects decides to switch up and try doing a mobile app instead, that exploration should be rewarded.
The prizes for Most Accessible and Most Innovative will be judged on the following criteria:
-
Accessibility: How well does the project meet the Software Accessibility Checklist provided by the Department of Justice? It is important to note that this category is not meant for hacks that solve accessibility issues (ex. A hack that helps people learn sign language). Rather, it is for hacks that have accessibility and usability in mind when building the hack.
-
Innovation: Does the team tackle a problem that might not have been solved before? Do they come up with an interesting way to solve it? While other categories are not affected by the project’s uniqueness or innovation, this category rewards projects that have come up with an outside-the-box idea.
If you are submitting for the equity, efficiency, or environment prize categories, the following criteria will be used to judge your project for those prizes:
-
Equity: Does the project effectively tackle a relevant social issue? Did they bring awareness or propose a solution to a social issue? Did the team utilize credible data and other resources? A “good” project is one that demonstrates a team's understanding of a societal issue (socioeconomic inequalities, healthcare, poverty, politics, etc.), the factors that influence this issue, and a mission associated with this issue (call to action, proposed solution, reveal new information) in addition to the base technical criterion.
-
Efficiency: Does this project improve an existing process? Does this tool make something in our day-to-day life more manageable? Does it reduce the costs (monetary or computational) of an existing tool? You are ranking a project based on how creatively a team optimizes an existing service or proposes something new and useful. Presentations should clearly state an existing problem and explain how their tool addresses this issue.
-
Environment: Does the project effectively address an environmental issue? Did they educate, bring awareness or propose a solution to an environmental issue or topic? Did the team utilize credible data and other resources? A “good” project is one that demonstrates a team's understanding of an issue affecting the natural world (climate science, deforestation, pollution, extinction, sustainability, ecology, etc.), the factors that influence this issue, and a mission associated with this issue (call to action, proposed solution, reveal new information) in addition to the base technical criterion.
It's important to note that these judging criteria do not include:
- How good your code is. It doesn't matter if your code is messy, or not well commented, or uses inefficient algorithms. Hacking is about playing around, making mistakes, and learning new things. If your code isn't production ready, we're not going to mark you down.
- How well you pitch. Hacking is about building and learning, not about selling.
- How good the idea is. Again, hackathons aren't about coming up with innovative ideas. It's about building and learning.
- How well the project solves a problem. You can build something totally useless and as long as you're learning and having fun, that's a good hack! Sometimes a pointless project is one of the best hacks!
So don't worry about coming up with the next big idea or building the next Facebook. You'll have plenty of time for that outside the hackathon. just focus on learning, having fun, and making new friends. At the end of the day the skills you learn and the friends you make might lead to the next big thing—but you don't have to do that to win a hackathon.