Apply suggestions from code review

Co-authored-by: Philipp Hofmann <[email protected]>

Author: sentrivana

develop-docs/sdk/processes/breaking_changes.mdx

@@ -28,7 +28,7 @@ The most obvious kind of breaking changes is changing the way the user interacts
 - 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:
-- Is the API mentioned in the user-facing docs? Then it's probably public and you should consider making changes to it in a major release.
+- 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?
 
@@ -43,7 +43,7 @@ We also need to be mindful of what the SDK change might cause in the product. So
 In general, we consider changes to the following product-side features potentially problematic:
 - **Grouping:** An SDK change might result in error events being grouped differently, because we remove, add or change some of the data on the event that is used in the grouping algorithm on the server. When you think a change might affect grouping, it's recommended to try the change yourself and check in Sentry to see if grouping is preserved.
 - **Dashboards:** A user has set up a dashboard that filters on specific data and we change that data. For instance, changing a span's `op` might mean a dashboard showing those spans will be empty after an SDK update.
-- **Alerts:** Alerts might stop firing because we've changed an attribute.
+- **Alerts:** Alerts might stop or start firing because we've changed an attribute.
 
 Changes to grouping, dashboards and alerts need closer inspection. In order to make a good decision, you can try to estimate how many users are affected using our data analytics tools. It always needs a human/team to weigh in.