feat: terminology added (#184)

Co-authored-by: BekahHW <34313413+BekahHW@users.noreply.github.com>

docs/contributing/introduction-to-contributing.md

@@ -144,7 +144,7 @@ Do you have questions? Join the conversation in our [Discord](https://discord.gg
 ## Coding tips
 
 - Ask questions if you are stuck.
-- Use [CSS variables](https://github.com/open-sauced/open-sauced/blob/HEAD/src/styles/variables.js).
+- Use [CSS variables.](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties)
 - Always use [rel="noreferrer" on all target="\_blank" links](https://web.dev/external-anchors-use-rel-noopener/).
 
 ## License

docs/maintainers/setting-up-a-new-repository.md

@@ -13,15 +13,15 @@ For the purpose of this tutorial, our target demo repository will be called `ope
 
 The steps described here mirror [open-sauced/check-engines](https://github.com/open-sauced/check-engines).
 
-The octoherd scripts assume you have exported a programatic token similar to:
+The octoherd scripts assume you have exported a programmatic token similar to:
 
 ```shell
 export GH_TOKEN="ghp_Q8TZZT9ypgqw3EeABoCWPcwZBHpjZJ9hI42n"
 ```
 
 ## Creating a new repo
 
-Don't spend too much time thinking of a name or a catchy description, just set license to MIT and rocket jump!
+Don't spend too much time thinking of a name or a catchy description, just set the license to MIT and rocket jump!
 
 ![create a new repository](../../static/img/contributing-maintainers-create-repository.png)
 
@@ -35,11 +35,10 @@ Copy most of the relevant settings with:
 
 ```shell
 npx octoherd-script-sync-repo-settings \
-  --template "open-sauced/open-sauced" \
+  --template "open-sauced/app" \
   -T $GH_TOKEN \
   -R "open-sauced/check-engines"
 ```
-
 Otherwise you can disable "Projects" and "Wikis" for the selected repository as we are handling them on a larger scale.
 
 ## Syncing labels with opensauced.pizza
@@ -52,23 +51,26 @@ npx octoherd-script-copy-labels \
   -T $GH_TOKEN \
   -R "open-sauced/check-engines"
 ```
-
 Then go back to your repository and delete:
-
 - documentation
 - 👀 needs-triage (green background one)
 - other potential duplicates if the above race condition is different
 
+> In this context, `race condition` refers to a situation where multiple labels are being deleted simultaneously. This can cause issues if the order in which the labels are deleted affects the final outcome. Therefore, it's important to ensure that the deletion of labels is properly synchronized and controlled to avoid any race conditions.
+
+In other words, if two of the directories (e.g., `👀 needs-triage` and `documentation` are deleted at the same, it is possible that the third directory(`potential duplicates`) will not be deleted.
+To avoid the `race condition`, the code must delete the directories in a specific order. For example, it could delete the `documentation directory` first, then the `👀 needs-triage` directory, and then the other `potential duplicates` directory.
+
 ## Syncing branch protections with opensauced.pizza
 
 This topic is more complex but in a sense tap the main branch and enable
 everything except "Restrict who can dismiss pull request reviews" and "Restrict who can push to matching branches" in the first section.
 
 ![maximum merge protections](../../static/img/contributing-maintainers-merge-protections.png)
 
-The "Rules applied to everyone including administrators" is more on an unused override.
+The "Rules applied to everyone including administrators" is more of an unused override.
 
-Most of the time this process is super manual but in the limited cases where we need this run:
+Most of the time, this process is super manual, but in the limited cases where we need this run:
 
 ```shell
 npx @octoherd/script-sync-branch-protections \
@@ -85,14 +87,14 @@ Pull requests require [triage](https://github.com/open-sauced/open-sauced/blob/m
 
 Most `node` projects will require [release automation](https://github.com/open-sauced/open-sauced/blob/main/.github/workflows/release.yml) powered by [@open-sauced/semantic-release-conventional-config](https://github.com/open-sauced/semantic-release-conventional-config).
 
-Other [development workflows](https://github.com/open-sauced/open-sauced/tree/main/.github/workflows) are less common and opinionated towards decentralised collaboration. Use these as example backbones for your new repository.
+Other [development workflows](https://github.com/open-sauced/open-sauced/tree/main/.github/workflows) are less common and opinionated towards decentralized collaboration. Use these as examples of backbones for your new repository.
 
 ## Setting up environments and secrets
 
-As you may have noticed in the previous step or in the actions visualisations, the release workflows enable named environments.
+As you may have noticed in the previous step or in the action visualizations, the release workflows enable named environments.
 
 These have to be manually set up, along with their secrets and branch protections.
 
 ![create environment](../../static/img/contributing-maintainers-env.png)
 
-If using `npm` or `ghcr` it is likely you will add a couple variables here.
+If using `npm` or `ghcr`, it is likely you will add a couple of variables here.

docs/technical/resolve-merge-conflicts.md

@@ -14,11 +14,48 @@ In literally every case it is advised _**not**_ to use the `Resolve conflicts` b
 
 ![don't resolve conflicts like this](../../static/img/contributing-resolve-merge-conflicts-dont-do.png)
 
-The above will at best achieve a ready to merge pull request with visible inconsistencies.
+The above will at best achieve a ready-to-merge pull request with visible inconsistencies.
+
+
+## Repository setup
+
+Fork and clone the project using the `gh` command line interface:
+
+```shell
+gh repo clone 0-vortex/open-sauced
+```
+
+Running `git remote -v` will output:
+
+```shell
+origin git@github.com:0-vortex/open-sauced.git (fetch)
+origin git@github.com:0-vortex/open-sauced.git (push)
+upstream git@github.com:open-sauced/open-sauced.git (fetch)
+upstream git@github.com:open-sauced/open-sauced.git (push)
+```
+
+Fork and clone the project using the `git` command line interface:
+
+```shell
+git clone git@github.com:0-vortex/open-sauced.git
+```
+
+Running `git remote -v` will output:
+
+```shell
+origin git@github.com:0-vortex/open-sauced.git (fetch)
+origin git@github.com:0-vortex/open-sauced.git (push)
+```
+
+As an additional step for this tutorial, we need to add the `upstream` remote:
+
+```shell
+git remote add upstream git@github.com:open-sauced/open-sauced.git
+```
 
 ## Update
 
-First get the default branch changes:
+First, get the default branch changes:
 
 ```shell
 git fetch origin --recurse-submodules=no --progress --prune
@@ -53,7 +90,7 @@ It will look like this:
 
 ## Resolve conflicts
 
-Since this pull request does not modify the `package.json` file it is safe to fast forward the changes from `origin/main`:
+Since this pull request does not modify the `package.json` file it is safe to fast-forward the changes from `origin/main`:
 
 ```shell
 # overwrite with origin/main changes
@@ -101,7 +138,7 @@ It should look something like this:
 
 The result of the above commands can be viewed at [283ff8cd788c550309ff0d1d5a9a5a97ec0731b2](https://github.com/open-sauced/open-sauced/pull/1078/commits/283ff8cd788c550309ff0d1d5a9a5a97ec0731b2)
 
-GitHub will conveniently display only you merge conflict changes:
+GitHub will conveniently display only your merge conflict changes:
 
 ![view merge commit](../../static/img/contributing-resolve-merge-conflicts-view-merge-commit.png)
 
@@ -111,7 +148,7 @@ And it's ready to merge:
 
 ## Dependency updates
 
-When dealing with dependency and lock file updates there are multiple use cases to consider, however as a baseline, the OpenSauced triage team will not prioritize parallel main features as seen in the roadmap.
+When dealing with dependency and lock file updates, there are multiple use cases to consider; however, as a baseline, the OpenSauced triage team will not prioritize parallel main features as seen in the roadmap.
 
 However when that happens, it is advised to:
 
@@ -120,6 +157,6 @@ However when that happens, it is advised to:
 - fast-forward your added lines to `package.json`
 - run `npm ci` to delete local modules and create dependency resolution from `upstream/beta`
 
-Visual diffing is advised however not following the git commit history procedure will result in a rogue pull request that scope creeps into dependency updates.
+Visual diffing is advised; however, not following the git commit history procedure will result in a rogue pull request that creeps into dependency updates.
 
-Generally speaking, just adding things to a lockfile will not be troublesome and since this is a licensed project, we should be careful when adding dependencies.
+Generally speaking, just adding things to a lock file will not be troublesome, and since this is a licensed project, we should be careful when adding dependencies.