Nit fixes to releasing doc (#1648)

Author: cijothomas

RELEASING.md

@@ -24,24 +24,33 @@ A draft PR can be created, but before releasing consider the following:
 ## Steps to Release
 
 1. Create a release PR
-  - For each crate
-    - Bump appropriate version
-    - Update change logs to reflect release version.
-    - Update API/SDK version as necessary
-    - Attach `integration test` label to the PR to run integration tests
-  - If there's a large enough set of changes, consider writing a migration guide.
+
+* For each crate
+  * Bump appropriate version
+  * Update change logs to reflect release version.
+  * Update API/SDK version as necessary
+  * Attach `integration test` label to the PR to run integration tests
+* If there's a large enough set of changes, consider writing a migration guide.
+
 2. Merge the PR
-  - Get reviews from other Maintainers
-  - Ensure that there haven't been any interfering PRs
+
+* Get reviews from other Maintainers
+* Ensure that there haven't been any interfering PRs
+
 3. Tag the release commit based on the [tagging convention](#tagging-convention). It should usually be a bump on minor version before 1.0
 4. Create Github Release
 5. [Publish](#publishing-crates) to crates.io using the version as of the release commit
 6. Post to [#otel-rust](https://cloud-native.slack.com/archives/C03GDP0H023) on CNCF Slack.
 
-
 ## Tagging Convention
 
 For each crate: it should be `<crate-name>-<version>` `<version>` being the simple `X.Y.Z`.
+For example:
+
+```sh
+git tag -a opentelemetry-http-0.11.1 -m "opentelemetry-http 0.11.1 release"
+git push origin opentelemetry-http-0.11.1
+```
 
 ## Publishing Crates