Document what to do in case of a breaking change

README.md

@@ -144,7 +144,7 @@ similar issue has already been filed. If not,
 
 Code contributions are always welcome! Cyma follows a `feature-branch` workflow,
 so any features and bug fixes are introduced via pull request from a feature
-branch. 
+branch. Please read these points before contributing.
 
 #### Do you want to contribute to a specific issue?
 
@@ -153,6 +153,27 @@ already been made. If not, you can fork the repository and then create a pull
 request with your changes. Link the related issue under the PR's *Development*
 section.
 
+#### Does your contribution introduce a <ins>breaking change</ins>?
+
+A breaking change is a modification to Cyma that affects the dependants of it. A
+backwards-incompatible modification to its internal workings is **not** a breaking
+change.
+
+A pull request **should not** introduce a breaking change. It should only do so when
+alternatives to it would be detrimental to performance and usability, or just aren't
+feasible. Usually, it is better to mark existing features as deprecated, and favor
+backwards-compatible solutions.
+
+In case your contribution changes core parts of Cyma such that code written using
+the library will break:
+
+- Announce your breaking changes
+- Explain how code broken by these changes can be migrated to work as expected.
+- Optionally, use `diffs` inside code block tags to provide examples of migration.
+
+See [this](https://github.com/223230/cyma/pull/50) PR as an example of how breaking
+changes can be announced.
+
 ## 📃 License
 
 This project is licensed under the [MPL](LICENSE).