On our 3-day hackathon, projects are not just presented, but also tested by other participants. The hackathon has two main phases:
- Make: build the best project possible
- Break: showcase and let other participants test your finished project
Participating teams must have between 2 and 4 elements. Each team shall build something that's interesting for them and that they can showcase.
At the end of the hackathon, we’ll have a fair where participants will have the opportunity to experiment and vote for each other’s projects. The registration to the hack fair will happen in the last day, at the beginning of the afternoon. As we need to setup the booths to the fair, we advise you to stop coding by that time, but we will not enforce it (you can code until the end of the fair).
Projects can be voted on 3 different categories:
- Useful: projects you could see yourself using or create social value
- Fun: projects that are entertaining or generally make people happy
- Creative: projects that implement new ideas or new solutions to known problems
By the end of the hack fair, we’ll announce the three most voted preferred
project in each of the categories.
Make or Break is a free event and everyone can apply in a team of 2 to 4 elements.
It’s expected that each team will be actively building a software, hardware, or hybrid project to show off at the fair.
At the fair, all of the members of your team are expected to divide their time between showcasing their team’s work and voting for other projects.
Seating is limited, be sure to grab yours at makeorbreak.io
Without a team, you are not able to apply to the hackathon. However, you can still register to gain access to our Slack community and find a team before the event starts. If you're having trouble, let somebody from the organization know in Slack, and we'll help you out the best we can.
Excluding people from participating in the event is something that pains us greatly, and we didn’t make the decision lightly. The reasons why we don’t allow teams of 1 are:
-
You won’t have the best experience: this is the 5th event we organize, and we’ve already talked with enough lone rangers who expressed some regret about applying alone and wished they were enjoying the event to the fullest.
-
We are not certain if you are going to show up: motivation is not always at its peak, but a motivated team can boost an individual’s motivation. With every seat counting, our goal to is to minimize our no-show rate, and individual applications have a higher no-show rate.
-
The number of projects does not scale well: with 250 participants, we want to make sure every project gets the spotlight it deserves. However, that’s already an impossible task, as there’s always the need to cut down the number of projects presenting to the public.
There are always exceptions to every rule. Unfortunately, with limited resources, we have to optimize our rules to enhance the odds of success and make exceptions as we see fit. If there’s something that can change our minds for the next edition of Make or Break, we want to hear it!
Make or Break is split between two main phases: Make and Break.
Make is the hackathon, where people hack on things together, as a learning and collaboration experience, to try out things they normally wouldn’t work with.
We want Make or Break to be an experience that’s both fun and edifying for everyone. We’re firm believers in the value that free/libre open source software can bring to the table for achieving this end, and we'll rally around it as much as we can.
The code (and any other produced artifacts) will belong to the participants. However, in the interest of keeping everything hackable and accessible, projects are required to be under an OSI approved license and unencumbered by any IP restrictions (like patents, among others). This way everyone can peek into any of the projects and learn from them, take them home to learn more, and even expand on them. Perhaps they’ll have something cool to discuss with you!
In the interest of keeping things level, we’re only allowing to incorporate free/libre open source software that’s publicly available before the competition begins. We don’t have any issues with people using popular software packages, but we’d like to avoid that teams bring a whole project along when others couldn’t have done the same. If you have a non-trivial codebase you’d like to use on your hack, make sure it is publicly available under an OSI approved license and unencumbered by any IP restrictions before the competition begins. This way everybody starts equally as far from the finish line.
In order to assure that all code is available to everyone, participants must use the GitHub repository provided by the organization. Nuking the repository and force pushes will be disabled. This ensures that we’ll have a copy that we can make available to everyone and that we can preserve for posterity.
Not using the repository will disqualify the entire team from winning any prizes. If a team has any problem with this setup they must convene promptly with the organization as soon as possible, to find a way to avoid disqualification. We will have a workshop on git during the first day of the event to help you get acquainted with these tools.
The organization will provide free hosting for teams that could give it some use. Talk to the organization for more details.
Break is the "hack fair", where teams demonstrate what they’ve built during the Make phase, and all the participants vote on each other’s work in the categories of the voter’s choosing. When the voting comes to an end, we’ll crunch the numbers, announce winners, and award prizes.
A subset of the organization will go through each team to double check their project submission and remind participants of the voting requirements and process.
Every competing team member must vote in every category. Not voting may disqualify their entire team from winning any prizes.
If any team members are unable to be present or to vote, they must convene promptly with the organization as soon as possible, to find a way to avoid disqualification.
We’re going to have 3 categories:
- Useful: you see yourself using it or it creates social value
- Fun: does not have to be useful, it has to entertain or make people happy
- Creative: a new idea or a new solution to a known problem
When you cast a vote on somebody, you also choose the category. You can vote for a project in more than one category. The project owners might suggest categories to be voted on, but it’s completely up to the voter to follow that suggestion.
There will be prizes for each member of the winning team in each category.
- Useful: Dell Monitor U2515H
- Fun: Nintendo Switch
- Creative: Bose QuietComfort 35
Each category has their own independent voting system. This means that voting in one category in no way influences the winners of the other categories.
For each category, voters are allowed to vote on up to three projects, in order of preference. When the ballots close, we sort the projects by their ranking, where ranking can be determined by Schulze method.
Breaking ties in the Schulze method takes various forms, each with their pros and cons. We've decided to keep this simple and break ties randomly, since all the winners are equally preferred by the audience. Before the voting begins, we'll publicly assign each team a "tie breaking dice roll", and use that in case we have to.
A team can only win one prize. If a team wins multiple categories, they'll win their preferred prize, and the second best team in the other categories will take the remaining prizes.
In order to avoid prize rigging, we'll be asking each team to declare their prize preference before we open up the votes. If a team fails to report their preference in time, we'll randomly assign them one.
At the end of the competition, we will publish the set of votes associated with anonymized identities. This will allow voters to verify that their vote is included in the list and that the number of votes matches the results. The anonymization process guarantees that each participant is able to verify that their votes are uniquely identified.
The audit log is a text file with two sections. The first section contains a
line for each participant, with their email in it, in alphabetical order. The
second section, separated by an empty line from the previous one, contains a
line for each participant, containing the anonymized_identifier_hex (which is
hex(HMAC(nonce, email)), where nonce is assigned to you at registration time)
and the list of projects they voted on, in decreasing order of preference. The
second section is sorted in alphabetical order as well.
Sample audit log:
hugopeixoto
jpmcosta
jvalente
mario
nunopolonia
pkoch
2f4a51d05ded4f7a2aecc3d59082ecb9 proj1 proj5 proj2
6017886db43c7102a5b7a030488a4242 proj4 proj3 proj3
93026da4be536ac8cd2d9331276640b8 proj1 proj3 proj6
7db7f4fc3575b404275b53f1383f5a69 proj2 proj4 proj5
c0092829631f39f6dc34cb506cf05b17 proj1 proj2 proj5
f8fafa57ef507152eff134a04f7ef2d7 proj5 proj1 proj2
During the event, we may want certain guests to have the ability to vote (sponsors, CMP collaborators, etc.). To make it easier for them to vote, without having to install apps or register on our website, we are planning on handing them a set of physical tokens that they can give to competing teams. Each token will have a unique identifier to avoid double counting.