wrding

Author: sentrivana

develop-docs/sdk/processes/breaking_changes.mdx

@@ -32,7 +32,7 @@ In general, it's good to explicitly point out which parts of the API are public
 In some SDKs, the line between public and private API is unclear, in which case you need to be more mindful of users possibly using functions that weren't meant to be public. In these cases, you need to make a decision. If unsure, discuss with your teammates. Some pointers:
 - Is the API mentioned in the user-facing docs? Then it's highly likely public, and you should consider making changes to it in a major release.
 - Was the code you're changing solely created for an internal purpose? Is it a utility or a helper function? Then it's fine to change.
-- Have you seen this function be used in user code, for example in issue reproduction examples in your repo?
+- Have you seen the function used in user code, for example in issue reproduction examples in your repo?
 
 Naturally, the language of your SDK and the community around it also affects what is generally considered a breaking change. Some languages provide their own guidelines:
 - [.NET](https://learn.microsoft.com/en-gb/dotnet/core/compatibility/library-change-rules)