[DO NOT MERGE] Test PR to try to add automated PR comments

[DaveTryon]

This is a placeholder test to see if we can add automatic PR comments as described at https://github.com/orgs/community/discussions/69944#discussioncomment-7281028

[github-actions]

This is just a test

[github-actions]

You touched the API project--how does this impact the API version?

[github-actions]

You touched the API project. Did you change any of the API interfaces in any way? If so, this is an API-breaking change. Please be sure you do the following:

1. Bump the major version in the next release
2. Update the documentation to show the new functionality

[github-actions]

This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:

• Changing the signature of an existing interface method
• Adding a new method to an existing interface
• Adding a required data member to a class that an existing interface method consumes

Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:

Option 1 - Publish this as a breaking change

1. Update the documentation to show the new functionality and/or explain the change
2. Bump the major version in the next release
3. Be sure to highlight the breaking changes in the release notes

Option 2 - Refactor the changes to be non-breaking

1. Review this commit, which adds a new interface in a backward-compatible way
2. Refactor the change to follow this pattern so that existing interfaces are left completely intact
3. Bump the minor version in the next release

[github-actions]

This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:

• Changing the signature of an existing interface method
• Adding a new method to an existing interface
• Adding a required data member to a class that an existing interface method consumes

Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:

Option 1 - Publish this as a breaking change

1. Update the documentation to show the new functionality and/or explain the change
2. Bump the major version in the next release

Option 2 - Refactor the changes to be non-breaking

1. Review this commit, which adds a new interface in a backward-compatible way
2. Refactor the change to follow this pattern so that existing interfaces are left completely intact
3. Bump the minor version in the next release