chore: review more words

Signed-off-by: tison <[email protected]>

community/new-committers.md

@@ -95,7 +95,7 @@ While Curator mainly uses git for source control, certain components required by
 * Staging directory: svn co https://dist.apache.org/repos/dist/dev/curator/
 * Release directory: svn co https://dist.apache.org/repos/dist/release/curator/
 
-You must add your GPG key to the KEYS file in "repos/dist/release/curator/" and commit the changes. E.g. (replace NAME with the username you used to generate the keys):
+You must add your GPG key to the KEYS file in `repos/dist/release/curator/` and commit the changes. E.g. (replace NAME with the username you used to generate the keys):
 
 ```shell
 cd DIST RELEASE CURATOR directory
@@ -107,7 +107,7 @@ svn commit -m "Added my keys"
 
 ### GitHub Flow
 
-Curator loosely uses [GitHub Flow](http://scottchacon.com/2011/08/31/github-flow.html). The short form:
+Curator loosely uses [GitHub Flow](https://scottchacon.com/2011/08/31/github-flow). The short form:
 
 * Anything in the master branch is deployable
 * The upcoming release is always "master"
@@ -148,11 +148,11 @@ Make sure you choose an appropriate version for each release. The Maven build wi
 
 Curator's source is mirrored on GitHub at: https://github.com/apache/curator. Non-committers are [asked to fork this repository and submit pull requests](submitting-pull-requests.md) (PR) for changes. When a PR is received, a Curator committer can test and possibly merge it by:
 
-* Create a branch for the PR: `git checkout -b <branch name>` - the branch name is usually the ID of the GitHub issue
+* Create a branch for the PR: `git checkout -b <branch-name>`. The branch name is usually the ID of the GitHub issue.
 * Pull the changes from the PR: `git pull https://github.com/<users-name>/curator.git <branch>` (or you can use `gh pr checkout <pr-number>` with [GitHub CLI](https://cli.github.com/)).
-* Test, updated, etc. the change. Periodically push the change to the main repo. For the initial push: `git push -u origin <branch name>`
+* Test, updated, etc. the change. Periodically push the change to the main repo. For the initial push: `git push -u origin <branch-name>`.
 * If the change is accepted, merge it into the master branch and push the master branch. This will automatically close the GitHub PR. NOTE: Please use `git merge --squash` as this makes it easier to read the history and do cherry-pick.
 
 ### Maven Checks
 
-Regardless of which IDE you use, you should periodically perform a `mvn clean install` to validate that the various configured checks are passing as well as the unit tests.
+Regardless of which IDE you use, you should periodically perform a `./mvnw clean install` to validate that the various configured checks are passing as well as the unit tests.

community/submitting-pull-requests.md

@@ -10,9 +10,9 @@ Curator also uses Apache's GitHub mirroring. All source code/bug fix submissions
 
 You must also create an issue in [Curator's Issue Tracker](https://github.com/apache/curator/issues) (reference the Pull Request in the issue) and create a git branch with the same name as the Issue. All discussion, comments, etc. regarding the Pull Request should be in the Issue Tracker and/or GitHub and not by email.
 
-* Fork the Curator project from GitHub
-* Create a branch with the same name as the GitHub Issue number (e.g. CURATOR-1234) in your fork and push it to GitHub
-* Create a Pull Request in GitHub. The name of the Pull Request should be in the form: `[CURATOR-XXX] Summary of the Issue`
+* Fork the Curator project from GitHub.
+* Create a branch with the same name as the GitHub Issue number (e.g. CURATOR-1234) in your fork and push it to GitHub.
+* Create a Pull Request in GitHub. The name of the Pull Request should be in the form: `[CURATOR-XXX] Summary of the Issue`.
 * The Pull Request should include a description with the issue number associated.
 
 ## Apache Contribution Guide
@@ -36,5 +36,5 @@ Curator uses the following tools and libraries:
 * There must be a GitHub Issue created for your change.
 * Create a git branch with the same name as the Issue.
 * All submissions must have TestNG tests.
-* All submissions must have proper Apache license headers. Run the following command to make sure all files have headers: `docker run --rm -v $(pwd):/github/workspace ghcr.io/korandoru/hawkeye-native:v3 format`.
+* All submissions must have proper Apache license headers. Run the following command to make sure all files have headers: `docker run --rm -v $(pwd):/github/workspace ghcr.io/korandoru/hawkeye:v6 format`.
 * The simpler and smaller the change the more likely it is to be accepted.

community/team.md

@@ -2,7 +2,7 @@
 
 A successful project requires many people to play many roles. Some members write code or documentation, while others are valuable as testers, submitting patches and suggestions.
 
-The project team comprises Members and Contributors. Members have direct access to the source of a project and actively evolve the code-base. Contributors improve the project through submission of patches and suggestions to the Members. The number of Contributors to the project is unbounded. Get involved today. All contributions to the project are greatly appreciated.
+The project team comprises Members and Contributors. Members have direct access to the source of a project and actively evolve the codebase. Contributors improve the project through submission of patches and suggestions to the Members. The number of Contributors to the project is unbounded. Get involved today. All contributions to the project are greatly appreciated.
 
 ## Members