HFI Calc: Decide on Data Architecture, Desired Behaviour, etc.
- Dominant language
- Python
- Stars
- 65
- Forks
- 11
- Avg merge
- 21h 25m
- Merged PRs (30d)
- 70
Description
**Describe the task**
Devs (and probably also PO and UX) need to meet to discuss issues that have arisen lately regarding data storage in HFI Calc and lack of clarity on the desired behaviours of the product.
**Acceptance Criteria**
- [ ] All relevant parties meet and document decisions made
- [ ] Create follow-up tickets to implement the work based on decisions made in meeting
**To Discuss**
- Versioning of planning area configurations by fire centre based on shoulder vs. core fire season
- Should fire centres be allowed to create new planning areas/delete old ones? Currently we don't have this functionality
- How should "stored HFI requests" (i.e., prep sheets) be stored on our end? Right now it's in JSON in DB, but this isn't ideal
- When user creates new prep sheet they're usually using forecast data, but if they go back in time to look at old prep periods in HFI Calc, the wx data shown will be for actuals, not the forecast data that was available at the time
- Should there be user documentation to clarify who is responsible for storing what data?
Contributor guide
Research direction
No files, tests, or entry points are identified. Start by reviewing the HFI Calc data storage and current JSON-in-DB approach, then use the meeting to document decisions about versioning, planning-area lifecycle, stored prep sheets, forecast history, and documentation; completion means decisions are recorded and follow-up tickets are created.
Written by the indexing model from the issue text.
Assessment
- Domain
- databases
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 15/100