ClassChangeController multi-request revamp #2416
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Make the lottery accept multiple requests per student per timeblock with priority, specified by a list of StudentRegistration types.
This might be kind of unfair since all of their requests are now "stronger" than even the first request from a student with at least one class. However, it's calculated dynamically so the advantage disappears once they get their first class, and they don't get any extra priority when we try to kick students, mostly just because that part of the code is hard to reason about.
Classify requests by priority, calculate student happiness crudely, and flag potentially buggy requests.
Take note of the "badness" of the assignment, which is how much it overflows true class capacities, and add a "pessimism" parameter that makes the algorithm more conservative about guessing that everybody who wants to switch out will get to. This way the lottery can be tuned to not overflow classes. This is a hacky workaround to patch the confusing student-kicking algorithm applied to "fix" the greedy student-assigning process, which doesn't always manage to get enrollments below true class capacities.
This allows for better introspection (shell_plus can autocomplete the parameters names), alerts you if you misspell a parameter name, puts the default values right next to the option names, and generally shortens the code a little.
Separate "orig" and "base" enrollments and capacities, "base" referring to the state of enrollments after unenrolling students from classes they want to switch out from, so that enroll_orig and section_capacities_orig (among others) are consistent with each other about the state of enrollments, and so that we have the section capacities needed to print_stats accurately after assignments are saved.
- Make the previously hard-coded check-in room an option, and prompt for it as needed - Slightly paranoidly confirm which email to send the class changes email from - Text formatting
A lot of sums along some axes should have been "any"s.
|
I think merging main will fix the travis test error. |
willgearty
force-pushed
the
main
branch
9 times, most recently
from
5e141c9
to
be64bb4
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Let the class changes lottery accept multiple requests with priorities from each user, fix up the API and variable names, confirm email details with the user and allow them to customize it, and print more stats.
I haven't tested it yet because I don't have good data to test it on, so I don't think it should be merged yet (worst case we wait until Spring HSSP 2018 :P --- I am reasonably confident in my changes to the class change request form, which are completely independent), but it would be nice if somebody could look it over asynchronously.