Fix some typos in markdown files

CONTRIBUTING.md

@@ -11,7 +11,7 @@ Are you ready to contribute to JHipster? We'd love to have you on board, and we
 - [Coding Rules](#rules)
 - [Git Commit Guidelines](#commit)
 
-And don't forget we also accept [financial contributions to the project](https://www.jhipster.tech/sponsors/) using OpenCollective.
+And don't forget, we also accept [financial contributions to the project](https://www.jhipster.tech/sponsors/) using Open Collective.
 
 ## <a name="question"></a> Questions and help
 
@@ -27,7 +27,7 @@ If you find a bug in the source code or a mistake in the documentation, you can
 
 ## <a name="bounties"></a> Bug bounties
 
-If you submitted a Pull Request that fixes a ticket with the "\$100" tag, then you are eligible to our bug bounty program! Go to our [bug bounties documentation](https://www.jhipster.tech/bug-bounties/) for more information, and claim your money.
+If you submitted a Pull Request that fixes a ticket with the "\$100" tag, then you are eligible for our bug bounty program! Go to our [bug bounties documentation](https://www.jhipster.tech/bug-bounties/) for more information, and claim your money.
 
 ## <a name="feature"></a> Feature Requests
 
@@ -39,7 +39,7 @@ would like to implement a new feature then consider what kind of change it is:
 
 ## <a name="rfcs"></a> RFCs
 
-Sometimes, major feature requests are "complex" or "substantial". In this case, GitHub Issues might not be the best tool to to present them because we will need a lot of going back and forth to reach a consensus.
+Sometimes, major feature requests are "complex" or "substantial". In this case, GitHub Issues might not be the best tool to present them because we will need a lot of going back and forth to reach a consensus.
 
 So we ask that these feature request be put through a formal design process and have their specifications described in an "RFC" (request for comments) that will be validated by the team through a Pull Request Review.
 
@@ -129,7 +129,7 @@ Each commit message consists of a **header**, a **body** and a **footer**.
 <footer>
 ```
 
-Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
+Any line of the commit message cannot be longer than 100 characters! This allows the message to be easier
 to read on GitHub as well as in various git tools.
 
 ### Header

DEVELOPMENT.md

@@ -41,7 +41,7 @@ In your cloned `generator-jhipster` project, run `npm ci` and then run `npm link
 
 For testing, you will want to generate an application, and there is a specific issue here: for each application, JHipster installs a local version of itself. This is made to enable several applications to each use a specific JHipster version (application A uses JHipster 3.1.0, and application B uses JHipster 3.2.0).
 
-To overcome this you need to run `npm link generator-jhipster` on the generated project folder as well, so that the local version has a symbolic link to the development version of JHipster.
+To overcome this, you need to run `npm link generator-jhipster` on the generated project folder as well, so that the local version has a symbolic link to the development version of JHipster.
 Also add the option `--skip-jhipster-dependencies` to generate the application ignoring the JHipster dependencies (otherwise a released version will be installed each time npm install/ci is called). You can later on re-add the dependency with the command `jhipster --no-skip-jhipster-dependencies`.
 
 To put it in a nutshell, you need to:
@@ -69,7 +69,7 @@ You should see your changes reflected in the generated project.
 
 Note: The generated project might not build properly in case the generator is using a
 snapshot version of [jhipster/jhipster-bom](https://github.com/jhipster/jhipster-bom). This issue is mentioned in; https://github.com/jhipster/generator-jhipster/issues/9571. In
-this case clone the jhipster/jhipster-bom project and build it using:
+this case, clone the jhipster/jhipster-bom project and build it using:
 
 ```shell script
 ./mvnw clean install -Dgpg.skip=true
@@ -138,12 +138,12 @@ Daily builds samples are prefixed with `daily-`.
 #### Samples folder
 
 A common samples folder will be used if `--global` option is used like `jhipster generate-sample ng-default --global`.
-At first execution a prompt will ask for the samples folder, the choosen value will be reused at next executions.
+At first execution a prompt will ask for the samples folder, the chosen value will be reused at next executions.
 At samples folder, a `jhipster-samples.code-workspace` is generated. It provides a single vscode workspace for `generator-jhipster` and samples generated at the samples folder. It's very used for quick looks.
 
 ### Testing samples
 
-CI tests uses the following commands:
+CI tests use the following commands:
 
 ```
 npm ci:backend:test
@@ -167,7 +167,7 @@ Once up, you should have the stack maintainers recommends.
 Shortcuts are provided to easily generate integration tests samples.
 
 - go to `Execute and Debug`.
-- select the sample's github workflow.
+- select the sample's GitHub workflow.
 - run the shortcut.
 - select the sample.
 - sample is generated at `../jhipster-samples/` folder relative the `generator-jhipster` folder.