#1282: Fix some typos in docs (#1285)

Co-authored-by: jan-vcapgemini <59438728+jan-vcapgemini@users.noreply.github.com>

Author: Sascha-droid

documentation/IDEasy-contribution-getting-started.adoc

@@ -39,7 +39,7 @@ If some days have passed meanwhile you should merge changes that meanwhile happe
 git pull upstream main
 ```
 
-Once you are complete and everything is merged and comitted, you can push your local feature branch and make it a remote branch of your fork on github:
+Once you are complete and everything is merged and committed, you can push your local feature branch and make it a remote branch of your fork on github:
 
 ```
 git push -u origin feature/«issue-id»-«brief-feature-description»
@@ -48,7 +48,7 @@ git push -u origin feature/«issue-id»-«brief-feature-description»
 Now you can go to https://github.com/devonfw/ideasy/pulls and create the pull-request (PR) from your new feature.
 Therefore, please click on the right down arrow of the green button and choose `Create draft pull request` and then click on `Draft pull request`.
 When the checks have completed you can check the link:DoD.adoc[Definition-of-Done] (DoD).
-Once, all checks of the DoD are addressed, you can go the the very bottom of the PR and click on `Ready for review` what will take the PR out of the draft mode.
+Once, all checks of the DoD are addressed, you can go to the very bottom of the PR and click on `Ready for review` what will take the PR out of the draft mode.
 FYI: If you forgot the upstream merge (`git pull upstream/main`) or the upstream changed again while your PR is still open, you will see `This branch is out-of-date with the base branch` at the bottom of your PR and can click on `Update branch`.
 
 For further development and testing, it is recommended to xref:symbolic-links[symlink] the modified scripts into your IDEasy installation.
@@ -136,13 +136,13 @@ You probably know this black box on Windows (the Command Prompt) that accepts co
 Now for users of a Linux Distribution there is something similar, but way more powerful, usually called "Bourne Again Shell", or in short Bash.
 This Command Line Interface or "Shell" is what we use most often when implementing something new for our Command-Line-Tool with the name IDEasy.  https://www.youtube.com/watch?v=I4EWvMFj37g[Have a look at Bash in 150 Seconds.]
 For MacOS you often also use BASH.
-That's why it is often enough to implement code for Mac or Linux (at least to some extend as you'll see soon enough) to be able to use it on both Operating Systems.
+That's why it is often enough to implement code for Mac or Linux (at least to some extent as you'll see soon enough) to be able to use it on both Operating Systems.
 
 Let's get to the practical part of the Bash-usage.
 
 **If you are using Windows**, make sure that you have git-bash installed, so you can execute the Bash commands mentioned in this introduction. (https://git-scm.com/download/win[Here you can find git for windows]).
 In some cases later on you may want or need to use WSL.
-Our project teams standard way is to install WSL via Rancher Desktop, which is easily installable with the IDEasy by using the command `ide install docker`.
+Our project team's standard way is to install WSL via Rancher Desktop, which is easily installable with the IDEasy by using the command `ide install docker`.
 If you don't have the IDEasy yet, then you can follow (https://github.com/devonfw/IDEasy/blob/main/documentation/setup.adoc[this guide])
 
 The https://www.youtube.com/watch?v=oxuRxtrO2Ag[following video] gives you some important and helpful basics, still you don't need to know all of these commands directly by heart.

documentation/IDEasy-contribution-rules-and-guidelines.adoc

@@ -3,7 +3,7 @@ toc::[]
 
 == Project Board
 
-The IDEasy *Project Board* with its Columns should be used as followed:
+The IDEasy *Project Board* with its Columns should be used as follows:
 
 * *New*: [.underline]#Issues# that are newly created and have yet to be refined
 * *Backlog*: [.underline]#Issues# that are refined but not yet being worked on
@@ -18,9 +18,9 @@ The PR may be in draft state, otherwise the PR should be in one of the following
 The reviewer is the assignee of the PR and the author remains assignee (2 assignees).
 * *In Review*: [.underline]#Pull Request# that is to be or currently under review by a final reviewer that is the assignee of the PR together with the author (2 assignees).
 Typically the final reviewer is the Project Owner (currently hohwille) but it may also be done by team members with longer experience in the project.
-* *Done*: [.underline]#Issues# and [.underline]#Pull Request# that have been completed and merged.
+* *Done*: [.underline]#Issues# and [.underline]#Pull Requests# that have been completed and merged.
 
-To better organize the board and avoid overload, only pull request are allowed in the review columns.
+To better organize the board and avoid overload, only pull requests are allowed in the review columns.
 Issues remain `in progress` until completed via merge of PR.
 
 General conventions for contributions to devonfw can be found
@@ -35,20 +35,20 @@ The following conventions are added on top by the IDEasy team from the learnings
 ** Closes
 ** For more info see (https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)
 * The description can also contain additional information for the PR and changed files.
-* More complicated pull request should contain a short summary of the changed files and commits.
-* In addition, other issue or PRs can be linked, most commonly with keyword like:
+* More complicated pull requests should contain a short summary of the changed files and commits.
+* In addition, other issues or PRs can be linked, most commonly with keyword like:
 ** Blocked by
 ** Related
 ** Merge first
 * Comments requested changes and other conversations in a pull request should only be resolved by the person that started them and NOT the creator of the pull request.
-(As the permissions might not always allow this, a final comment by the creator of the conversations, saying it can be resolved is the second 0ption.)
-* Conversations should be answered by the owner of the pull request, so to show that the suggestion was either implemented or acknowledged.
+(As the permissions might not always allow this, a final comment by the creator of the conversations, saying it can be resolved is the second option.)
+* Conversations should be answered by the owner of the pull request to show that the suggestion was either implemented or acknowledged.
 * The pull request should be assigned to the person that has work on the PR, either the reviewer or the owner depending on whether a review is to be done or the review needs to be addressed.
-* A pull request should not be a draft when it is in a review.
+* A pull request should not be a draft when it is in review.
 
 == Commit
 
-* Commit messages should always start with the issue number and a hashtag, so to automatically link the corresponding issue.
+* Commit messages should always start with the issue number and a hashtag to automatically link the corresponding issue.
 * The title of a commit should be kept short and informative.
 * The description of a commit message can be used to elaborate on the title.
 * Always commit your changes in small logical units associated with an issue (see above section) using the commit message format:
@@ -89,7 +89,7 @@ devonfw/IDEasy#5: added REST service for tablemanagement
 
 * The reviewer should be assigned to the PR, if a review is needed, or the requested changes need to be checked and conversations need to be resolved.
 * After completing the review, the owner of the PR should be assigned.
-* After the team review is finished the PO (hohwille) should be assigned.
+* After the team review is finished, the PO (hohwille) should be assigned.
 * While reviewing a useful tool is the web ide provided by github.
 Simply open the `files changed` tab and press `.` on the keyboard.
 * Another useful tool is to use the feature “insert a suggestion” while writing a comment (for more detail see