bcgov / bcgov/wps

HFI Station Admin: Decision log for changes - who and why (accountability)

Open
#2,034 1 comment 0 reactions 0 assignees View on GitHub
Decision User Story
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.