Your commits explain the who, what, where and when of these changes. Your code shows the how. You do not need to reiterate this. This PR should complete the picture by explaining why these changes are necessary.
Please complete the fields below, replacing or removing placeholder text where necessary:
Please describe the importance/impact of the problem and a description of how the changes in this pull request will address, resolve or improve it. This section should sufficiently explain to reviewers why these changes should be approved.
If the proposed changes should close an issue, be sure to link to it below:
Fixes #?
What types of changes does this pull request introduce? Put an x in the boxes that apply.
This will inform the new release number.
- Fix (non-breaking change which fixes a bug)
- Feature (non-breaking change which adds or changes functionality)
- Breaking change (fix or feature that would cause existing functionality to not work as expected)
- Other change (if none of the other choices apply)
If this is a relatively large or complex change, kick off a discussion by explaining why you chose the solution you did, what alternatives you considered, problems you may have encountered, etc.
Assign at least 2 reviewers:
- one of which should be a maintainer of this repo,
- the others should be familiar with the subject or problem.
Please detail the process reviewers will need to follow to properly test these changes. It is especially helpful to identify the exact code needed to conduct a local build/review/test and to specify any aspects of the testing that may not be obvious.
This repo contains an air.toml file that automatically formats code to a set of standards.
It is preferred that contributors and reviewers install the Air formatting tool.
Code submitted in this pull request will be automatically checked for correct formatting.