Skip to content
HackWinnerDB

Methodology

Trust is the product. This page describes exactly how records get in, how they are checked, and where the data falls short.

What qualifies as a hackathon winner

A project qualifies when it received a named award at a hackathon — a grand prize, a placement, a track or category win, a sponsor prize, an audience or community choice award, an honorable mention, or a finalist placement.

Participation alone does not qualify. Neither does a project that was merely featured, shortlisted informally, or promoted by its own team.

Accepted sources

Every published entry carries at least one publicly accessible source that confirms the award: an official winners page, a platform winner gallery, an organizer announcement or blog post, an official social announcement, or a project page that clearly shows the award.

Self-published claims with no corroborating organizer source are recorded as unverified or rejected.

Verification

Records enter the database either through community pull requests or automated discovery of public hackathon galleries. Auto-imported records land with an unverified status (displayed on the site as 'Source pending review') until a maintainer opens the source and verifies that it corroborates both the project and the award.

Once human-checked, the date of that review is recorded on the entry as checked_at and shown on the project page.

Sources rot. If a link dies, the entry keeps its record and the status can be moved to disputed until a replacement source is found.

Categories and technologies

Categories and technologies are controlled vocabularies, not free-text tags. Adding a new one is a deliberate change to a taxonomy file, reviewed like any other change.

This keeps filters meaningful: a single technology cannot silently split into five spellings.

Duplicates

One project can enter many hackathons, so projects and awards are stored separately and linked by an entry. Only one entry may exist per project and hackathon pair.

A duplicate checker compares normalized names, repository URLs, website domains, and submission URLs on every pull request.

Corrections

Anyone can open a correction issue or a pull request against the offending YAML file. Corrections that come with a source are merged quickly.

Limitations

Coverage is uneven by design: the database grows where contributors are. Early data skews toward large online hackathons with public winner galleries.

Prize amounts, participant counts, and submission counts are only recorded when the organizer published them.

Summaries are written by contributors, so tone varies. They are deliberately short and original rather than copied from the source.

Community contributions

Everything above is enforced in the open: schemas, validation rules, and review happen in the repository. See Contribute or the GitHub repository.