diff --git a/DEVELOPING.md b/DEVELOPING.md
index 092e3efeaf..2972d96b79 100644
--- a/DEVELOPING.md
+++ b/DEVELOPING.md
@@ -7,17 +7,24 @@ Start from a clean checkout at `main`.
 Before running through the release it's good to run the build and the tests locally, and make sure CI is passing. You can
 also test-drive the commit in an existing Bazel workspace to sanity check functionality.
 
+#### Steps
+1. [Determine the next semantic version number](#determining-semantic-version)
+1. Create a tag and push, e.g. `git tag 0.5.0 upstream/main && git push upstream --tags`
+   NOTE: Pushing the tag will trigger release automation.
+1. Watch the release automation run on https://github.com/bazelbuild/rules_python/actions
+1. Add missing information to the release notes. The automatic release note
+   generation only includes commits associated with issues.
+
 #### Determining Semantic Version
 
 **rules_python** is currently using [Zero-based versioning](https://0ver.org/) and thus backwards-incompatible API
 changes still come under the minor-version digit. So releases with API changes and new features bump the minor, and
-those with only bug fixes and other minor changes bump the patch digit.   
+those with only bug fixes and other minor changes bump the patch digit.
+
+To find if there were any features added or incompatible changes made, review
+the commit history. This can be done using github by going to the url:
+`https://github.com/bazelbuild/rules_python/compare/<VERSION>...main`.
 
-#### Steps 
-1. Determine what will be the next release, following semver.
-1. Create a tag and push, e.g. `git tag 0.5.0 upstream/main && git push upstream --tags`
-1. Watch the release automation run on https://github.com/bazelbuild/rules_python/actions
-    
 #### After release creation in Github
 
 1. Ping @philwo to get the new release added to mirror.bazel.build. See [this comment on issue #400](https://github.com/bazelbuild/rules_python/issues/400#issuecomment-779159530) for more context.