Docs Changes for DevDot Migration

website/docs/plugin/sdkv2/best-practices/index.mdx

@@ -18,8 +18,7 @@ configuration management systems, et. al). While each provider is unique, over
 the years we’ve accumulated some patterns that should be adhered to, to
 ensure a consistent user experience when using Terraform for any given provider.
 Listed below are a few best practices we’ve found that generally apply to most
-Providers, with a brief description of each, and link to read more. Each
-practice is also linked in navigation on the left.
+Providers, with a brief description of each, and link to read more. 
 
 This section is a work in progress, with more sections to come.
 

website/docs/plugin/sdkv2/guides/v2-upgrade-guide.mdx

@@ -147,10 +147,10 @@ func Create(ctx context.Context, *schema.ResourceData, meta any) diag.Diagnostic
         // this is the standard way to convert a Go error to Diagnostics
         return diag.FromErr(err)
     }
-    
+
     // Warning or Errors can be collected in a slice type
     var diags diag.Diagnostics
-    
+
     // Diagnostics supports warnings, a detailed message
     // as well as linking to a specific attribute
     // see github.com/hashicorp/go-cty for learning the Path types
@@ -179,8 +179,7 @@ The `helper/schema.Resource` and `helper/schema.Schema` types both now have
 groundwork for future improvements to Terraform, and will have no visible
 effect to the Terraform CLI at the moment. If you’d like to build in support
 for your provider starting now, it’s recommended that you set these properties
-to whatever you’d document the resource or field as in your terraform.io docs
-for the resource.
+to whatever you would document the resource or field as in your provider documentation for the resource.
 
 You can globally set the format of the text in these fields by setting the
 global variable `helper/schema.DescriptionKind`. Its acceptable values are

website/docs/plugin/sdkv2/index.mdx

@@ -11,7 +11,7 @@ Terraform Plugin SDKv2 is an established way to develop Terraform Plugins on [pr
 
 ## Get Started
 
-- Try the [Call APIs with Custom Providers](https://learn.hashicorp.com/collections/terraform/providers?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorials on HashiCorp Learn.
+- Try the [Call APIs with Custom Providers](https://learn.hashicorp.com/collections/terraform/providers?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorials.
 - Clone the [terraform-provider-scaffolding](https://github.com/hashicorp/terraform-provider-scaffolding) template repository on GitHub.
 
 ## Key Concepts

website/docs/plugin/sdkv2/resources/import.mdx

@@ -19,7 +19,7 @@ $ terraform import example_thing.foo abc123
 
 Implementing import support requires three changes: an `Importer` `State` function in the resource code, a `TestStep` with `ImportState: true` in the acceptance tests, and documentation of the import ID format.
 
-> **Hands-on:** Try the [Implement Import](https://learn.hashicorp.com/tutorials/terraform/provider-import?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial on HashiCorp Learn. In this tutorial, you will implement the import functionality on an example Terraform provider.
+> **Hands-on:** Try the [Implement Import](https://learn.hashicorp.com/tutorials/terraform/provider-import?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial. In this tutorial, you will implement the import functionality on an example Terraform provider.
 
 ### Resource Code Implementation
 

website/docs/plugin/sdkv2/resources/index.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # Resources
 
-A key component to Terraform Provider development is defining the creation, read, update, and deletion functionality of a resource to map those API operations into the Terraform lifecycle. While the basic aspects of developing Terraform resources have already been covered in the [Call APIs with Terraform Providers Learn collection](https://learn.hashicorp.com/collections/terraform/providers?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) and [Schemas](/plugin/sdkv2/schemas), this section covers more advanced features of resource development.
+A key component to Terraform Provider development is defining the creation, read, update, and deletion functionality of a resource to map those API operations into the Terraform lifecycle. While the basic aspects of developing Terraform resources have already been covered in the [Call APIs with Terraform Providers tutorial](https://learn.hashicorp.com/collections/terraform/providers?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) and [Schemas](/plugin/sdkv2/schemas), this section covers more advanced features of resource development.
 
 ## Import
 

website/docs/plugin/sdkv2/testing/acceptance-tests/index.mdx

@@ -32,7 +32,7 @@ left over from testing and development.
 
 Provider acceptance tests use a Terraform CLI binary to run real Terraform commands. The goal is to approximate using the provider with Terraform in production as closely as possible.
 
-Terraform Core and Terraform Plugins act as gRPC client and server, implemented using HashiCorp's [go-plugin](https://github.com/hashicorp/go-plugin) system (see the [RPC Plugin Model](https://github.com/hashicorp/terraform/tree/main/docs/plugin-protocol) section of the Terraform Core documentation).  When `go test` is run, the SDK's acceptance test framework starts a plugin server in the same process as the Go test framework. This plugin server runs for the duration of the test case, and each Terraform command (`terraform plan`, `terraform apply`, etc) creates a client that reattaches to this server.
+Terraform Core and Terraform Plugins act as gRPC client and server, implemented using HashiCorp's [go-plugin](https://github.com/hashicorp/go-plugin) system (refer to the [RPC Plugin Model](https://github.com/hashicorp/terraform/tree/main/docs/plugin-protocol) section of the Terraform documentation).  When `go test` is run, the SDK's acceptance test framework starts a plugin server in the same process as the Go test framework. This plugin server runs for the duration of the test case, and each Terraform command (`terraform plan`, `terraform apply`, etc) creates a client that reattaches to this server.
 
 Real-world Terraform usage requires a config file and Terraform working directory on the local filesystem. The framework uses the [`internal/plugintest` package](https://pkg.go.dev/github.com/hashicorp/terraform-plugin-sdk/v2/internal/plugintest) to manage temporary directories and files during test runs. This library is not intended for use directly by provider developers.
 

website/docs/plugin/sdkv2/testing/index.mdx

@@ -11,8 +11,7 @@ Here we cover information needed to write successful tests for Terraform
 Plugins. Tests are a vital part of the Terraform ecosystem, verifying we can
 deliver on our mission to safely and predictably create, change, and improve
 infrastructure. Documentation for Terraform tests are broken into categories
-briefly described below. Each category has more detailed information by clicking
-on the matching item in the left navigation.
+briefly described on this page. Each category has more detailed information on a separate page within the documentation.
 
 -> **Note:** Recent versions of Terraform CLI also support [developer overrides in the CLI configuration](/cli/config/config-file#development-overrides-for-provider-developers), which can be useful for manually testing providers. The acceptance testing framework uses real Terraform CLI executions, so developer overrides are only recommended as a last resort option for missing functionality.
 
@@ -46,7 +45,7 @@ For a given plugin, Acceptance Tests can be run from the root of the project by
 using a common make task:
 
 ```shell
-$ make testacc 
+$ make testacc
 ```
 
 See [Acceptance Testing](/plugin/sdkv2/testing/acceptance-tests) to learn more.
@@ -67,8 +66,3 @@ $ make test
 ```
 
 See [Unit Testing](/plugin/sdkv2/testing/unit-testing) to learn more.
-
-## Next Steps
-
-See the navigation on the left of this page for documentation and guides on
-writing tests for Terraform Plugins.