Pr comments

CONTRIBUTING.md

@@ -123,22 +123,22 @@ documentation in `/docs`.
 
 ### Updating Changelog
 
-Any pr which is merged to `main` and affects consumers of the codebase,
+Any PR which is merged to `main` and affects consumers of the codebase,
 must modify changelog [file](./CHANGELOG.md) accordingly, by adding new entry
 in `Unreleased` section of the changelog.
 
 Examples of changes which require change log update:
-- bug fix
-- adding new api
-- adding new feature
+- bug fixes
+- adding new APIs
+- adding new features
 
-Examples of changed that do not require changelog updates:
+Examples of changes that do not require changelog updates:
 - refactoring of internal implementation
 - adding new tests
 - modifying documentation
 
-The rule of thumb here it that changelog should be updated whenever change is
-visible by external user.
+The rule of thumb here is that the changelog should be updated as long as the change is
+visible by external users.
 
 ## Dependencies
 

RELEASE_PROCESS.md

@@ -42,7 +42,7 @@ branch (see [CONTRIBUTING.md](./CONTRIBUTING.md#pull-requests)).
   * **PRs targeting directly a release branch can be merged _only_ when
     exceptional circumstances arise**.
 * In the release branch
-  * Create by a PR, new version section in the `CHANGELOG.md` matching the released version e.g
+  * Create a PR that adds new version section in the `CHANGELOG.md`, matching the released version e.g
     for branch `release/v0.Y.x`, section will be called `v0.Y.0`
 * We freeze the release branch from receiving any new features and focus on
   releasing a release candidate.
@@ -56,19 +56,18 @@ branch (see [CONTRIBUTING.md](./CONTRIBUTING.md#pull-requests)).
   * The release verification on devnet must pass.
   * When bugs are found, create a PR for `main`, and backport fixes to the
     release branch.
-  * Before tagging release, create and merge pr to release branch that:
-    * Moves all changelog entries form `Unreleased` section of the changelog to newly created section `v0.Y.0`
+  * Before tagging the release, create and merge PR to the release branch that:
+    * Moves all changelog entries form `Unreleased` section of the changelog to the newly created section `v0.Y.0`
   * Create new release candidate tags after bugs are fixed.
 * After the team feels the release candidate is ready, create a full release:
   * **Note:** The final release MUST have the same commit hash as the latest
     corresponding release candidate.
   * Create a new annotated git tag in the release branch (follow the [Tagging
     Procedure](#tagging-procedure))
-* After final release is made e.g `v0.Y.0`, backport changelog changes to `main` branch
+* After the final release is made e.g `v0.Y.0`, backport changelog changes to the `main` branch
   * checkout a new branch from the main branch: `username/backport_changelog`
   * bring the new section from `release/v0.Y.x` branch to the `CHANGELOG.md` file on `main` branch
-  * open pr against the `main` branch
-
+  * open PR against the `main` branch
 
 ### Creating a new release branch