You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The objective is to schedule all of the teams into their judging categories within the judging timeframe with a reasonable judging windows (time per team).
Considerations
Stipulations to scheduling makes this problem harder. There are some rules we have to follow that adds layers of complexity onto an already hard problem. A current but not exhaustive list is:
Some judging categories can have multiple judging groups. This means two teams can be judged for the SAME CATEGORY AT THE SAME TIME, depending on how many judging groups there are. Each judging group can judge ONE TEAM!
Bitcamp People's choice award (based on likes on devpost) is not a real judging category and should not be scheduled
Virtual submission teams (not there in-person on judging day) are not scheduled
Each team should be limited to 3 Bitcamp prize categories. This means if they signed up for 5, you chop it off at 3.
This is not a simple algorithm. You should seriously think about how to approach this problem because there is no "easy" way to do it. Maybe there is, but then you are clearly smarter than me.
Feel free to use libraries to your advantage. For example, if you choose to use Python, pandas might be a good library to use.
Input
The input file is a Devpost .csv file of all of the project submissions. Here is last year's devpost submission file: bitcamp-2023-projects.csv
As you can see, many of the fields can be discarded. The ones you care about are the team name, prize categories, etc. One thing that might be good is to create an environment variable to hold the column name, since they may change and may be super ugly (e.g. might be "What is your name" instead of "name"). This makes the app more flexible in case things change, either this year or even in future years.
Output
The output schedule should be a list of teams and their judging categories + the time the judging category should be scheduled for. The schedule should be possible, meaning there is sufficient time to judge each team and that at any given time, there are at most the same number of teams judged as the number of judging groups available.
YOU SHOULD
You should generate an ID for each project and you should call it project_id (exactly as shown). This is because each submission is not given an ID by devpost automatically. You should generate a unique project_id for each project, and they MUST BE UNIQUE. The way you choose to do this is up to you, but "Project Title" is NOT ENOUGH because it does not have to be unique. It can be a combination of fields from the devpost CSV or it can be a uuid() generation call (Python) or a randomly generated one via a library of your choice.
Store the URLs for their project submission as a field
(OPTIONAL) keep fields that may be useful later including github links
Each team should also have a table number, although we are unsure what the tabling scheme is yet. It doesn't really matter because it's a pretty easy thing to do later once we have the table names figured out. The output should be json format and will be uploaded to DynamoDB. It should look something like:
This is flexible based on your implementation. It's just an idea to get you started. For example, instead of having time-start and time-end, you could just have time-start and having a judging slot time "length": 5 min. It should be documented and should make sense.
The text was updated successfully, but these errors were encountered:
Objective
The objective is to schedule all of the teams into their judging categories within the judging timeframe with a reasonable judging windows (time per team).
Considerations
Stipulations to scheduling makes this problem harder. There are some rules we have to follow that adds layers of complexity onto an already hard problem. A current but not exhaustive list is:
Previous Years
It would be very smart to consult the implementation last year to see what it looked like. Do some digging in https://github.com/bitcamp/hackathon-expo-app.
Strategy
This is not a simple algorithm. You should seriously think about how to approach this problem because there is no "easy" way to do it. Maybe there is, but then you are clearly smarter than me.
Feel free to use libraries to your advantage. For example, if you choose to use Python,
pandas
might be a good library to use.Input
The input file is a Devpost
.csv
file of all of the project submissions. Here is last year's devpost submission file:bitcamp-2023-projects.csv
As you can see, many of the fields can be discarded. The ones you care about are the team name, prize categories, etc. One thing that might be good is to create an environment variable to hold the column name, since they may change and may be super ugly (e.g. might be "What is your name" instead of "name"). This makes the app more flexible in case things change, either this year or even in future years.
Output
The output schedule should be a list of teams and their judging categories + the time the judging category should be scheduled for. The schedule should be possible, meaning there is sufficient time to judge each team and that at any given time, there are at most the same number of teams judged as the number of judging groups available.
YOU SHOULD
project_id
(exactly as shown). This is because each submission is not given an ID by devpost automatically. You should generate a uniqueproject_id
for each project, and they MUST BE UNIQUE. The way you choose to do this is up to you, but "Project Title" is NOT ENOUGH because it does not have to be unique. It can be a combination of fields from the devpost CSV or it can be auuid()
generation call (Python) or a randomly generated one via a library of your choice.Each team should also have a table number, although we are unsure what the tabling scheme is yet. It doesn't really matter because it's a pretty easy thing to do later once we have the table names figured out. The output should be json format and will be uploaded to DynamoDB. It should look something like:
The text was updated successfully, but these errors were encountered: