diff --git a/docs/contributing/contributing-code/contributing-code-control-plane/configSettings.md b/docs/contributing/contributing-code/contributing-code-control-plane/configSettings.md index e8f631aeb0..6111fedc99 100644 --- a/docs/contributing/contributing-code/contributing-code-control-plane/configSettings.md +++ b/docs/contributing/contributing-code/contributing-code-control-plane/configSettings.md @@ -88,7 +88,7 @@ The following are properties that can be specified for UCP: | host | Domain name of the server | `0.0.0.0` | | port | HTTP port | `8080` | | pathBase | HTTPRequest PathBase | `""` | -| authType | The environmnet authentification type (e.g. client ceritificate, etc) |`ClientCertificate` | +| authType | The environment authentication type (e.g. client ceritificate, etc) |`ClientCertificate` | | armMetadataEndpoint | Endpoint that provides the client certification | `https://admin.api-dogfood.resources.windows-int.net/metadata/authentication?api-version=2015-01-01` | | enableArmAuth | If set, the ARM client authentifictaion is performed (must be `true`/`false`) | `true` | diff --git a/docs/contributing/contributing-code/contributing-code-reviewing/README.md b/docs/contributing/contributing-code/contributing-code-reviewing/README.md index f4a5426e44..2abe00c528 100644 --- a/docs/contributing/contributing-code/contributing-code-reviewing/README.md +++ b/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 unneccesary 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 unneccessary 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. @@ -117,7 +117,7 @@ Review feedback for design should focus on the following points: --- -Go is a pragmatic and simple language and our designs should leverage its simplicity. In general we want to avoid complex hierarchies or object-orientied abstractions where possible. The flip-side of this is that because Go is a simple language, the type system and what it can express is limited. +Go is a pragmatic and simple language and our designs should leverage its simplicity. In general we want to avoid complex hierarchies or object-oriented abstractions where possible. The flip-side of this is that because Go is a simple language, the type system and what it can express is limited. Where possible we want to optimize for correctness, testability, and simplicity in that order. @@ -167,7 +167,7 @@ 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, responsiblity, and competance over the *top* of the code review pyramid (Style, Correctness, Design). +Approvers are expected to display good judgement, responsibility, and competance 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. @@ -175,7 +175,7 @@ Approvers are responsible for enforcing the **completeness** of a change. Each p ### Responsibilities of a maintainer -Maintainers are expected to display good judgement, responsiblity, 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 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 explicitly required to review and approve new dependencies to the project. diff --git a/docs/contributing/contributing-code/contributing-code-writing/README.md b/docs/contributing/contributing-code/contributing-code-writing/README.md index 42faf0cd8a..511e82edff 100644 --- a/docs/contributing/contributing-code/contributing-code-writing/README.md +++ b/docs/contributing/contributing-code/contributing-code-writing/README.md @@ -10,7 +10,7 @@ For learning Go, we recommend the following resources: - [Tour of Go](https://go.dev/tour/welcome/1) - [Effective Go](https://go.dev/doc/effective_go) -- [Offical tutorials](https://go.dev/doc/) +- [Official tutorials](https://go.dev/doc/) We're happy to accept pull-requests and give code review feedback aimed at newbies. If you have programmed in other languages before, we are confident you can pick up Go and start contributing easily. diff --git a/docs/contributing/contributing-releases/README.md b/docs/contributing/contributing-releases/README.md index a600ff9f2b..7858da7083 100644 --- a/docs/contributing/contributing-releases/README.md +++ b/docs/contributing/contributing-releases/README.md @@ -27,7 +27,7 @@ In the project-radius/samples repo, run the [Test Quickstarts](https://github.co > For now, this is a manual task. Soon, this workflow will be triggered automatically. -> There is a possiblity that the workflow run failed from flaky tests. Try re-running, and if the failure is persistent, then there should be further investigation. +> There is a possibility that the workflow run failed from flaky tests. Try re-running, and if the failure is persistent, then there should be further investigation. If this workflow run fails, or if we encounter an issue with an RC release, please refer to "Patching" below. diff --git a/docs/ucp/code_walkthrough.md b/docs/ucp/code_walkthrough.md index dcdd7609fd..ab32d6fe69 100644 --- a/docs/ucp/code_walkthrough.md +++ b/docs/ucp/code_walkthrough.md @@ -19,7 +19,7 @@ For proxying requests to the AWS plane, UCP needs to perform request translation

## UCP Resource Definitions -The swagger defintions for UCP resources are defined in swagger/specification/ucp/resource-manager/UCP/preview/2023-10-01-preview/ucp.json. +The swagger defination for UCP resources are defined in swagger/specification/ucp/resource-manager/UCP/preview/2023-10-01-preview/ucp.json.