Click and Drag for Track Judging

[balebbae]

Describe the feature you'd like

Would be nice to have the drag and drop ranking system for tracks, not only general.

Pre-existing Issue or Justification

Tracks only support star based scoring and would be nice to have the ranking one too. At Axxess we only found out there was no rank judging for tracks once we started 😞.

Additional context

No response

[MichaelZhao21]

Okay there's a decent amount of history for this. I did a bit of digging bc it's been a while. This actually was a feature that was implemented in #167. However, it was then removed in #218... unfortunately I did not document why it was removed but a lot of it came down to simplification. The code was, well, a fuckin mess. That's what #218 cleaned up a lot of and er I think at that time it was a ton of changes at once bc we were in a hurry so it's a bit of a disaster.

I also did not write documentation on how the ranking system works, so I guess I'm to blame for the lack of info. The actual rankings themselves is pretty simple (oh wait I did explain this in https://jury.mikz.dev/docs/usage/admin/scoring#ranking), but I didn't explain how projects are actually assigned to judges. There's a big matrix that's created (see server/judging/comparisons.go), stored in-memory on the backend, that keeps track of a matrix of each project and which judges have seen those projects. Using this matrix, for a judge picking a new project, we assign the project that would produce the maximum number of new comparisons for the project with all other projects.

It's not extremely important to know the details, but what is important to know if that track project assignment does not use this algorithm. That algorithm was created to balance the rank aggregation algorithm we use because we are aggregating partial rankings. However, for tracks, because we are just counting number of stars, it doesn't really matter so we just make sure each project is seen X number of times and then we are done.

I agree that this is something we would eventually need but for the original use case, having only general judging was good enough. That being said, if we were to add rankings to the tracks, it would mean that we would need to create a comparisons array for every track and so it would be a dictionary/map of the comparison matrix objects, which in of itself are already complex:

type Comparisons struct {
	Arr      [][]int                    `json:"arr"`
	IdNumMap map[primitive.ObjectID]int `json:"id_num_map"`
	Mutex    sync.Mutex                 `json:"mutex"`
}

With the current way we're passing/storing data in context, this is honestly a bit unwieldy in the long run. I'd love to discuss how to refactor the code to make this more feasible. It's definitely possible to add it in the current state of the code, but it'd make fixing bugs and stuff pretty complex.