Designs to support winter data collection

[LindsayMacfarlane]

Description:

The A&R team would like to better track information related to winter camping. Designs required to support the implementation of ticket number 389.

Development Checklist:

• [ ] Reach out to A&R team to better understand requirement
• [ ] Draft designs
• [ ] Review with A&R and Devs for feedback
• [ ] Make any changes as needed
• [ ] Attach finalized designs to ticket #389

Dependencies

• Blocked by
• Blocking #389

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:

[LindsayMacfarlane]

Hi @pavelcreates @meredithom - tagging you directly in this ticket for async backlog refinement. Please review criteria and add anything that is missing. Let me know if you have any questions.

[pavelcreates]

@LindsayMacfarlane

Took a look at #389 as well - Do we have some clarity on what data is required? Does this exploration work still need to happen? Do we have any supporting documents I can look at to determine what needs to happen with this ticket?

Does this work align with what info services is doing with the dates of operation? Is this a possible collaboration point?

[LindsayMacfarlane]

@pavelcreates - great questions. Exploration should be part of this ticket and, from my current understanding, is separate from the dates of operation work - but that is something to dig into!

@nicolebottoms @sallyhaynes - can you remind me if this was simply to add a field for the camping fees - or something else? Thanks!

[sallyhaynes]

@LindsayMacfarlane @pavelcreates @nicolebottoms @jbarber48

Yes, some of our parks charge a reduced camping rate over the winter (see example for Rathtrevor below). Unfortunately the day a park switches from regular season to winter season isn't necessarily static year over year, can be different depending on the park, and is based on a change in level of service (like a reduction in staff presence or availability of facilities) that is decided outside of HQ. Since sometimes the switch to winter season happens part way through the month, our camping party data for those months represents parties that are being charged two different rates, which is less than ideal.

We need to track how many parties are paying winter rates versus standard. This is likely best done by adding another data entry field.

Business impacts/uses for this data: -Revenue projections -Understanding Fee impacts -Application of contractual payments to park operators based on fee revenue/ attendance data (such as SSCFE payments)

Bonus considerations/ choose your complexity level:

-This data entry field could displayed in the UI year round for simplicity's sake, or could only display during winter months if there it's not too difficult to do in the back end. -Could tie in to park operating dates which often state when the winter season starts for parks, but since we only record monthly totals this would likely take the form of a variance note for now. -Do we need a separate entry field for SSCFE during the winter rates time period so we can more accurately reimburse the POs?

[nicolebottoms]

to add to this. if we were considering a separate entry field for sscfe, would an option be to 'toggle' the winter rate when the winter rate field is entered? for example, there is a separate winter rate field, somebody enters data in that, and they also enter sscfe. but because they have that data in the winter field, automatically populates the revenue at the sscfe rate. oh wait this also ties into the fee rate being embedded into the field results. okay may be more complicated but i wanted to put it out there.