You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some initial thoughts on deprecating Rotations in favor of making Schedules "smarter".
RFC: Merging Schedules and Rotations in GoAlert
Overview
GoAlert currently manages on-call responsibilities through two separate systems: Schedules and Rotations. Schedules consist of rules (assignments) such as day-of-week filters and optional time windows, which can target either a user or a rotation. Rotations are simple lists of users that rotate based on time intervals.
Current Issues
Always-active rotations: No way to restrict rotations to specific days or hours, requiring manual management.
User confusion: Schedules and rotations can both be assigned to escalation policy steps, and users sometimes get confused about which to use, especially since only schedules have temporary overrides.
Complex rotation code: Rotations rely on database triggers, which makes them hard to maintain and prone to deadlocks. Joining across multiple tables adds complexity when calculating schedules.
Limited future on-call data: Rotations don’t expose future on-call information, which limits integration with external systems that need this data.
Proposed Solution
I propose consolidating rotations into schedules, enhancing schedule functionality to cover all use cases of rotations. The benefits of this solution include:
Deprecating rotations while maintaining compatibility for existing systems, ensuring gradual migration.
Simplifying scheduling logic by storing all configuration in a single JSONB field in schedule_data, removing the need for table joins and database triggers.
Improving future on-call data visibility by consolidating all scheduling logic under schedules.
Long-Term Compatibility Plan
To minimize disruption, rotations will remain in the codebase for a period of time:
Opt-in configuration: Introduce a configuration option to disable new rotations creation. Initially, this will be opt-in, allowing early adopters to transition to schedules.
Opt-out configuration: In a future release, the creation of new rotations will be disabled by default, with the option to opt back in.
Complete removal: Eventually, rotations will be removed entirely, and a newer version of GoAlert will refuse to start or migrate if rotations are detected.
Auto convert/migrate: Include an admin option for bulk migration of existing rotations to schedules when the auto-convert functionality is built.
Migration Strategy
Deprecate Rotations:
Add a confirmation before assigning a rotation to an escalation policy.
Provide a "Convert to Schedule" link to migrate rotations into schedules.
Enhance Schedules:
Allow assigning multiple users to a schedule at once.
Add rotation logic into schedules (active shifts, pauses, flexible intervals).
Gradual Feature Rollout:
Introduce opt-in config to disable creating new rotations.
Later, change this to opt-out so rotations are disabled by default.
Eventually, rotations will be removed entirely.
Bulk Migration Tool:
Develop an admin tool to bulk migrate existing rotations into schedules.
Database Considerations
Expand the existing schedule_data table (JSONB column) to support multi-user assignments and new rotation logic.
The text was updated successfully, but these errors were encountered:
Some initial thoughts on deprecating Rotations in favor of making Schedules "smarter".
RFC: Merging Schedules and Rotations in GoAlert
Overview
GoAlert currently manages on-call responsibilities through two separate systems: Schedules and Rotations. Schedules consist of rules (assignments) such as day-of-week filters and optional time windows, which can target either a user or a rotation. Rotations are simple lists of users that rotate based on time intervals.
Current Issues
Proposed Solution
I propose consolidating rotations into schedules, enhancing schedule functionality to cover all use cases of rotations. The benefits of this solution include:
schedule_data
, removing the need for table joins and database triggers.Long-Term Compatibility Plan
To minimize disruption, rotations will remain in the codebase for a period of time:
Migration Strategy
Deprecate Rotations:
Enhance Schedules:
Gradual Feature Rollout:
Bulk Migration Tool:
Database Considerations
schedule_data
table (JSONB column) to support multi-user assignments and new rotation logic.The text was updated successfully, but these errors were encountered: