Goa Hacks 1.0 – A 24-hour hackathon encouraging playing around, making mistakes and learning new things.
The 24-hour hackathon begins on the 27th of September, with participants reporting at 91 Springboard at 10:30 am.
There are no restrictions on the use of libraries, frameworks, or open-source code however, handling the work before the event would is frowned upon.
The hackathon will be judged on four criteria; technology, design, completion and learning.
Teams can gain advice and support from organizers, volunteers, sponsors, and others.
All work on a project should be done at the hackathon.
Teams can use an idea they had before the event.
Teams must stop hacking once the time is up. 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.
After hacking finishes, teams will show their projects to each other and to the judges. Each team will be given 5 minutes to present their ideas. You are strongly encouraged to present a demo of what you have built. 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.
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”?
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.
Does the hack work? Did the team achieve everything they wanted?
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.
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.
All the participants will be given participation certificates. Winners will be given merit certificates along with the prizes.
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 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.