HFI Station Admin: Decision log for changes - who and why (accountability)
- Dominant language
- Python
- Stars
- 65
- Forks
- 11
- Avg merge
- 21h 25m
- Merged PRs (30d)
- 70
Description
As a Forecaster/RWCO I want the ability to respond to weather station network challenges in the HFI product So That if a station goes down, and particularly if a technician can't address it quickly, I can ensure the HFI product is still functional with enough data
Additional Context
- requirement: clarity to all users that a station has gone down or isn't behaving as expected (error state)
request: notification system — email notification when certain actions/states/criteria are met
- a forecaster is probably the first person to notice a station is down in their FC
- a forecaster may manually enter estimated forecast data in WFWX to override the station, they may send a human out (fly/drive) for a manual reading
- OR a decision may be made (never in isolation) between Plans, RWCO, Forecaster, maybe ZWCO for local context, on when/why to swap in a replacement station — RWCO has decision accountability
- only if there are representative stations available for replacement: easier in dense FCs, harder in remote areas with less stations
- note: prep stations are given high priority for repair
when such a decision is made: there is a request for accountability clarity.
- Who made the change, and why
- this would be referred to as a "guest station" why? station error, guest criteria: high elevation
- guest stations are **temporary** and need to be removed when the original station is repaired - they should be labelled as a guest
- swapping stations will vary by FC - some are densely populated with neighbouring weather stations, others wouldn't have a suitable replacement and would have to be omitted in prep
[Started a Figma concept riffing off forecaster chat](https://www.figma.com/file/FReMPNBDzxYeE8hlxRvsoB/PSU%3A-HFI-Calculator---Preparedness?node-id=1606%3A5246)
**Acceptance Criteria**
- [ ] Given (Context), When (action carried out), Then (expected outcome)
- [ ] Given (Context), When (action carried out), Then (expected outcome)
**Definition of Done**
- Ready to Demo in Sprint Review
- Does what I have made have appropriate test coverage?
- Documentation and/or scientific documentation exists and can be found
- Peer Reviewed by 2 people on the team
- Manual testing of all PRs in Dev and Prod
- Merged
Contributor guide
Research direction
Start by reviewing the linked Figma concept and the issue's station-swap and notification context; no implementation files, tests, or entry points are named. Clarify the acceptance criteria and the audit-log and notification flows before coding. Done means a demo-ready, tested, documented implementation that is peer reviewed and manually tested in Dev and Prod.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- figma
- Domain
- design, full-stack
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100