VerifiedHacks

Track

Education

Inspiration

As a director at HackHarvard, a group member observed how fast-paced judging timeframes at Hackathons sometimes didn't have the infrastructure in place to consistently filter out cheating or invalid projects; notably, a few teams had actually won up to 10 hackathons this year before they were caught by deepchecks. And as this type of behavior disrupted authentic collaboration and the hackathon educational experience, we wanted to offer an accessible solution that would verify hackathon submissions. This way, there would be added incentive for hackers to genuinely do their best.

What it does

VerifiedHacks takes an input of the hackathon start time and a list of submitted repositories as a starting step. It then runs checks on each repository's date, time of commits, number of commits, and compares against DQ repositories. Using these criteria, VerifiedHacks flags individual repositories as "valid", "unsure", and "invalid" based on the number and severity of suspicious characteristics. // EDIT BASED ON WHAT WE HAVE AT 12:20

How we built it

Frontend-wise, we first used Figma to create mockups for the website functions and surface before implementing the prototype using TypeScript, HTML, and CSS. When it came to less user-visible aspects, we were primarily concerned with the details of getting relevant information from each user-submitted Github repository link, as well as running the checks correctly. To do this, we pinged Github's API to retrieve repository details and compared processed information against internal criteria.

Challenges we ran into

We underestimated how much overlap there would be between individual team member skills vs. the total ground we had to cover; specifically, we had more UI/UX and frontend specialists than backend support. This meant that each team member had to take their already acquired skills and adapt them to work on tasks outside of their comfort zone, such as by asking JavaScript/HTML/CSS programmers to learn TypeScript for frontend, or by having backend Firebase hackers implement checks using a more straightforward Github API-focused method instead.

Accomplishments that we're proud of

We're proud of how we put together an earnest collaborative effort despite being a hybrid team split across several timezones. Specifically, each member's willingness to learn helped us create a strong project idea and prototype that we put our all into implementing.

What we learned

Think big but practice realistically! For instance, we aimed high with our Figma mockups knowing that not all the aesthetic elements (such as the detailed custom loading screens and typefaces) would make it to the finished product by the end of the hackathon. After all, our general approach was to put down a wealth of ideas that we could then choose specific ones to focus on later. We learned that this type of mindset makes for a fairly challenging and educational experience, and in the future, we could even narrow things down a little more in the beginning.

What's next for VerifiedHacks

We liked the direction of VerifiedHacks and felt that its potential was constrained solely by the duration of the hackathon, so we'd like to add more features once free to work on it over a longer period of time. Firstly, we wanted to add more criteria for validity, such as by comparing submitted project code to other repositories' code under the submitting person's Github. Secondly, we would also add a "toggle criteria" feature so that organizers can select which rules to apply when determining authenticity. Thirdly, we also wanted to streamline the frontend appearance so that users can easily access all their repository results in a cleaner table.