[Change Requests] - Improvements

Overview

This epic bundles a set of change-request and work-package scheduling improvements requested. The core themes are: fixing work package activation date handling, adding automated Slack-driven deadline tracking, prioritizing change requests, tightening which edits actually require a CR, extending blocking relationships across projects, cleaning up dead "connect CR" backend code, and letting declined CRs be revised instead of discarded outright.

Stakeholders

Product Stakeholder: @chpy04
Software Stakeholder: @wavehassman @chpy04
Reference Users: @jr1221

User Story

As a project head, lead, and admin, I want the change request and work package system to track deadlines automatically, prioritize CRs sensibly, and reduce friction on both automated and manual paths, so that work packages stay realistically on schedule without me having to manually chase every timeline slip.

As a member, I want my change requests to be prioritized by severity and to be able to edit declined change requests, so I do not have to make new ones.

Success Metrics

• Decreased average time a work package spends in a late state, aka past its start date without activation, or past its end date without a stage gate
• Reduction in declined CRs that are abandoned rather than resubmitted
• Decreased average time-to-review for high-priority CRs relative to low-priority ones
• Reduction in WPs that miss their start or end date with no CR ever filed (a "silent slip" count)
• Fewer late-discovered cross-project delays

Rollout Plan

Phase 1: WP Activation Modal & Buffer Window

• Activate WP modal defaults start date to the actual current date (configurable), with live Gantt sync
• Buffer-window auto-update on activation (admin-configurable threshold in Project Configuration); outside the buffer, the modal's submit button becomes "Submit CR," which creates a self-approved Activation CR and sends a Slack message to the team channel with the old/new start date

Phase 2: CR Governance & Data Model

• Computed, persisted triage score (plus snapshotted blocking count/start date/duration) exposed as a sortable column in ChangeRequestsTable.tsx
• CR exemption: project edits other than budget, timeline, and deliverables no longer require a Standard CR
• Declined-CR edit/resubmit flow (creator-only edit action, pre-filled from the original proposed changes, resubmit posts to the original Slack thread, re-adds original requested reviewers)
• Remove all backend "connect existing CR" routes/services/schema fields

Phase 3: Deadline Notification System

• Day-before/day-of/day-after Slack pings at 5pm for both WP start dates (activation) and end dates (stage gate), each gated on "not already activated/stage-gated"

Phase 4: Cross-Project Blocking

• blockedBy/blocking relationships allowed across projects on the same car
• Checkbox on the CR creation form for a delay caused by an unmarked blocking WP
• Cascade Slack notification to affected WPs' heads/leads whenever a timeline changes via activation, stage-gate, or a standard CR

Each of these will get its own branch off of develop. You can either create branches off of that for each part or have developers continue to work on the same branch. Either way, phase 1 should be totally completed and then merged into develop instead of merging in each ticket at a time. Each phase will have its own schema changes and migration; however, they should be planned out before the start of the semester.

Each time one of these phases is completed, it needs to be announced in the leads channel, so they are aware of the changes. When the last ticket for a phase is ready to be merged in, we will cover the use cases during our weekly meeting in that phase to make sure it is working correctly.

This feature needs to be completed, meaning we sit down and go through all the functionality together, by December 13. Only the required functionality needs to be done; any of the additives are a bonus. This is a day before the start of the final exam period. This will give us the final exam period to make any last changes. It is up to you how to split up this time between the 4 phases.

Out of Scope

• A general-purpose "smart scheduling" engine beyond the specific buffer-window auto-update described here
• Slack notifications for anything other than the two WP deadline cases listed
• Rebuilding the previously-removed frontend "connect existing CR" feature (only backend cleanup is in scope)
• Merging/deduplicating CRs

Background / Context

Historically, the club has required a change request for nearly every edit to project/work package data (all WBS element name changes, budget changes, leadership changes, and stage gate/activation transitions). Now, the level of scrutiny varies a lot by type: Budget and Standard CRs wait for an independent reviewer to accept or decline them, while Leadership, Activation, and Stage-Gate CRs are self-approved by the submitter the moment they're created. Every type still logs an auditable Change row, so the paper trail exists, but for most CR types, "change request" today means a record of what happened, not a review gate that could catch or block it. Now, CR volume has gotten so heavy that people skip filing one out when a work package slips, or they've stopped taking the requirement seriously. On top of that, the one deadline notification that already exists is a weekly Slack reminder for work packages whose end date is <= next Monday. It re-fires every Monday with a growing "days ago" count. This notification is ignored most of the time.

We want to make non-meaningful information (not budget, deliverables, or timeline) not require a change request. This will cut down the volume and turnaround for changes that are not super important. Budget, deliverable, and timeline changes are the opposite case: they should not be taken lightly, so instead of loosening them, we're tightening how they're tracked and enforced. Change requests will be ordered by priority so the changes that matter most get reviewed first instead of sitting behind a queue of trivial ones. Work packages that pass their start or end date without an activation or stage-gate CR will trigger a Slack notification instead of slipping silently, with a buffer window that auto-updates the timeline for minor slips and forces a real CR for anything larger. And a declined CR will be editable and resubmittable, so a meaningful change doesn't just disappear the first time it's rejected.

Acceptance Criteria & Mock-ups

• Activate WP modal defaults the start date field to the actual current date. This field should stay configurable, in case someone forgets to activate it but did start on time. Changing it updates the Gantt chart immediately without a page refresh.
• On activation, if the new start date is within a configurable buffer (7 days) of the original scheduled date, the timeline updates automatically. The buffer should be configurable under admin tools in the Project Configuration tab. If it's further off (before or after the set date), the date change instead requires an accepted change request. The modal button to submit the date activated should turn into a Submit CR button. The CR should be an activation CR and still get automatically implemented. This should send a Slack message to that team’s channel notifying the head and lead that the start date has changed from this to this.

Activation and Stage Gating Slack Messages (all should check that the work package has not already been activated/stage gated before sending):

• A Slack message should be sent to that team’s channel pinging the manager and lead the day before a WP’s start date at 5pm with a link to the work package page.

• A Slack message should be sent to the team’s channel pinging the manager and lead, the day of a WP’s start date at 5pm with a link to the work package page.

• A Slack message should be sent to the team’s channel pinging the manager and lead, the day after a WP’s start date at 5pm with a link to the work package page.

• A Slack message should be sent to that team’s channel, pinging the manager and lead, the day before a WP’s end date at 5pm with a link to the work package page.

• A Slack message should be sent to the team’s channel pinging the manager and lead, the day of a WP’s end date at 5pm with a link to the work package page.

• A Slack message should be sent to the team’s channel pinging the manager and lead, the day after a WP’s end date at 5pm with a link to the work package page.

• The change requests table supports sorting or filtering by importance, not just identifier. This is a computed triage score based on CR type, Budget_CR.proposedBudget magnitude, the WP's blocking count, days-until-start/end date, and the magnitude and direction of the timeline change. The score is persisted (as well as the blocking count, start date, and duration) on the CR record when computed, so it can be aggregated later for season-end reporting. The blocking count, start date, and duration can be changed again, so we want them at that specific point in time. ChangeRequestsTable.tsx exposes it as a sortable column.

• Editing project fields other than budget, timeline, and scope (deliverables) no longer requires a standard change request.

• Blocked-by relationships can reference work packages in other projects (projects must be on same car, should be filtered for this), so marking one WP as blocked (e.g. due to a backorder) can cascade timeline updates to WPs across multiple projects. To go further on this, in the change request creation form under the normal text box, there should be a checkbox for when the timeline is changing due to another work package being delayed that wasn't marked as blocking. When a timeline is changed by a work package, either through early/late activation, early/late stage gating, or a standard change request, a Slack message should be sent out in the team’s slack channel pinging the other WP’s heads and leads that the timeline was changed from this to this allowing them to update their work packages accordingly.

• All backend routes/services/schema fields related to "connect existing CR" are removed

• A declined change request can be edited and resubmitted by its creator. Under the actions dropdown, there should be an edit button only shown to the creator, which will take the user to the edit project/work package page. It should default to their proposed edits where they can go and change them and then resubmit (should first take the them to the usual text box). This should send a message in the change request created thread that it has been resubmitted, with a link to take them to the change request to review and approve it. If the original change request had any requested reviewers, they should be added again.

Additives if Time Permits

• At the beginning of the year, we have drafting phases where people are trying to figure out their timelines, but nothing is set in stone yet. We will set a date as the finishline freeze where people can make CRs for whatever they want before that date, and they will automatically be approved. After that date, all timeline changes require a change request. The date of the finishline freeze is what we want to use for the retrospective at the end of this year. In admin tools, we want to add a toggle in project configuration where any edits to projects or work packages do not require a CR. They are automatically skipped whenever this is toggled on. The edits are automatically implemented with no paper trail. When that toggle is turned back, everything goes back to the specifications above.
• Some WPs are on the critical path, and some do not contribute to the critical path. For example, Embedded may create WPs for automotive ethernet. This is not critical to the car being able to drive. If they never get around to it or the timeline slips, the car will still drive fine. These are not part of the critical path. On the other hand, if our hubs slip on timelines, the car will not be able to drive. That WP contributes to the critical path. Work packages should be able to opt in to the critical path, and this would increase their triage score.

Tickets

• #4409
• #4410
• #4411
• #4413
• #4415
• #4416
• #4417
• #4419
• #4420
• #4421
• #4422
• #4423
• #4424
• #4425
• #4426
• #4427
• #4428
• #4429
• #4430
• #4431
• #4432
• #4433
• #4434
• #4435
• #4459
• #4460

Start by breaking the four phases into separate work items and reading the corresponding acceptance criteria; the payload specifically identifies ChangeRequestsTable.tsx and the Project Configuration area. Trace the activation, stage-gating, Slack notification, change-request, and cross-project blocking entry points, then define completion against the listed phase criteria and rollout plan.