GITBOOK-696: Merge queue docs typos, small fixes

merge-queue/batching.md

@@ -16,7 +16,7 @@ example of testing pull requests in batches of 3
 
 ## Enable Batching
 
-Batching is enabled in the Merge Settings of your repo in the [Trunk webapp](https://app.trunk.io/login?intent=merge).
+Batching is enabled in the Merge Settings of your repo in the [Trunk web app](https://app.trunk.io/login?intent=merge).
 
 <figure><img src="../.gitbook/assets/image (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 

merge-queue/common-problems.md

@@ -10,9 +10,9 @@ Solution: Most likely you did not set up the required status checks to trigger f
 
 ## My PR appears to be ready but isn't entering the Merge Queue?
 
-First, check the Trunk UI where it shows what Trunk is waiting on before putting your PR into the merge queue. **(screenshot)**
+First, check the Trunk web app to see what Trunk is waiting on before putting your PR into the merge queue. 
 
-Next, if something on that page doesn't look right (for example, it says that GitHub is still checking the merge-ability of the PR), comment `/trunk merge` again in the PR.
+Next, if something on that page doesn't look right, for example, it says that GitHub is still checking the mergeability of the PR, comment `/trunk merge` again in the PR.
 
 ## My PR is constantly failing when it starts testing because of "GitHub errors".
 
@@ -35,6 +35,6 @@ By default, both [dependabot](https://docs.github.com/en/code-security/dependabo
 
 ## I have an emergency PR that needs to merge right now. How can I do that?
 
-To merge a PR in the event of an emergency, you can just merge the PR directly though GitHub as you normally would. The merge queue will restart everything it is currently testing to account for the new head of the merge branch.
+To merge a PR in the event of an emergency, you can just merge the PR directly through GitHub as you normally would. The merge queue will restart everything it is currently testing to account for the new head of the merge branch.
 
 We currently have other features planned to help with this, so stay tuned!

merge-queue/metrics.md

@@ -18,7 +18,7 @@ You can access the metrics in your Trunk Merge Queue by navigating to the Trunk
 
 The date ranges selector at the top left of the dashboard allows you to filter the data displayed by date and time. You can display time buckets by the day or hour in the day/hour dropdown.
 
-The metrics displayed only include data that have **completed within the time rage**, jobs started but not completed during the selected time **will not be displayed**. 
+The metrics displayed only include data that have **completed within the time range**, jobs started but not completed during the selected time **will not be displayed**. 
 
 {% hint style="info" %}
 When working across multiple time zones, enable **Time in UTC** to ensure everyone sees the same data. 
@@ -28,7 +28,7 @@ When working across multiple time zones, enable **Time in UTC** to ensure everyo
 
 Conclusion count displays the number of pull requests that exited the merge queue during each time bucket. This includes passes, failures, and cancellations. Passes and failures signal a PR that was tested in the queue to completion, while canceled signals that the request to merge terminated before testing finished or before testing began.
 
-Conclusion counts are an important signal to potential bottlenecks or underlying issues with your merging process, as a failure or cancellation in the merge queue can force other PRs to r**estart their testing**. A spike in the number of failures or passes can indicate a potential problem to investigate.
+Conclusion counts are an important signal to potential bottlenecks or underlying issues with your merging process, as a failure or cancellation in the merge queue can force other PRs to **restart their testing**. A spike in the number of failures or passes can indicate a potential problem to investigate.
 
 Conclusions are tagged with a reason to give further insights into how merges pass or fail in the queue. You can show or hide conclusions of a particular reason by using the **+ Add** button.
 
@@ -38,7 +38,7 @@ Conclusions are tagged with a reason to give further insights into how merges pa
 
 Time in queue shows how long each PR spends in the Merge Queue from the moment the PR enters the queue to the moment when it exits the queue, either from merging, failing, or being canceled. 
 
-Understanding the amount of time a pull request is spending in the queue is important for ensuring your merge process continues to ship code quickly. A spike in the time to merge indicates a slowdown somewhere that's impacting all developers. For example, it's taking longer to run tests on PRs, PRs are waiting too long to start testing, or constant failures in the queue are causing PRs to take longer to merge
+Understanding the amount of time a pull request spends in the queue is important for ensuring your merge process continues to ship code quickly. A spike in the time to merge indicates a slowdown somewhere that's impacting all developers. For example, it's taking longer to run tests on PRs, PRs are waiting too long to start testing, or constant failures in the queue are causing PRs to take longer to merge
 
 The time in queue can be displayed as different statistical measures. You can show or hide them by using the **+ Add** button.
 

merge-queue/parallel-queues/README.md

@@ -28,15 +28,15 @@ To run in parallel mode, each pull request needs to be inspected for its impacte
 \
 In the example above, the pull requests **A**, **B**, and **D** can be tested in isolation since they affect distinct targets - `backend`, `frontend` and `docs`. The **C** pull request affects both `frontend` and `backend` and would be tested predictively with the changes in both **A** and **B**.\
 \
-In order to understand the interactions or dependent changes between pull requests, Trunk Merge Queue provides an API for posting the list of **impacted targets** that result from code changes in every PR. When Trunk Merge Queue is running in parallel mode, pull requests will not be processed until the list of impacted targets are uploaded.\
+To understand the interactions or dependent changes between pull requests, Trunk Merge Queue provides an API for posting the list of **impacted targets** that result from code changes in every PR. When Trunk Merge Queue is running in parallel mode, pull requests will not be processed until the list of impacted targets are uploaded.\
 \
 **What are Impacted Targets?**\
-Impacted targets are metadata that describe the logical changes of a pull request. An impacted target is a string that can be as expressive as a bazel target or the name of a file folder. Calculating impacted targets with a purpose-built build system will provide absolute correctness for the merge queue, but more lightweight glob or folder-based approaches can also work with fewer guarantees around correctness.\
+Impacted targets are metadata that describe the logical changes of a pull request. An impacted target is a string that can be as expressive as a Bazel target or the name of a file folder. Calculating impacted targets with a purpose-built build system will provide absolute correctness for the merge queue, but more lightweight glob or folder-based approaches can also work with fewer guarantees around correctness.\
 \
 **Posting impacted targets from your pull requests**\
 We ship several pre-built solutions for popular build systems to automatically calculate and post the impacted targets of a pull request. If you are using another build system, we would be happy to work with you to add support for your specific build system.
 
-<table data-column-title-hidden data-view="cards"><thead><tr><th></th><th data-hidden></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Bazel</strong></td><td></td><td></td><td><a href="../../.gitbook/assets/Bazel.png">Bazel.png</a></td><td><a href="bazel.md">bazel.md</a></td></tr><tr><td><strong>Nx</strong></td><td></td><td></td><td><a href="../../.gitbook/assets/NX.png">NX.png</a></td><td><a href="nx.md">nx.md</a></td></tr><tr><td><strong>Other</strong></td><td></td><td></td><td><a href="../../.gitbook/assets/Group 1277.png">Group 1277.png</a></td><td><a href="api.md">api.md</a></td></tr></tbody></table>
+<table data-column-title-hidden data-view="cards"><thead><tr><th></th><th data-hidden></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Bazel</strong></td><td></td><td></td><td><a href="../../.gitbook/assets/bazel-dark.png">bazel-dark.png</a></td><td><a href="bazel.md">bazel.md</a></td></tr><tr><td><strong>Nx</strong></td><td></td><td></td><td><a href="../../.gitbook/assets/NX.png">NX.png</a></td><td><a href="nx.md">nx.md</a></td></tr><tr><td><strong>Other</strong></td><td></td><td></td><td><a href="../../.gitbook/assets/Group 1277.png">Group 1277.png</a></td><td><a href="api.md">api.md</a></td></tr></tbody></table>
 
 **Enable Parallel Modes**\
 Merge can be swapped between `Single` and `Parallel` mode at any time. If there are no PRs in the merge queue when switching, the switch will be immediate. If there are PRs in the queue, then Merge will go into the `Switching Modes` state, where it'll wait for all currently testing PRs to merge before switching modes. During this time, PRs will not be able to enter the queue.

merge-queue/parallel-queues/api.md

@@ -4,13 +4,13 @@ description: Upload custom list of impacted targets
 
 # API
 
-Impacted Targets should be computed for every PR. The list of impacted targets should be computed by comparing two different SHAs: the **head of the target branch**, and the **merge commit of the pr**. 
+Impacted Targets should be computed for every PR. The list of impacted targets should be computed by comparing two different SHAs: the **head of the target branch**, and the **merge commit of the pr**.
 
 {% hint style="info" %}
 Our [reference implementation](https://github.com/trunk-io/bazel-action/tree/main/src/scripts) may be useful in guiding your implementation.
 {% endhint %}
 
-**POST** the list of impacted targets here:`https://api.trunk.io:443/v1/setImpactedTargets`. 
+**POST** the list of impacted targets here:`https://api.trunk.io:443/v1/setImpactedTargets`.
 
 ```ssml
 HEADERS:
@@ -36,7 +36,7 @@ BODY: {
 `impactedTargets` allows specifying either an array of strings representing the impacted targets from the PR or the string "ALL" (note that this is explicitly not in an array and is just the string "ALL"). Specifying "ALL" is the equivalent of saying that everything that comes into the graph after this PR should be based on this one, which is useful when your PR contains changes that affect the whole repo (such as editing `trunk.yaml` or a GitHub workflow).
 
 **Handling Forked Pull Requests**\
-The HTTP POST must contain the `x-api-token` to prove that it is a valid request from a workflow your org controls. _Workflows which come from forked PRs most likely will not have access to the Trunk org token_ required for the HTTP POST above. In this case you should provide the **run ID** of the workflow as the  `x-forked-workflow-run-id` header in place of the `x-api-token`. This ID can be  obtained from [the GitHub context](https://docs.github.com/en/actions/learn-github-actions/contexts#github-context) as `${{ github.run_id }}`. Trunk Merge Queue will verify that the ID belongs to a currently running workflow originating from a forked PR with a SHA that matches the one provided in the request and allow it through.
+The HTTP POST must contain the `x-api-token` to prove that it is a valid request from a workflow your org controls. _Workflows that come from forked PRs most likely will not have access to the Trunk org token_ required for the HTTP POST above. In this case, you should provide the **run ID** of the workflow as the `x-forked-workflow-run-id` header in place of the `x-api-token`. This ID can be obtained from [the GitHub context](https://docs.github.com/en/actions/learn-github-actions/contexts#github-context) as `${{ github.run_id }}`. Trunk Merge Queue will verify that the ID belongs to a currently running workflow originating from a forked PR with a SHA that matches the one provided in the request and allow it through.
 
 {% hint style="info" %}
 We do not recommend using an event trigger like `pull_request_target.` This would allow workflows from forked PRs to get secrets, which is a security risk and would open your repo to attackers making forks, adding malicious code, and then running it against your repo to exfiltrate information. (see[ Keeping your GitHub Actions and workflows secure](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)).

merge-queue/parallel-queues/bazel.md

@@ -7,7 +7,7 @@ description: Instructions for enabled dynamic parallel queues powered by your ba
 Leveraging [parallel mode](../#single-mode-vs.-parallel-mode) for Trunk Merge Queue is easy for Bazel-enabled repos because Bazel already knows the structure of your code and can automatically generate a dependency graph. Merge can use this information in parallel mode to create dynamic parallel queues enabling your pull requests to run through your Merge Queue faster.\
 \
 **How do we create parallel queues?**\
-By understanding which bazel targets a pull request affects, we can build a real-time graph and detect intersection points and where distinct non-overlapping graphs exist. This information is essentially a list of unique target names, which can then be used in real time to understand along which targets pull requests might overlap.
+By understanding which Bazel targets a pull request affects, we can build a real-time graph and detect intersection points and where distinct non-overlapping graphs exist. This information is essentially a list of unique target names, which can then be used in real time to understand along which targets pull requests might overlap.
 
 **Calculating impacted targets in GitHub Actions**\
 Trunk ships a [GitHub action](https://github.com/trunk-io/bazel-action) that will generate the list of impacted targets for a pull request and post that information to the Trunk Merge Queue service.

merge-queue/pr-prioritization.md

@@ -8,7 +8,7 @@ When a high-priority change must be merged quickly but still validated by the Me
 
 ## Setting Priorities
 
-You specify a custom priority for a pull request at the time on insertion into the queue:
+You specify a custom priority for a pull request at the time of insertion into the queue:
 
 {% tabs %}
 {% tab title="GitHub comment" %}
@@ -46,9 +46,9 @@ valid values for the priority level:
 
 ## How Priority Affects PR Order
 
-PRs with a higher priority will always begin testing before any other PR that isn't currently being tested, ensuring that prioritized PRs move into the queue as soon as they can. A PR without a priority will use the default `medium` (100) priority. If there is already a PR in the queue with the exact same priority then the new one will be behind it. 
+PRs with a higher priority will always begin testing before any other PR that isn't currently being tested, ensuring that prioritized PRs move into the queue as soon as they can. A PR without a priority will use the default `medium` (100) priority. If there is already a PR in the queue with the same priority then the new one will be behind it. 
 
-When prioritizing a PR, Merge will explicitly **not interrupt** any currently testing PR, as it is usually costly to restart testing on PRs even if you want another PR to be sooner. Because of this, if a PR is submitted with a priority and there is still room in the queue to begin testing PRs, it will being testing as normal without interrupting other PRs.
+When prioritizing a PR, Merge will explicitly **not interrupt** any currently testing PR, as it is usually costly to restart testing on PRs even if you want another PR to be sooner. Because of this, if a PR is submitted with a priority and there is still room in the queue to begin testing PRs, it will begin testing as normal without interrupting other PRs.
 
 **There is one exception to this rule.** Sometimes, when there is a PR urgent enough to get in that it is worth the cost of restarting a currently testing PR, you can move the new PR to the front using the `"urgent"` priority. This is the only time Merge will reschedule a PR that is already in testing.
 
@@ -58,10 +58,10 @@ Say you have a queue that is configured to test two PRs at once. The queue curre
 
 <img src="../.gitbook/assets/file.excalidraw (1).svg" alt="queue with two testing PRs and one pending" class="gitbook-drawing">
 
-If you submit a PR D with a `"high"` priority it will be put in front of C (since it is a higher priority than C and C is not testing). D will begin as soon either A or B finishes, like this:
+If you submit a PR D with a `"high"` priority it will be put in front of C (since it is a higher priority than C and C is not testing). D will begin as soon as either A or B finishes, like this:
 
 <img src="../.gitbook/assets/file.excalidraw (1) (1).svg" alt="queue with two testing PRs and a new higher priority pending PR" class="gitbook-drawing">
 
-If instead you submit PR D with an `"urgent"` priority, then D would be tested immediately,  A would be restarted, and B would be bumped back to pending, like this:
+If instead, you submit PR D with an `"urgent"` priority, then D would be tested immediately,  A would be restarted, and B would be bumped back to pending, like this:
 
 <img src="../.gitbook/assets/file.excalidraw (2).svg" alt="queue with an urgent PR moved to the front and a normal PR restarting" class="gitbook-drawing">