Restructure model so Hacker is nested under Account

[logan-r]

First part of refactor that will move Hackers, Organizers and Sponsors so they are nested under accounts. This will simplify rolebindings and move us away from the current relational structure. Middleware, validators and other appropriate parts of the source will need to be updated to reflect the new structure.

[krubenok]

Infinite +1's to this.

A consideration for whoever ends up taking this on would be to think about the lifecycle of a user year to year. A very large portion of hackers will at least apply (if not attend) for 2 or 3 years, thinking about how we can better design the schema to remove friction from later years would be great.

For example, I manually duplicated several fields from the McHacks 6 database into the one for McHacks 7. This repopulated a lot fo fields like school, major, GitHub URL, etc... so that applicants simply needed to confirm that nothing changed. Some of these fields we probably don't need to save year to year (i.e. we only want the latest Github URL) whereas fields like their "Why McHacks" essay we might want to maintain the different responses from year to year. Maybe the instance of a the hackathon is nested within the hacker object?

Migrating the database to the new structure is likely out of scope of this issue, but in designing how the hacker information is stored, making sure that the new structure is compatible for migration from the old structure would be good. I'd be toying around with the concept of a "hackathon_id" so that one database can span multiple instances of a Hackathon while connecting hacker data between them. Again, beyond the scope of this but having this in mind might help to prevent creating tech-debt for a longer term feature.

[pierreTklein]

This is going to be a Herculean task, but def worth it. I would recommend creating a new branch to work on this, with many PRs going into that new branch.

This will affect almost every part of the API, so this task really should be broken down into sub-tasks on a service-level. This migration will definitely need a design doc too.

[logan-r]

Good points, I'll write up a design spec and break this into smaller issues.

With regards to the migration, the current plan is to not migrate any past years' data, instead storing them offline. This will ease migration and leave us with less data to pay for but the downside of this is that hacker accounts will not persist from previous years.

Looking forwards to supporting future years, accounts will be subdivided by year in order to add capability to reuse accounts between years like so:

account: {
    ...account level info
    2021: {
        organizer: {
            ...organizer info
        }
    },
    2020: {
        hacker: {
            ...hacker info
        }
    }
}

With this previous application answers could be preloaded from the last hackathon the account attended. I really like the idea of hackathon_id instead of the year number as the above design has the major flaw of limiting to one hackathon per year. Also, eying a potential goal of making this a platform any hackathon can use out of the box, this would support that too (not sure if this is a useful goal at all, but the process of stiving to make this a white-labelable platform might be a useful undertaking in order to refine the codebase).

Also, all endpoints will stay the same with the exceptions of teams and travel (which need large refactors anyways) and the removal of hackerid, sponsorid, etc. in favor of a universal accountid so updates to dashboard will be minimal.

[krubenok]

With regards to the migration, the current plan is to not migrate any past years' data, instead storing them offline. This will ease migration and leave us with less data to pay for but the downside of this is that hacker accounts will not persist from previous years.

This is unfortunate, but I do think it's understandable this years since the database migration will be a lot more complex than last year (though it would still be cool to have it as a stretch goal! if only the usernames/passwords and not the rest of the information). It might not actually be that painful to maintain just the accounts level information since that's the one part of the db that isn't going to change all that fundamentally.

The structure you proposed there looks good, and I do agree that hackathon_id is more flexible than year. It would be cool if when applying as a hacker, the API parsed through all of that accounts previous hackathon_id objects to retrieve the most recent Github URL, School, Program, etc... but even that exposes a whole new set of issues, for example, what is the most recent hackathon_id if it's not just a year. Perhaps there does need to be a companion table storing metadata about each hackathon_id such as the date. Alternatively, maybe fields that we see as worthwhile to carry-over from year to year aren't in the hacker sub-object at all but are instead an optional section in the account object that is populated at the first instance of that user being a hacker. Perhaps:

account: {
    ...account level info
    profile: {
        GitHub: ...
        LinkedIn: ...
        etc....
    }
    2021: {
        organizer: {
            ...organizer info
        }
    },
    2020: {
        hacker: {
            ...hacker info
        }
    }
}

I'm not convinced this is the best route but it came to mind as a way to keep only the recent profile information and not have an overly complicated API to auto-populate new things on the n>2'th year.