diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 11cbd8a3e63..77bce4cca3c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -71,7 +71,7 @@ You can file new issues by selecting from our [new issue templates](https://gith ### Contribution Quality -We strongly value open source contribution and pull requests from community contributors. Please note that every pull request is reviewed and merged by an actual person on the team, which does take time and effort. That is time and effort that does take away from other valuable work. With that in mind we have an minimum set of expectations that are required of any community contribution pull request that is opened. +We strongly value open source contribution and pull requests from community contributors. Please note that every pull request is reviewed and merged by an actual person on the team, which does take time and effort. That is time and effort that does take away from other valuable work. With that in mind we have a minimum set of expectations that are required of any community contribution pull request that is opened. 1. Search [GitHub](https://github.com/angular/angular/pulls) for an open or closed PR that relates to your submission. - You don't want to duplicate existing efforts. @@ -238,7 +238,7 @@ changes to be accepted, the CLA must be signed. It's a quick process, we promise - For corporations, we'll need you to [print, sign and one of scan+email, fax or mail the form][corporate-cla]. -If you have more than one GitHub accounts, or multiple email addresses associated with a single GitHub account, you must sign the CLA using the primary email address of the GitHub account used to author Git commits and send pull requests. +If you have more than one GitHub account, or multiple email addresses associated with a single GitHub account, you must sign the CLA using the primary email address of the GitHub account used to author Git commits and send pull requests. The following documents can help you sort out issues with GitHub accounts and multiple email addresses: diff --git a/adev/src/content/guide/components/anatomy-of-components.md b/adev/src/content/guide/components/anatomy-of-components.md index bdf6f8703e0..e08682b04c4 100644 --- a/adev/src/content/guide/components/anatomy-of-components.md +++ b/adev/src/content/guide/components/anatomy-of-components.md @@ -51,7 +51,7 @@ You can alternatively choose to write your template and styles in separate files export class ProfilePhoto {} ``` -This can help separate the concerns of _presentation_ from _behavior_ in your project. You can choose one approach for your entire project, or you decide which to use for each component. +This can help separate the concerns of _presentation_ from _behavior_ in your project. You can choose one approach for your entire project, or you can decide which to use for each component. Both `templateUrl` and `styleUrl` are relative to the directory in which the component resides. diff --git a/adev/src/content/guide/components/styling.md b/adev/src/content/guide/components/styling.md index 0355304f275..b2bad65c800 100644 --- a/adev/src/content/guide/components/styling.md +++ b/adev/src/content/guide/components/styling.md @@ -94,7 +94,7 @@ For example: So, in effect, the `` element may be in the component's template, or in any of its projected or child content. -- With `:host ::ng-deep p a`, both the `` and `

` elements must be decendants of the component's host element. +- With `:host ::ng-deep p a`, both the `` and `

` elements must be descendants of the component's host element. They can come from the component's template or the views of its child components, but not elsewhere in the app. diff --git a/adev/src/content/guide/hydration.md b/adev/src/content/guide/hydration.md index 129c861dfd5..3bc7b5a36da 100644 --- a/adev/src/content/guide/hydration.md +++ b/adev/src/content/guide/hydration.md @@ -142,7 +142,7 @@ Providing a custom or a "noop" Zone.js implementation may lead to a different ti ## Errors -There are several hydration related errors you may encounter ranging from node mismatches to cases when the `ngSkipHydration` was used on an invalid host node. The most common error case that may occur is due to direct DOM manipulation using native APIs that results in hydration being unable to find or match the expected DOM tree structure on the client that was rendered by the server. The other case you may encounter this type of error was mentioned in the [Valid HTML structure](#valid-html-structure) section earlier. So, make sure the HTML in your templates are using valid structure, and you'll avoid that error case. +There are several hydration related errors you may encounter ranging from node mismatches to cases when the `ngSkipHydration` was used on an invalid host node. The most common error case that may occur is due to direct DOM manipulation using native APIs that results in hydration being unable to find or match the expected DOM tree structure on the client that was rendered by the server. The other case you may encounter this type of error was mentioned in the [Valid HTML structure](#valid-html-structure) section earlier. So, make sure the HTML in your templates is using valid structure, and you'll avoid that error case. For a full reference on hydration related errors, visit the [Errors Reference Guide](/errors). diff --git a/contributing-docs/branches-and-versioning.md b/contributing-docs/branches-and-versioning.md index 1ce5a556b94..9a5adec81e7 100644 --- a/contributing-docs/branches-and-versioning.md +++ b/contributing-docs/branches-and-versioning.md @@ -102,14 +102,14 @@ major version. Two additional target labels do not map to specific versions while still defining which branch to merge into. -| Label | Description | -| ------------------ | ----------------------------------------------------- | -| target: automation | A automated change made by the angular-robot account. | -| target: feature | A change to be made in a feature branch. | +| Label | Description | +| ------------------ | ------------------------------------------------------ | +| target: automation | An automated change made by the angular-robot account. | +| target: feature | A change to be made in a feature branch. | Changes made to a feature branch, outside of our typical branching and merging process utilize the `target: feature` branch. Additionally, the `target: automation` label, which is only able to be -utilized by the `angular-robot` account targets only the branch defined within the Github UI. +utilized by the `angular-robot` account targets only the branch defined within the GitHub UI. ### Pull request examples diff --git a/contributing-docs/caretaking.md b/contributing-docs/caretaking.md index 434fb3ae564..d4ee14a6fe7 100644 --- a/contributing-docs/caretaking.md +++ b/contributing-docs/caretaking.md @@ -26,7 +26,7 @@ pnpm ng-dev pr merge Some directories in the Angular codebase have additional protections or rules. For example, code under `//packages/core/primitives` must be merged and synced into Google separately from other changes. Attempting to combine changes in `primitives` with other changes results in an error. This -practices makes it significantly easier to rollback or revert changes in the event of a breakage or +practice makes it significantly easier to rollback or revert changes in the event of a breakage or outage. ## PRs that require global presubmits diff --git a/contributing-docs/commit-message-guidelines.md b/contributing-docs/commit-message-guidelines.md index 709e830ecd1..bdee1c87d4d 100644 --- a/contributing-docs/commit-message-guidelines.md +++ b/contributing-docs/commit-message-guidelines.md @@ -45,7 +45,7 @@ Must be one of the following: | Type | Description | | ------------ | --------------------------------------------------------------------------------------------------- | | **build** | Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) | -| **ci** | Changes to our CI configuration files and scripts (examples: Github Actions, SauceLabs) | +| **ci** | Changes to our CI configuration files and scripts (examples: GitHub Actions, SauceLabs) | | **docs** | Documentation only changes | | **feat** | A new feature | | **fix** | A bug fix | diff --git a/contributing-docs/documentation-authoring.md b/contributing-docs/documentation-authoring.md index 6d8eaa1df01..9dad61ce85a 100644 --- a/contributing-docs/documentation-authoring.md +++ b/contributing-docs/documentation-authoring.md @@ -94,7 +94,7 @@ because they are _very_ common. - Use callouts for a brief aside that offers more context on a topic that's not strictly necessary to understanding the main content - Never put multiple callouts next to each other or in proximity (such as separated - by one a line or two of text) + by a line or two of text) - Never put a callout inside another element, such as a card or table cell - **Alerts** - Use sparingly to call attention to a very brief but relevant point diff --git a/contributing-docs/triage-and-labelling.md b/contributing-docs/triage-and-labelling.md index aa717e4121b..c0b97ebe3bc 100644 --- a/contributing-docs/triage-and-labelling.md +++ b/contributing-docs/triage-and-labelling.md @@ -9,7 +9,7 @@ The owner of the component is then responsible for the detailed / component-leve ### Areas The caretaker should be able to determine the _area_ for incoming issues. -Most areas generally corresponds to a specific directory or set of directories in this repo. Some +Most areas generally correspond to a specific directory or set of directories in this repo. Some areas are more cross-cutting (e.g. for performance or security). Apply all labels that make sense for an issue. Each `area: ` label on GitHub should have a description of what it's for. diff --git a/contributing-docs/using-fixup-commits.md b/contributing-docs/using-fixup-commits.md index baac7dd95a5..a98b74cb461 100644 --- a/contributing-docs/using-fixup-commits.md +++ b/contributing-docs/using-fixup-commits.md @@ -51,7 +51,7 @@ However, amending an existing commit with the changes makes it difficult for the exactly what has changed since the last time they reviewed the Pull Request. Here is where fixup commits come in handy. -By addressing review feedback in fixup commits, you make it very straight forward for the reviewer +By addressing review feedback in fixup commits, you make it very straightforward for the reviewer to see what are the new changes that need to be reviewed and verify that their earlier feedback has been addressed. This can save a lot of effort, especially on larger Pull Requests (where having to re-review _all_