DUP: Front-end Major Updates and Plan Forward

[Dianadec]

Description:

Commencing brain dump:

In an effort to create a 'minimum viable dataset' for the backcountry reservations systems project, we have encountered a few issues with data quality including:

• overlapping definitions of 'outdoor experiences' (ie Wilderness)
• dubiously trustworthy geospatial data (exists on a wiki-like platform where anyone can change and update the data)
• policies that are at first glance unique to the park they belong to, but in fact can be harmonized with more general policies

It is becoming apparent that we may have to commence building the system without having a complete MVD set for all backcountry experiences offered by Camis, and to a greater extent, offered by BC Parks. In this scenario, it is critical that we have a strong data model that the system can be built around, such that data may be added to the system as it becomes available without the system changing to accept new data.

For this to be successful we would need to define what the MVD should look like, though it may be incomplete. To help with this, there are a few paths we can take:

Option 1 is to take a few exemplary parks with trustworthy data and flesh out the functionality that those parks would need in a fully fledged system.

• We would need to select a minimum of one of each type of experience the new backcountry system would offer so we are able to assess all potential cases.
• Essentially, this approach would build out all the functionality the system would ever need, and it would just grow iteratively with each new set of data added with ideally zero code changes.
• The drawback would be presenting a system where at first, most of the backcountry experiences are still available only in Camis while some are available in the new system.

Option 2 is to shift focus away from backcountry camping and focus more on the Day Use Pass system.

• DUP was not built with the longevity it is currently experiencing in mind and it is needing a rewrite more and more each day.
• If the PRDT system includes the absorption of DUP at some point anyways, then rewriting the system from a PRDT standpoint is a potentially lightweight first-pass option.
• There are only a few parks involved in PRDT and the policy involved is well known by the team already. Finally, there is no payment collection with DUP so that cuts out a massive portion of scope.
• Plus, once built, the old DUP system can be spun down and there are not multiple places public users have to go to book something depending on their destination of choice.
• This option is a massive paradigm shift and obviously does far less than Option 1 by way of building a backcountry reservation system replacement, though a lot of the technologies used (map technology, new email/notification technologies to replace GCN, etc) could be experimented with here with little drawback.
• A rebuild of DUP would also contribute less to understanding what the MVD for backcountry reservations should look like, but in turn it would give us more time to assemble an actual MVD that is ready to go once the system is rebuilt.

It is paramount we work alongside the RST project at this time to coordinate the way our data is structured. The ultimate goal is to enable data consumers to be agnostic of the source of the data they are pulling - for example, RST and backcountry geospatial data should be able to live in different databases but be represented on the same front end map page without the page making special considerations dependent on the origin of the data.

Acceptance Criteria:

[Note: Use 'Given/When/Then' format if it makes sense to. Otherwise, a simple checklist that can be tested.]

Development Checklist:

• [ ] ...
• [ ] ...
• [ ] ...

Dependencies

• Blocked by
• Blocking

Relevant documentation as reference

Definition of Ready

• [ ] Acceptance criteria are included
• [ ] Wireframes are included (if applicable)
• [ ] Design / Solution is accepted by Product Owner (if applicable)
• [ ] Dependencies are identified (technical, business, regulatory/policy)
• [ ] Story has been estimated (under 13 pts)

Definition of Done

• In progress:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] UI meets accessibility requirements
  • [ ] Unit tests are written
  • [ ] Work is traceable in GitHub
  • [ ] PR linked to ticket number
  • [ ] If needed/required - Dev adds flag/label to highlight any migration steps necessary prior to PROD deployment
• Code review:
  • [ ] Code is peer reviewed and has passed CI/CD tests
• QA:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] Code is potentially shippable to the production environment
  • [ ] Functional features have been tested and passed by QA
  • [ ] UI components tested by designer
  • [ ] Code is deployed to PROD when moved to 'done' column (unless requested otherwise by PO)
• PO Review:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] Reviewed and approved by Product Owner

Notes:

[Dianadec]

One next step could include: Create list of pain points of current DUP system so we can keep them in mind when building it into the new system.

Noting that a lot of the feature requests may be a waste of time in the CURRENT state of DUP if we are rebuilding this. Need to weigh the priorities. TL;DR: All the feature requests should be viewed in the context of the new system.

cc @cameronpettit @MarshallHenson @LindsayMacfarlane