Distribution of delegates by name or rank

[AnnikaStein]

Hi,
In all competitions I acted as competitor and delegate, we noticed a peculiar pattern. While „usual“ competitors without dedicated staffing role are correctly distributed into groups when sorting by their ranks, delegates seem to be assigned by name instead. It may be a coincidence, and I am not sure I fully understand the logic yet to tell if a results-based assignment should in principle be there for delegates / organizers already.

Suppose following example:
Delegate 1 („Alice“) is better in 3x3 than Delegate 2 („Bob“). However, in 2x2, it’s the other way around.
Expectation: D1 competes in a faster (later) group for 3x3 than D2, with opposite treatment for reversed relative ranking (2x2).
What we seem to observe is that Delegate 1 with alphabetical ordering is assigned always in the faster group than Delegate 2, as Alice comes before Bob when using descending time similar to descending name string.

The questions: is this just coincidence and no such alphabetical ordering for staff is applied, or is this always the case and can we change this to the more intuitive sorting by results also for staff? Can we treat trainee-delegate as part of delegate for that matter? Or even make it configurable?

It should have something to do with how the overlapsEveryoneWithSameRole comes after the initial competitor sorting inside assignGroups.
Thank you.

Best,
Annika

CC: @LauraHolzhauer

[jonatanklosko]

Hey @AnnikaStein :) I don't think it is related to alphabetical ordering, however there are cases where a faster delegate is moved to a slower group. The group assignment goes through competitors worst through best and puts them in groups worst through best. However, for delegates, scoretakers and organizers there is a special rule.

Let's say we have delegates D1 D2 (ordered worst to best) and groups G1 G2 G3. We assign people to G1, no delegate there. We keep assigning, we put D1 in G2. Now we need to assign D2, but since D1 is in this group, we don't want to put them together so we move D2 to G3 (upgrade). But, if there were only two groups, we would instead move D3 to G1 (downgrade), and someone else from G1 to G2. In other words, this unexpected ordering happens if all delegates should be in the last group.

The assignment algorithm takes a lot of things into consideration and I don't think there is a straightforward fix to address this specific case. At this point I prefer not to mess with the assignment logic too much.

[AnnikaStein]

Hey @jonatanklosko ! Thank you for your instructive answer, it's good to know how this happens and when exactly. Now I do also understand that this would be a non-trivial fix indeed.

[jonatanklosko]

Note that you can use the manual group editing to adjust assignments, not ideal to do it manually, but always an option.

[Jobarion]

Would it be possible to not change the way assignments work, but to instead have a second pass after the assignments to swap delegates around until they are in the correct order (if possible)? If we have D1 D2 ordered worst to best and Groupifier assigns them to G2 and G1 respectively, it should be okay to just swap them. If this is acceptable, I'd give implementing it a try.

[AnnikaStein]

Would it be possible to not change the way assignments work, but to instead have a second pass after the assignments to swap delegates around until they are in the correct order (if possible)? If we have D1 D2 ordered worst to best and Groupifier assigns them to G2 and G1 respectively, it should be okay to just swap them. If this is acceptable, I'd give implementing it a try.

From user perspective, this sounds perfectly fine - it's our thought process when updating the assignments manually. I just don't know how long the second pass takes w.r.t. what is needed already to compute assignments. But ideally, sorting this smallish amount of special case people shouldn't change the overall time consumption or the way this scales to large comps (?)

[jonatanklosko]

@Jobarion I'm pretty sure doing a post-processing like is going too much complexity (code-wise), which I'd rather avoid. There are some edge cases like if groups overlap partially with other events (FMC), where Groupifier tries to assign the group where the person is most available; obviously that's a rare case, but the point is that would need to account for things like that in the separate pass. Feel free to experiment, but unless there's a simple fix I would not change the existing logic (especially that there are a lot of considerations and there are no assignment tests :<).