...
| 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 | ||||
|---|---|---|---|---|
|
Once infractions are implemented, we can start to implement automatic suspensions for hockey. While soccer and baseball infractions are very simple which made it easy to implement existing suspensions, hockey has a much more complex structure of infractions and suspensions.
This involves defining a list of sanctions related to infractions which will be flagged as suspensions.
...
Assigning rules
| Status | ||||
|---|---|---|---|---|
|
Rules were designed from a complex standpoint that different assigners have very different and complex needs, with the intent of getting to a more simplified point, but this has proven impossible.
...
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.
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 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.
...
...
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.
...
Categories
| Status | ||||
|---|---|---|---|---|
|
Categories were originally modelled after HCR 2.0 categories, which had a division, gender and category separately. Spordle ID (HCR 3.0) introduced a more normalized category model, which Play has been gradually migrating, however this requires a three-phase approach:
...