Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scheduling Algorithm #2

Open
cloudui opened this issue Mar 5, 2024 · 0 comments
Open

Scheduling Algorithm #2

cloudui opened this issue Mar 5, 2024 · 0 comments

Comments

@cloudui
Copy link
Member

cloudui commented Mar 5, 2024

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:

  • 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.

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

  • 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:

[
{
    "project_id": SOMETHING
    "name": "Best Hack Ever",
    "table": "A",
    "prizes": [
        {
            "category": "Bitcamp People's Choice"
        },
        {
            "category": "Bloomgberg Best Booty Hack",
            "time-start": "2024-03-05T12:30:45Z",
            "time-end": "2024-03-05T3:30:45Z"
        }
    ]
},
{...}
]

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.

@MoheEdeen MoheEdeen self-assigned this Mar 6, 2024
@devlai23 devlai23 assigned devlai23 and unassigned MoheEdeen and devlai23 Mar 6, 2024
@MoheEdeen MoheEdeen assigned MoheEdeen and unassigned devlai23 and MoheEdeen Mar 6, 2024
@cloudui cloudui assigned devlai23 and shahsalonik and unassigned devlai23 and shahsalonik Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants