Update clone-incremental-models.md

website/docs/best-practices/clone-incremental-models.md

@@ -47,13 +47,6 @@ Because of your first clone step, the incremental models selected in your `dbt b
 
 Your CI jobs will run faster, and you're more accurately mimicking the behavior of what will happen once the PR has been merged into main. 
 
-## Additional help
-
-**Relevant `dbt clone` Slack thread:** https://dbt-labs.slack.com/archives/C05FWBP9X1U/p1692830261651829
-
-### From the "Better CI for better data quality" coalesce talk
-"If you use the incremental materialization in your dbt project, you should consider cloning your relevant, pre-existing incremental models into your PR-specific schema as the first step of your CI check. This will force your second step to run in incremental mode (where is_incremental is true) because now the models already exist in your PR-specific schema (via cloning). This is beneficial because it more accurately mimics what will happen when you merge your changes into production and it will save time and money by not rebuilding your incremental models (which are often large data sets) from scratch for every PR that modifies them." -Grace Goheen, dbt Labs Product Manager
-
 ### Expansion on "think schema drift" where [on_schema_change](/docs/build/incremental-models#what-if-the-columns-of-my-incremental-model-change) config is set to `fail`" from above
 
 Imagine you have an incremental model `my_incremental_model` with the following config:
@@ -83,4 +76,4 @@ There’s probably no perfect solution here; it’s all just tradeoffs! Our pref
 ### Expansion on "why `state:old`"
 
 For brand new incremental models, you want them to run in `full-refresh` mode in CI, because they will run in `full-refresh` mode in production when the PR is merged into `main`. They also don't exist yet in the production environment... they're brand new!
-If you don't specify this, you won't get an error just a “No relation found in state manifest for…”. So, it technically works without specifying `state:old` but adding `state:old` is more explicit and means it won't even try to clone the brand new incremental models.
+If you don't specify this, you won't get an error just a “No relation found in state manifest for…”. So, it technically works without specifying `state:old` but adding `state:old` is more explicit and means it won't even try to clone the brand new incremental models.