Overview
Simplify the change request (CR) workflow by removing a confusing type categorization system, streamlining the form, and moving approval to Slack. One CR per change. Approval = implementation.
More Info
Stakeholders
Product Stakeholder:
Software Stakeholder: @chpy04 @wavehassman
Reference Users:
User Story
- As a member, I want a simple form that just asks what I'm changing and why, without confusing type choices and multiple text boxes.
- As a head/admin, I want to approve changes directly from Slack without opening finishline.
- As a reviewer, I want to see a diff of what changed before approving.
Success Metrics
- Slack-based approvals: % of approvals via Slack reply
- Approval turnaround: time from submission to turnaround
- CR submission time: reduced form fields = faster submission
Rollout Plan
Phase 1 — Schema & Backend Foundation (no parallelism, must be sequential)
- TICKET 1 (migration) → TICKET 2 (backend endpoints) → TICKET 3 (approval logic)
Phase 2 — Backend features (can run in parallel after Phase 1)
- TICKET 10 (add deliverables to diff)
- TICKET 4 (Slack notification)
- TICKET 5 (Slack webhook) — depends on TICKET 4 (needs Message_Info records from it)
Phase 3 — Frontend (can start after TICKET 2 lands)
- TICKET 6 (new CR form) — depends on TICKET 2
- TICKET 7 (remove legacy UI) — depends on TICKET 2
- TICKET 8 (CR detail page) — depends on TICKET 2
- TICKET 9 (stage gate date) — independent, can run any time
Tickets 1, 2, 3 must be sequential
Tickets 4, 5 mught be sequential
Tickets 6, 7, 8, 9, can be done in parallel
Out of Scope
- Cross-project blocking WP timeline propagation
- Changes to activation, stage gate, leadership, or budget CR types (auto-implementing CRs stay as-is)
Background / Context
The existing CR system has four manual types: ISSUE, DEFINITION_CHANGE, and OTHER. In practice, users don't understand the distinctions and nearly always select OTHER. The form is cluttered, stacking multiple changes onto one request is confusing, and approval happens inside the app with no push notifications.
Auto-implementing types (activation, stage gate, leadership changes) work fine and are untouched.
Acceptance Criteria & Mock-ups
Remove type field and only have "Why are you making this change?" text box
Field is free-text and required. Old type enum data is migrated into this field as a human-readable string on existing CRs.
Approval logic: requested review OR any head/admin can approve
If a specific reviewer is requested, approval must come from that person or any head/admin. Heads/admins can always approve regardless of reviewer assignment.
Slack notification with diff, tagging and reply-based approval
On CR submit: notify project's Slack channel tagging the project head and requested reviewer if it is not auto implementing. Thread includes a diff. Users reply "approve" to auto-approve. Bot validates permissions and responds with confirmation or rejection message. Like the attendance feature.
Remove legacy UI elements
Select existing CR" and "Make new change request" buttons removed from project/WP views. Remove /change-requests/new route. The only entry point is the edit button for both project and workpackage. After CR approval: "create new project" and "create new WP" buttons hidden. Review comment made optional CR edit page: "Submit" and "Request change" merged into one context-aware button.
Migrate existing enum data before removing old tables
Extract ISSUE/DEFINITION_CHANGE/OTHER type + any associated proposed changes data into human-readable JSON string. Make the new buttons auto-implement or not. Populate new why text field. Then drop the old enum column and related tables. Activation/stage gate/leadership/budget tables untouched.
Put deliverables on the diff
Stage gate date input defaults to today
When a user stage gates a work package, the date field is shown and defaults to the current date. User can change it.
Tickets
Overview
Simplify the change request (CR) workflow by removing a confusing type categorization system, streamlining the form, and moving approval to Slack. One CR per change. Approval = implementation.
More Info
Stakeholders
Product Stakeholder:
Software Stakeholder: @chpy04 @wavehassman
Reference Users:
User Story
Success Metrics
Rollout Plan
Phase 1 — Schema & Backend Foundation (no parallelism, must be sequential)
Phase 2 — Backend features (can run in parallel after Phase 1)
Phase 3 — Frontend (can start after TICKET 2 lands)
Tickets 1, 2, 3 must be sequential
Tickets 4, 5 mught be sequential
Tickets 6, 7, 8, 9, can be done in parallel
Out of Scope
Background / Context
The existing CR system has four manual types: ISSUE, DEFINITION_CHANGE, and OTHER. In practice, users don't understand the distinctions and nearly always select OTHER. The form is cluttered, stacking multiple changes onto one request is confusing, and approval happens inside the app with no push notifications.
Auto-implementing types (activation, stage gate, leadership changes) work fine and are untouched.
Acceptance Criteria & Mock-ups
Remove type field and only have "Why are you making this change?" text box
Field is free-text and required. Old type enum data is migrated into this field as a human-readable string on existing CRs.
Approval logic: requested review OR any head/admin can approve
If a specific reviewer is requested, approval must come from that person or any head/admin. Heads/admins can always approve regardless of reviewer assignment.
Slack notification with diff, tagging and reply-based approval
On CR submit: notify project's Slack channel tagging the project head and requested reviewer if it is not auto implementing. Thread includes a diff. Users reply "approve" to auto-approve. Bot validates permissions and responds with confirmation or rejection message. Like the attendance feature.
Remove legacy UI elements
Select existing CR" and "Make new change request" buttons removed from project/WP views. Remove /change-requests/new route. The only entry point is the edit button for both project and workpackage. After CR approval: "create new project" and "create new WP" buttons hidden. Review comment made optional CR edit page: "Submit" and "Request change" merged into one context-aware button.
Migrate existing enum data before removing old tables
Extract ISSUE/DEFINITION_CHANGE/OTHER type + any associated proposed changes data into human-readable JSON string. Make the new buttons auto-implement or not. Populate new why text field. Then drop the old enum column and related tables. Activation/stage gate/leadership/budget tables untouched.
Put deliverables on the diff
Stage gate date input defaults to today
When a user stage gates a work package, the date field is shown and defaults to the current date. User can change it.
Tickets