hackKU Official Rules

[Competition: Saturday, 11AM - Sunday, 11AM]

Competition

  • Teams must have a maximum of five members.
    • Contenders may work alone, but they will be judged on the same guidelines as a team will be.
  • All members of a team must be registered participants.
    • All team members must be current students or recently graduated (within 1 year).
  • All team members must sign in and be present at the event.
    • Working off-site is discouraged, but allowed.
  • Code for a team’s project should only be written by team members.
    • Getting advice from other teams, volunteers, sponsors, or mentors is allowed, and encouraged.
    • Don’t get someone else to code your project for you.
    • Please don’t get your pals from home to remote in and help out.
  • Teams may use ideas for projects they have had before the event.
  • All code written for this project MUST be written during hackKU.
    • It is entirely against the spirit (and the rules) of this competition to work on a project already in progress.
    • You may choose to expand or add features to an existing product. If you choose to do so, be very clear about what parts you created, and what was already there.
  • All code written must be your team’s.
    • You may use whatever frameworks, libraries, and open-source code you choose, but there’s a clear difference between using a framework and turning in someone else’s work.
  • Hacking must stop when the hackathon is over.
    • Small fixes (debugging, last minute changes) are allowed after the official stop time, but any major modifications are not.
  • For judging purposes, your code must be publically available on Github. We will use it to verify all the rules and deadlines of the competition were followed. All winning teams may be subject to a code review.
  • Please follow the MLH Code of Conduct. This code is pretty straightforward; don’t make/do something inappropriate.
  • All submissions remain the intellectual property of the individuals or teams that made them.

Submission, Demo, and Judging

    • When submitting your project you must provide a Github link to the source code.
    • All teams competing for prizes will be required to give a short (2-4 minutes), live demo of their products.
      • Everyone is encouraged to demo, even if you didn’t finish. Completeness is only a portion of the judging criteria.
      • This is a chance to learn from other people and show off what you did and learned. There’s no downside to it - you only hurt yourself for not demoing.
    • Do not try to ‘pitch’ the product to us or give us a presentation, just show us the cool thing you built!
      • Try to avoid using PowerPoints, Prezi, or related tools which take away from the demo of your final product.
    • Judging will be based on the following criteria. When demoing, try to go through each of the following points. These criteria are directly taken from the MLH handbook:
  • 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.
  • 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?
  • 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"? 
  • Judging will NOT be based on the following criteria:
    • Cleanliness/formatting of code. No matter how inefficient, undocumented, or ‘hacky’ it looks, the entire point of a hackathon is to mess around with new ideas and learn from it.
    • The pitch/presentation. Yes, you are required to demo your product to be eligible for awards, but at hackKU we think coding and learning is more important than selling a product. We don’t expect all teams to have an amazing, well-rehearsed speech.
    • The scope, usefulness, or innovativeness of the project. You can create the most pointless, specific, or repeated project ever, but as long as you enjoy making it and learning from it, it’s a good project!
  • The judges will have these guidelines, but ultimately their decisions are up to them and their opinions on which project is the most impressive or deserving.