...
| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Scheduler
| Status | ||||
|---|---|---|---|---|
|
Currently the draft schedule is a self-contained entity that makes it difficult for associations to schedule games across multiple schedules, as they’re required to go into each individual draft to make changes.
A redesigned draft scheduler introduces a new DraftGame entity that’s similar to Game, which draft games far more flexible than the current implementation. This also necessitates changes around team ordering and game number sequencing as these were handled within the draft which would no longer exist.
...
Infractions
| Status | ||||
|---|---|---|---|---|
|
Originally infractions were actually hardcoded in the app, and every change to infractions required code changes. When ball hockey was introduced, the “rulebook” was created to unhardcode the penalties, but it basically moved the structure that was in the code into the database and retained a limitation that each infraction did not have an ID since existing penalties didn’t have this.
While this generally works, it’s realistically a really hacky solution as references to any infraction require the rulebook (which can technically vary by office) to be able to resolve details like the name and severity, instead of just referencing by an infraction ID.
There are also potential issues such as a branch extending the infractions to specify their own code would override the default code which may not be desirable in reporting, and linking penalties (5+GM) is not as efficient as it could be. Further, creating rules for each suspension is significantly more ineffective.
A more appropriate solution is to normalize the relations so that penalties are linked to infraction IDs, then it’s much simpler to extend infractions if necessary while retaining reporting flexibility, link related penalties together and create suspension rules based on infractions.
...
Suspensions
| Status | ||||
|---|---|---|---|---|
|
...
Since we’ve introduced tournament and cup offices, we can reliably move assigner determination to be a office or schedule setting instead of being an assigning rule, as the rules were primarily based on the schedule type.
...
Positions
| Status | ||||
|---|---|---|---|---|
|
...
A lot of the feedback we’ve received works well together if we move from game assign settings to per-official settings.
Custom official positions
The hardcoded enums are insufficient for more advanced assigners who want to be able to create ordered positions (Referee 1, Referee 2), more descriptive positions (Scorekeeeper Supervisor) or just entirely custom positions (Video Official).
Qualifications
Since we have qualification categories, this doesn’t create a problem to match eligible officials, but we will need to rethink other settings are implemented, such as the minimum levels and pay structures, which rely on the enum positions.
We should consider creating a Qualification model that aligns with SID, which would allow Play to control how qualifications are numerically compared, since currently SID manages it with an obscured display order property.
Grades
A potential problem of changing levels to qualifications is that grades start to get neglected. We should consider how to move a grading requirements system to be based on attributes.
Custom systems
Assigners want the freedom to be able create custom systems as they please instead of using standardized systems that Play provides.
Assignment settings
| Status | ||||
|---|---|---|---|---|
|
There are some new feature requests that require a rethink of how we define settings at the office and assignment levels.
A lot of the feedback we’ve received works well together if we move from game assign settings to per-official settings.
Delegation
This was a last-minute high-urgency request that was implemented without sufficient design consideration. It has a number of ugly limitations because it’s implemented directly on the official, which means it’s limited by the scoresheet, which is something the game assign settings are not limited by.
...
Assigners also need the ability to specify criteria to delegate positions automatically that they would otherwise be responsible for.
Custom systems
The idea in delegation that each position should have it’s own settings is related to another piece of feedback we’ve received which is that the current “assign systems” are too limiting. Assigners want the freedom to be able to add/remove positions as they please.
If we’re to move game assign settings to become per-official settings, the system ends up being the odd property out because it doesn’t relate to any one official while the others do (office, min level/grade/age, fee and status).
Assign fees
Currently changing pay structures mid-season is a pain because the relation already exists between games. We limit changing pay structures in this case and force creation of a new pay structure instead.
A more optional solution would be that the fee is defined in the category settings and a relation isn’t necessary. When editing game settings, we could be smart about recommending a value if they make changes instead.
Position-based Settings
If we’re to move game assign settings to become per-official settings, the system ends up being the odd property out because it doesn’t relate to any one official while the others do (office, min level/grade/age, fee and status).
...
Categories
| Status | ||||
|---|---|---|---|---|
|
...