MY-Hack is hosted in-person. MY-Hack’s theme is “Social Good”. We want MY-Hack to be an inclusive environment where you can learn new things, meet new people, and receive support with the end goal of creating a product for social good!
Event Rules:
Project Development
* No development may start before the actual date and time of the event. Any teams that violate this rule will be automatically disqualified. The first line of code should be written on or after the first day of MY-Hack after the team has registered. However, we encourage you to brainstorm ideas and create wireframes/mockups via our private Facebook group.
*Any software development tools, IDE, and/or programming language can be used for the event. If a team member uses a purchased tool licensed to him or her and the license is not transferable to other members, the member’s team must choose one available to all developer teams.
*To ensure a level field for all contestants, all code must be created only at the hackathon. You are permitted to use publicly developed and openly licensed API’s and SDKs for your project.
*You will only be able to use a pre-public release of a product in developing your project if you bring at least one extra version that can be used by other teams in the Hackathon and provide any user support needed to teams using the device.
*Project design/assets can be created prior to the start date of the hackathon. All assets should conform to the Creative Commons License agreement standard or are freely available and you have permission or license to use them. Proof of permission must be given upon request.
*Assets, SDKs, APIs or other tools or components available under a trial license may be used.
*A team can submit only one entry for the hackathon. Participation at the hackathon is subjected on a “per-team” basis meaning you are not allowed to be on more than one team at the event.
*Any intellectual property developed during and within the scope of the hackathon must be open source and licensed under one of the licenses referenced in https://opensource.org/licenses.
*The license selected by the team must be clearly listed in code (page per page) or a generic page announcing the license the application adheres to. The public code used inside your application should also list the licenses the code is subjected to.
*A team can use multiple licenses in the application. For example, the public code used could be licensed under the Apache license agreement whereas the code written by the team for the application licensed under the MIT license agreement.
*A team may not code applications that violate the code of conduct. For example, racially insensitive ideas for an application will automatically be disqualified.
Project Submission
*All teams should have a team name and be registered with Devpost.
*The Devpost team page listing should have the following:
*The team lead must list a mobile phone number on the teams DevPost page (after judging is complete the number may be removed)
*All team members will be listed with brief biographies.
*Short abstract of the project
*The hackathon theme (See https://my-hack.devpost.com/) and sub-category if applicable
*Answers to the following:
*What inspires you?
*What does the product do?
*What development tools, libraries, assets did you use to build iit?
*What challenges have you run into?
*A link to the application or recording of the working app on youtube
*How does the product facilitate social good?
*What did you learn in the process?
*All projects should be submitted to the devpost page before judging begins on the second day of the hackathon. Failure to submit will result in disqualification. should commit regularly throughout the hackathon to the team repository.
*All project submissions will be randomly code-reviewed. Applications will be spot checked by code reviewers. All the projects selected by the judges as finalists will be code reviewed to confirm that the code is original work created at the hackathon and all components and assets conform to the licenses allowed in these rules.
*When development ends, at least one member from each team will meet with the judging team for a brief review of their submission and to confirm that the team’s Devpost page has been correctly updated.