public/private api changes

Author: sentrivana

develop-docs/sdk/processes/breaking_changes.mdx

@@ -27,10 +27,12 @@ The most obvious kind of breaking changes is changing the way the user interacts
 - Dropping or renaming an argument to an API function
 - Changing the type of an argument to an API function and not accepting the previous type anymore
 
-In some SDKs, the line between public and private API is unclear. If unsure, discuss with your teammates. Some pointers:
+In general, it's good to explicitly point out which parts of the API are public using whatever way is conventional for your language (declaring them as such, prefixing private functions with `_`, adding a code comment, etc.).
+
+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 function, or a helper function we added to make testing easier? Then it's fine to change.
-- Can you reasonably assume a significant portion of the user base is using this?
+- 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?
 
 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)