Merge branch 'current' into patch-1

website/docs/community/resources/oss-expectations.md

@@ -82,8 +82,8 @@ In some cases, the right resolution to an open issue might be tangential to the
 | `triage`           | This is a new issue which has not yet been reviewed by a maintainer. This label is removed when a maintainer reviews and responds to the issue.                                                                                                                        |
 | `bug`              | This issue represents a defect or regression from the behavior that's documented, or that you reasonably expect                                                                                                                                                        |
 | `enhancement`      | This issue represents net-new functionality, including an extension of an existing capability                                                                                                                                                                          |
-| `good first issue` | This issue does not require deep knowledge of the codebase to implement. This issue is appropriate for a first-time contributor.                                                                                                                                       |
-| `help wanted`      | This issue is trickier than a "good first issue." The required changes are scattered across the codebase, or more difficult to test. The maintainers are happy to help an experienced community contributor; they aren't planning to prioritize this issue themselves. |
+| `good_first_issue` | This issue does not require deep knowledge of the codebase to implement. This issue is appropriate for a first-time contributor.                                                                                                                                       |
+| `help_wanted`      | This issue is trickier than a "good first issue." The required changes are scattered across the codebase, or more difficult to test. The maintainers are happy to help an experienced community contributor; they aren't planning to prioritize this issue themselves. |
 | `duplicate`        | This issue is functionally identical to another open issue. The maintainers will close this issue and encourage community members to focus conversation on the other one.                                                                                              |
 | `stale`            | This is an old issue which has not recently been updated. In repositories with a lot of activity, stale issues will periodically be closed.                                                                                                                            |
 | `wontfix`          | This issue does not require a code change in the repository, or the maintainers are unwilling to merge a change which implements the proposed behavior.                                                                                                                |

website/docs/docs/cloud/manage-access/set-up-sso-saml-2.0.md

@@ -264,7 +264,7 @@ Expected **Attributes**:
 
 | Google groups  | App attributes |
 | -------------- | -------------- |
-| Name of groups | `MemberOf` |
+| Name of groups | `groups` |
 
 10. Click **Finish** to continue.
 

website/docs/guides/best-practices/how-we-style/2-how-we-style-our-sql.md

@@ -25,7 +25,7 @@ id: 2-how-we-style-our-sql
 
 - 🔙 Fields should be stated before aggregates and window functions.
 - 🤏🏻 Aggregations should be executed as early as possible (on the smallest data set possible) before joining to another table to improve performance.
-- 🔢 Ordering and grouping by a number (eg. group by 1, 2) is preferred over listing the column names (see [this classic rant](https://blog.getdbt.com/write-better-sql-a-defense-of-group-by-1/) for why). Note that if you are grouping by more than a few columns, it may be worth revisiting your model design.
+- 🔢 Ordering and grouping by a number (eg. group by 1, 2) is preferred over listing the column names (see [this classic rant](https://www.getdbt.com/blog/write-better-sql-a-defense-of-group-by-1) for why). Note that if you are grouping by more than a few columns, it may be worth revisiting your model design.
 
 ## Joins
 

website/docs/reference/artifacts/manifest-json.md

@@ -53,12 +53,4 @@ You can refer to [dbt JSON Schema](https://schemas.getdbt.com/) for info on desc
 
 **Note**: The `manifest.json` version number is related to (but not _equal_ to) your dbt version, so you _must_ use the correct `manifest.json` version for your dbt version. To find the correct `manifest.json` version, select the dbt version on the top navigation (such as `v1.5`). 
 
-Use the following table to understand how the versioning pattern works and match the Manifest version with the dbt version:
-
-| dbt version | Manifest version |
-| ----------- | ---------------- |
-| `v1.5` | [Manifest v9](https://schemas.getdbt.com/dbt/manifest/v9/index.html)
-| `v1.4` | [Manifest v8](https://schemas.getdbt.com/dbt/manifest/v8/index.html)
-| `v1.3` | [Manifest v7](https://schemas.getdbt.com/dbt/manifest/v7/index.html)
-| `v1.2` | [Manifest v6](https://schemas.getdbt.com/dbt/manifest/v6/index.html)
-| `v1.1` | [Manifest v5](https://schemas.getdbt.com/dbt/manifest/v5/index.html)
+Refer to the table at the beginning of [this page](/reference/artifacts/manifest-json) to understand how the Manifest version matches the dbt version.

website/docs/reference/dbt-jinja-functions/builtins.md

@@ -1,8 +1,8 @@
 ---
-title: "About builtins Jinja function"
+title: "About builtins Jinja variable"
 sidebar_label: "builtins"
 id: "builtins"
-description: "Read this guide to understand the builtins Jinja function in dbt."
+description: "Read this guide to understand the builtins Jinja variable in dbt."
 ---