13 02 2025/maintainer policy codebase changes (#400)

https://forum.spacestation14.com/t/codebase-changes-with-contrib-notifications/17097/2

src/en/wizden-staff/maintainer/review-procedure.md

@@ -12,6 +12,7 @@ This documents lists the Maintainer procedure for reviewing and merging PRs to t
   - In the case where there's dissent among maintainers, e.g. 2 Approvals and 1 Disapproval, a Maintainer Discussion should be held as described under the Policy section.
   - You do not need to be one of the two Maintainers who have given Approval/Disapproval to merge/close the PR. Ideally a PR should be processed once it meets the requirements to be merged/closed, but if that does not happen for some reason, any other Maintainer is free to do it (even if that Maintainer is the PR author).
 - PRs that have more than 3 weeks of inactivity waiting on something from the PR author should be considered "stale" and labeled as such with the `S: Stale` label, unless another reason explains the inactivity (e.g. freeze or author has informed about a longer break). You may use any means to contact the author of the PR, but at the minimum you should leave a comment on the PR and give at least 1 week to respond before closing a stale PR. A PR that is waiting on an action from Maintainers (e.g. a code review or discussion resolution) is not eligible to be marked as stale.
+- PRs that change public APIs, move code into another namespace, change a prototype ID / prototype definition in C# etc. should contain a "breaking changes" section. This section should contain a summary of the changes and how to apply them. Upon merging the PR it is the maintainers task to post the breaking changes section (Not just the PR link!) into `#codebase-changes`. The message format should first include a link to the PR, then the "breaking changes" section copied from the PR and lastly a ping for `@contrib-notifications.`. While not necessary, checking the message for spelling errors and correcting them is preferred.
 
 ### Exemptions:
 - PMs and Wizards may waive any PR Review Procedure requirements if deemed necessary for the health of the project. When doing so, it should be done via written permission with an explanation (either on Github, Discord or the SS14 forums). Note that this exemption is not the default for actions taken by the relevant roles, and should be explicitly invoked when used.