meta: clarify process for breaking changes

Fixes: #7848

COLLABORATOR_GUIDE.md

@@ -56,16 +56,23 @@ full responsibility for the change, defer to another Collaborator.
 Before landing pull requests, sufficient time should be left for input
 from other Collaborators. Leave at least 48 hours during the week and
 72 hours over weekends to account for international time differences
-and work schedules. Trivial changes (e.g. those which fix minor bugs
-or improve performance without affecting API or causing other
-wide-reaching impact) may be landed after a shorter delay.
+and work schedules. Trivial changes (e.g. fixing typographical errors in
+documentation) may be landed after a shorter delay.
 
-Where there is no disagreement amongst Collaborators, a pull request
-may be landed given appropriate review. Where there is discussion
+For non-breaking changes, if there is no disagreement amongst Collaborators, a
+pull request may be landed given appropriate review. Where there is discussion
 amongst Collaborators, consensus should be sought if possible. The
 lack of consensus may indicate the need to elevate discussion to the
 CTC for resolution (see below).
 
+Breaking changes (that is, pull requests that require an increase in the
+major version number, known as `semver-major` changes) must be elevated for
+review by the CTC. This does not necessarily mean that the PR must be put onto
+the CTC meeting agenda. If multiple CTC members approve (`LGTM`) the PR and no
+Collaborators oppose the PR, it can be landed. Where there is disagreement among
+CTC members or objections from one or more Collaborators, `semver-major` pull
+requests should be put on the CTC meeting agenda.
+
 All bugfixes require a test case which demonstrates the defect. The
 test should *fail* before the change, and *pass* after the change.