tribeHacks IV Hackathon Rules

The spirit of the competition
Remember that hackathons are like marathons. Some people go to compete but most people take part to better themselves and have fun. Whatever the reason is you're at a hackathon, make sure you’re making the event better for everyone, by collaborating with other teams, helping beginners, and having fun.

The rules of the competition

  1. Teams can be no larger than four hackers, and it will be the responsibility of the team to split prizes evenly between members. tribeHacks will not mediate disputes over prize money.
  2. Teams should be made up exclusively of students (or recent graduates within one year of having graduated) who are not organizers, judges, sponsors, or in any other privileged position at the event.
  3. All team members should be present at the event. Leaving the venue for some time to hack elsewhere is fine. Teams should be present at the opening ceremony and closing ceremony.
  4. Teams can and should gain advice and support from mentors, organizers, volunteers, sponsors, and others.
  5. All work on a project should be done at the hackathon.
  6. Teams can use an idea they had before the event.
  7. Teams can work on an idea that they have worked on before (as long as they do not re-use code).
  8. Teams can use libraries, frameworks, or open-source code in their projects. Working on a project before the event and open-sourcing it for the sole purpose of using the code during the event is against the spirit of the rules and is not allowed.
  9. Adding new features to existing projects is allowed, however, make clear to the Judges which features were added during the hackathon. Judges will only consider new functionality introduced or new features added during the hackathon in determining the winners.
  10. Teams must have their projects submitted to the devpost by 6 am on Sunday, March 25th. However, teams are allowed to debug and make small fixes to their programs after time is up. e.g. If during demoing your hack you find a bug that breaks your application and the fix is only a few lines of code, it's okay to fix that. Making large changes or adding new features is not allowed.
  11. Projects that violate the Code of Conduct are not allowed.
  12. Teams or individual team members can be disqualified from the competition at any time at the organizers' discretion. Reasons might include, but are not limited to, breaking the Competition Rules, breaking the Code of Conduct, or other unsporting behavior. The organizing team is under no obligation to provide reason for disqualification.


Demos
After hacking finishes, teams will show their projects to each other and to the judges. You are strongly encouraged to present a demo of what you have built. You should 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.


Judging Criteria
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.
Entrepreneurship: The project's potential beyond the hackathon: does this project have commercial viability? Projects with the greatest entrepreneurship are not necessarily the projects with the highest potential profitability, but that satisfy consumer needs.
Ingenuity: This incorporates creativity and originality. Projects with high ingenuity should be unique, and solve a problem in a novel and effective way.
Completeness: How much did the team do with their time? Projects that score highly should be polished and fully functional.
Presentation Quality: Was the presentation thorough and convincing? Well presented projects are compelling and have complete and rehearsed presentations.
Complexity: Was the project of a high technical difficulty? High scoring teams are ambitious in their undertakings.
Judges’ Impression: Did the project stand out to you? What was your overall impression?
These criteria will guide judges but ultimately judges are free to make decisions based on their gut feeling of which projects are the most impressive and most deserving.


Remember!
The competition is just a part of the hackathon. To make the most out of the event, try something new, teach other people, and make new friends!