Docs: Add managing packages section

CONTRIBUTING.md

@@ -158,7 +158,36 @@ When creating a new package you need to provide at least the following:
 	- Installation details.
 	- Usage example.
 	- `Code is Poetry` logo.
+
+### Managing packages
 
+It isn't easy task to maintain dozens of npm packages. That's why we decided to introduce `CHANGELOG.md` files for all packages to simplify the release process.
+
+The developer who proposes a change (pull request) is responsible to choose the correct version increment (`major`, `minor` or `patch`) according to the following guidelines:
+- Major version X (X.y.z | X > 0) should be bumped on any backwards-incompatible change. This will usually occur at the final removal of the feature. The deprecation should be fully backwards-compatible and, if it is not, it should warrant a separate major version bump.
+- Minor version Y (x.Y.z | x > 0) update should be selected when you add functionality in a backwards-compatible manner. It must be incremented if any public API functionality is marked as deprecated.
+- Patch version Z (x.y.Z | x > 0) should be incremented when you make backwards-compatible bug fixes.
+
+When in doubt, refer to [Semantic Versioning specification](https://semver.org/).
+
+_Example:_
+
+```md
+## v1.2.2 (Unreleased)
+
+#### Bug Fix
+
+- ...
+- ...
+```
+
+- If you need to add something considered a bug fix, you add the item to `Bug Fix`section and leave the version as 1.2.2.
+- If it's a new feature you add the item to `New Feature` section and change version to 1.3.0.
+- If it's a breaking change you want to introduce, you add the item to `Breaking Change` section and bump the version to 2.0.0.
+
+The version bump is only necessary if one of the following applies:
+ - There are no other unreleased changes.
+ - The type of change you're introducing is incompatible (more severe) than the other unreleased changes.
 
 ### Releasing packages
 
@@ -200,12 +229,7 @@ To release a production version for the outdated packages, run the following com
 NPM_CONFIG_OTP=123456 npm run publish:prod
 ```
 
-Choose the correct version (`major`, `minor` or `patch`) according to the following guidelines:
-- Major version X (X.y.z | X > 0) should be bumped on any backwards-incompatible change. This will usually occur at the final removal of the feature. The deprecation should be fully backwards-compatible and, if it is not, it should warrant a separate major version bump.
-- Minor version Y (x.Y.z | x > 0) update should be selected when you add functionality in a backwards-compatible manner. It must be incremented if any public API functionality is marked as deprecated.
-- Patch version Z (x.y.Z | x > 0) should be incremented when you make backwards-compatible bug fixes.
-
-When in doubt, refer to [Semantic Versioning specification](https://semver.org/). Confirm all your choices and let Lerna do its magic.
+Choose the correct version based on `CHANGELOG.md` files, confirm your choices and let Lerna do its magic.
 
 ## How Designers Can Contribute
 

docs/reference/repository-management.md

@@ -123,7 +123,7 @@ A pull request can generally be merged once it is:
 - In compliance with all relevant code review criteria.
 - Covered by sufficient tests, as necessary.
 - Vetted against all potential edge cases.
-- Changelog entries were introduced.
+- Changelog entries were properly added.
 - Reviewed by someone other than the original author.
 
 The final pull request merge decision is made by the **@wordpress/gutenberg-core** team.