<!---
This template is not mandatory, but it is highly recommended. If you feel like
it's a bad fit for your PR, feel free to delete some or all of it. By filling
it, it will help you to think through the changes you are making and why you
are making them, and hopefully even regret some of them early. It will also
help the reviewer to understand your changes better, which will help them to
review your code more effectively. Remember reviewers time is valuable, and
often without this information, reviewing feels a bit like tedious reverse
engineering.

Be as verbose as you like! You don't have to write paragraphs if you don't
want, even brief notes can be helpful. But a lot of information never hurts.
Remember that often this will be the only record of our decisions / design, and
our only form of communication with other team members about our changes. So
it's good to be thorough.
-->

# Background / Context

<!---
Not all reviewers know everything there is to know about the project, use this
section to give a bit of background knowledge about the part of the project
you're changing. Things like links to previous relevant commits, existing
system behavior, how things currently work. Don't describe your changes or what
issue you're solving, just things that are already established. Even if these
seem obvious and the reviewer likely already knows them, it still helps
establish the context of the change.
-->

# Issue / Requirement / Reason for change

<!---
The reason for making this PR. Use this section to describe the issue you're
solving. The shortcomings of the above background. This doesn't have to be an
actual issue/bug, but could also be a requirement that is being addressed or
the need for a new feature. Don't describe your solution just yet, focus on the
problem/requirement. If there's a relevant ticket, also link it here.
-->

# Solution / Feature Overview

<!---
Use this section to give a general overview of the solution you're proposing.
Explain how it helps to solve the issue you described above. No need to go into
code specifics.
-->

# Implementation Details

<!---
If your change is complicated, use this section to describe the implementation
details of your PR. This is mostly good for huge PRs where it's easy to get
lost in a lot of diff, or when the changes are complicated. Not everything
needs to be described, just the main points.
-->

# Other Information

<!---
Any other relevant information that doesn't fit into the above sections. Extra
changes you did as part of your PR that you want to point out, considerations
such as performance, security. Future follow-up work that might be needed
(maybe create a ticket?), concerns you might have about your changes, etc.
-->

<!---

# Checklist

This is a personal checklist that should be applicable to most PRs. It's good
to go over it in order to make sure you haven't missed anything. If you feel
like some of these points are not relevant to your PR, feel free to keep them
unchecked and if you want also explain why you think they're inapplicable.

- [ ] I also copied this entire text into my commit message, and not just the GitHub PR description (`git config commit.template .github/pull_request_template.md`)
- [ ] I performed a rough self-review of my changes
- [ ] I explained non-trivial motivation for my code using code-comments
- [ ] I made sure my code passes linting, tests, and builds correctly
- [ ] I have ran the code and made sure it works as intended, and doesn't introduce any obvious regressions
- [ ] I have not committed any irrelevant changes (if you did, please point them out and why, ideally separate them into a different PR)
- [ ] I added tests (or decided that tests aren't really necessary)
- [ ] I deleted this checklist and all the "<!---" comments (like this one) from the commit message and the PR description, leaving only my own text
-->