docs: fix typos (radius-project#6525)

# Description

Fix typos.

Signed-off-by: Loong <[email protected]>
Co-authored-by: Aaron Crawfis <[email protected]>
Co-authored-by: Ryan Nowak <[email protected]>
Signed-off-by: willdavsmith <[email protected]>

.github/workflows/release.yaml

@@ -113,7 +113,7 @@ jobs:
             1. Create ./docs/release-notes/${{ steps.get-version.outputs.release-version }}.md from [release note template](https://github.com/radius-project/radius/blob/main/docs/release-notes/template.md)
             2. Update the each section and add the above Change logs to the end of release note.
             3. Push release note changes to the PR branch.
-      - name: Stop the workflow if release is the offical and its release note is not found.
+      - name: Stop the workflow if release is the official and its release note is not found.
         if: ${{ !contains(steps.get-version.outputs.release-version, '-rc') && env.RELNOTE_FOUND == 'false' }}
         run: exit 1
   release:

CONTRIBUTING.md

@@ -11,7 +11,7 @@ You can find our full **contributor documentation** including instructions at th
 - [Install prerequisites](./docs/contributing/contributing-code/contributing-code-prerequisites/)
 - [Create your first commit (full walkthrough)](./docs/contributing/contributing-code/contributing-code-first-commit/)
 - [Building the repo](./docs/contributing/contributing-code/contributing-code-building/)
-- [Understanding repo organiztion](./docs/contributing/contributing-code/contributing-code-organization/)
+- [Understanding repo organization](./docs/contributing/contributing-code/contributing-code-organization/)
 - [Contribute to issues](./docs/contributing/contributing-issues/)
 - [Create pull requests](./docs/contributing/contributing-pull-requests/)
 - [Contribute to documentation](https://github.com/radius-project/docs)

deploy/Chart/README.md

@@ -2,7 +2,7 @@
 
 The Radius helm chart deploys the Radius services on a Kubernetes cluster using Helm.
 
-### Prerequisities
+### Prerequisites
 
 - Kubernetes cluster with RBAC enabled
 - Helm 3

deploy/test-pwsh-install.ps1

@@ -42,7 +42,7 @@ if ($originalPathType -ne $afterInstallPathType) {
     exit 1
 }
 
-## Verify the original path is not overriden
+## Verify the original path is not overridden
 if (!$currentPath.StartsWith($originalPath)) {
     Write-Error "Path is not using original path as a prefix after installation. Expected: $originalPath, Actual: $currentPath"
     exit 1

docs/contributing/contributing-code/contributing-code-reviewing/README.md

@@ -73,7 +73,7 @@ Our expectations for code style and linting are described in our [coding documen
 
 Beyond this we value consistency with the decisions we've already made. Ideally the code we write is consistent everywhere. Failing that, it should be consistent with the surrounding components.
 
-Outside of these expectations, please feel free to make style suggestions if you think the code could be clearer. If the submitter has a good reason for doing it the way they are, and rejects your feedback then please consider: *"Is someone credibly going to make a mistake in the future based on this decision?"* before continuing to push the issue. We want the project to be approachable for new contributors (both new to Go and new to Radius). We do not want to frustrate people with unneccessary ceremony.
+Outside of these expectations, please feel free to make style suggestions if you think the code could be clearer. If the submitter has a good reason for doing it the way they are, and rejects your feedback then please consider: *"Is someone credibly going to make a mistake in the future based on this decision?"* before continuing to push the issue. We want the project to be approachable for new contributors (both new to Go and new to Radius). We do not want to frustrate people with unnecessary ceremony.
 
 The bar is **very high** for adopting new rules or changing style guidance for the project. Please start a discussion **outside** of the context of a pull-request if you think we need to adopt a new rule.
 
@@ -167,15 +167,15 @@ More details about those roles can be found in the [community repo](https://gith
 
 ### Responsibilities of an approver
 
-Approvers are expected to display good judgement, responsibility, and competance over the *top* of the code review pyramid (Style, Correctness, Design).
+Approvers are expected to display good judgement, responsibility, and competence over the *top* of the code review pyramid (Style, Correctness, Design).
 
 It's likely that for for small changes a maintainer will delegate responsibility for approval to a maintainer working in the relevant area.
 
 Approvers are responsible for enforcing the **completeness** of a change. Each pull-request that is merged to `main` must stand on its own merits. We do not allow a submitter to merge and then "follow up" to complete the work (for example merging a change without tests). If you encounter this situation, **DO NOT** merge the pull-request, ask the submitter to complete the work. If they are unable to do so, then it is appropriate to close the pull-request without merging.
 
 ### Responsibilities of a maintainer
 
-Maintainers are expected to display good judgement, responsibility, and competance over **all** of the code review pyramid, with special emphasis on Behavior and Scope. Maintainers are responsible for the technical oversight of the project, and this often means saying **"no"** when a feature request is out of scope, or a change is too complex to maintain.
+Maintainers are expected to display good judgement, responsibility, and competence over **all** of the code review pyramid, with special emphasis on Behavior and Scope. Maintainers are responsible for the technical oversight of the project, and this often means saying **"no"** when a feature request is out of scope, or a change is too complex to maintain.
 
 Maintainers are explicitly required to review and approve new dependencies to the project.
 

docs/release-notes/v0.25.0.md

@@ -127,7 +127,7 @@ During our preview stage, an upgrade to Radius v0.25.0 requires a full reinstall
 * Fix naming example by @AaronCrawfis in https://github.com/radius-project/radius/pull/6253
 * Fix code of conduct link by @AaronCrawfis in https://github.com/radius-project/radius/pull/6254
 * Fix stuck portable resource deletion bug  by @sk593 in https://github.com/radius-project/radius/pull/6247
-* Adding metrics for recipe grabage collection and refactoring engine to take options. by @vishwahiremat in https://github.com/radius-project/radius/pull/6232
+* Adding metrics for recipe garbage collection and refactoring engine to take options. by @vishwahiremat in https://github.com/radius-project/radius/pull/6232
 * Release 0.25: Create rc release by @kachawla in https://github.com/radius-project/radius/pull/6260
 * Add new release documentation and release verification workflow by @willdavsmith in https://github.com/radius-project/radius/pull/6113
 

pkg/cli/cmd/README.md

@@ -1,7 +1,7 @@
 # CLI Commands
 
 This package `pkg/cli/cmd` is the root for our CLI commands. Commands are organized
-according to their heirarchy of sub-commands. For example `rad resource show` would be
+according to their hierarchy of sub-commands. For example `rad resource show` would be
 located in `pkg/cli/cmd/resource/show/show.go`.
 
 Some of our command names are reserved words in Go and so they can't be used as package names.

pkg/corerp/README.md

@@ -16,7 +16,7 @@
 
 1. Ensure that you update openapi spec in [/swagger](../../swagger)
 1. Generate resource type models in [/pkg/corerp/api](api/) by following the instruction.
-1. Define api version agnostic datamodel in  [/pkg/corerp/datamodel](datamodel/) and its converters beteen datamodel and api models.
+1. Define api version agnostic datamodel in  [/pkg/corerp/datamodel](datamodel/) and its converters between datamodel and api models.
 1. Define routes for new resource type and its operation APIs in [routes.go](frontend/handler/routes.go).
 1. Create resource type directory under `/pkg/frontend/controller/` and related go files by referring to [environments controller](frontend/controller/environments/).
 1. Implement operation controllers and tests.

pkg/metrics/README.md

@@ -9,7 +9,7 @@
 
 	metric.Must(global.GetMeterProvider().Meter("radius-rp")).NewInt64Counter(metricName, metric.WithUnit(unit.millisecond)).Add(ctx, int64(val), labels...)
 
-3. To use a guage, define a call back function:
+3. To use a gauge, define a call back function:
 
 	callback := func(v int) metric.Int64ObserverFunc {
 		return metric.Int64ObserverFunc(func(_ context.Context, result metric.Int64ObserverResult) { result.Observe(int64(v), labels...) })

test/infra/azure/main.bicep

@@ -20,10 +20,10 @@ param prefix string = uniqueString(resourceGroup().id)
 @description('Specifies the location where to deploy the resources. Default is the resource group location.')
 param location string = resourceGroup().location
 
-@description('Specifies the name of log anlaytics workspace. Default is {prefix}-workspace.')
+@description('Specifies the name of log analytics workspace. Default is {prefix}-workspace.')
 param logAnalyticsWorkspaceName string = '${prefix}-workspace'
 
-@description('Specifies the location of log anlaytics workspace. Default is the resource group location.')
+@description('Specifies the location of log analytics workspace. Default is the resource group location.')
 param logAnalyticsWorkspaceLocation string = resourceGroup().location
 
 @description('Specifies the location of azure monitor workspace. Default is {prefix}-azm-workspace.')

test/infra/azure/modules/grafana-onboard-metrics.bicep

@@ -27,7 +27,7 @@ param metricLabelsAllowlist string
 param metricAnnotationsAllowList string
 
 // This enables the Azure Monitor for Containers addon on the AKS cluster by patching the existing cluster
-// after deploying datacollection endpoint/rules and datacollection assocation on cluster resource.
+// after deploying datacollection endpoint/rules and datacollection association on cluster resource.
 resource enableMonitorAddon 'Microsoft.ContainerService/managedClusters@2023-05-01' = {
   name: clusterName
   location: clusterLocation

typespec/README.md

@@ -66,7 +66,7 @@ tsp format **/*.tsp
 
 You can manage multiple API versions with the decorator of [TypeSpec.Versioning](https://microsoft.github.io/typespec/standard-library/versioning/reference) library.
 
-1. Describe the supported version in `enum Verisons` of `main.tsp`. For example, [Test.Resource/main.tsp](./Test.Resource/main.tsp) supports two API verisons, `2022-08-19-preview` and `2023-08-19`.
+1. Describe the supported version in `enum Versions` of `main.tsp`. For example, [Test.Resource/main.tsp](./Test.Resource/main.tsp) supports two API versions, `2022-08-19-preview` and `2023-08-19`.
 1. Use [the versioning decorators](https://microsoft.github.io/typespec/standard-library/versioning/reference#decorators) for model and property. [Test.Resource/typesyncresources.tsp](./Test.Resource/testsyncresources.tsp) includes the example to use `@added` decorator to add new resource type in `v2023-08-19` API version.
 
 ### Link API operation to example files with `x-ms-examples` custom property