diff --git a/content/collaborating/pull-requests-and-git-flow.md b/content/collaborating/pull-requests-and-git-flow.md
index 77dd612..84bfbea 100644
--- a/content/collaborating/pull-requests-and-git-flow.md
+++ b/content/collaborating/pull-requests-and-git-flow.md
@@ -8,7 +8,7 @@ eleventyNavigation:
 
 ## Benefits of a pull-request based workflow
 
-> ***TLDR:*** *Keep an eye on your repository and org permissions. Don't take sweets from strangers. Use pull requests. Easy to review, easy to manage, and only the project maintainers/owners need full access to the repo to merge them.*
+> ***TLDR:*** *Keep an eye on your repository and organization permissions. Don't take sweets from strangers. Use pull requests. Easy to review, easy to manage, and only the project maintainers/owners have permission to merge them.*
 
 Although it is perfectly possible to use a Git project on Codeberg just as single shared central repository for individuals and teams, a collaborative workflow based on pull requests provides many benefits:
 
@@ -19,11 +19,11 @@ Although it is perfectly possible to use a Git project on Codeberg just as singl
 
 Let's say, you would like to contribute to our "examples" project [knut/examples](https://codeberg.org/knut/examples).
 
-First, fork the project you would like to work on, by clicking the `fork` button in the top-right corner of the project page:
+First, fork the project you would like to work on, by clicking the `Fork` button in the top-right corner of the project page:
 
 ![Fork a project](/assets/images/collaborating/pull-requests-and-git-flow/fork-button.png)
 
-Then clone it onto your local machine. We assume that [you have set up your SSH keys](/security/ssh-key). This has to be done only once:
+Then, clone it onto your local machine. We assume that [you have set up your SSH keys](/security/ssh-key). This has to be done only once:
 
 ```shell
 git clone git@codeberg.org:<YOURCODEBERGUSERNAME>/examples.git
@@ -33,19 +33,19 @@ Now, let's create a feature branch, do some changes, commit, push, edit, commit,
 
 ```shell
 git checkout -b my_cool_feature_branch
-## do some changes
+# do some changes
 git commit -m "first feature"
-git push                        ## here you get asked to set your upstream URL, just confirm
-## do more work, edit...
+git push    # here you get asked to set your upstream URL, just confirm
+# do more work, edit...
 git add new_file.png
 git commit -m "second feature introducing a new file"
 git push
-## ...
+# ...
 git commit -m "more work, tidy-up"
 git push
 ```
 
-Now you can create the pull request by selecting your feature branch, and clicking on the pull request button:
+Now you can create a pull request by selecting your feature branch, and clicking on the pull request button:
 
 ![Create a pull request](/assets/images/collaborating/pull-requests-and-git-flow/pull-request-button.png)
 
@@ -53,7 +53,7 @@ Now you can create the pull request by selecting your feature branch, and clicki
 
 Sometimes the upstream project repository is evolving while we are working on a feature branch, and we need to rebase and resolve merge conflicts for upstream changes into our feature branch. This is not hard:
 
-In order to track the `upstream` repository, we add a second remote that is pointing to the original project. This has to be done only once:
+In order to track the `upstream` repository, we'll add a second remote that is pointing to the original project. This has to be done only once:
 
 ```shell
 git remote add upstream git@codeberg.org:knut/examples.git
@@ -69,11 +69,11 @@ git pull --rebase upstream main
 git pull
 ```
 
-That's it. You can now push your changes, and create the pull request as usual by clicking on the "pull request" button.
+That's it. You can now push your changes, and create the pull request as usual by clicking on the "New Pull Request" button.
 
-## A friendly note on owner rights, and forced push permissions
+## A friendly note on owner rights, and force push permissions
 
-Please keep in mind that project owners can do *everything*, including editing and rewriting the history using `force-push`. In some cases this is a useful feature
+Please keep in mind that project owners can do *everything*, including editing and rewriting the history using `force-push`. In some cases, this is a useful feature
 (for example to undo accidental commits or clean up PRs),
 but in most cases a transparent history based on a pull-request based workflow is surely preferable,
 especially for the default branches of your project where other people rely on intact history.