Edit docs for style, naming, and broken links (#458)

This PR fixes several issues:
 * Old naming / product identity
 * Adds missing GDI spec files
 * FIxes broken links
 * Style improvements

.github/CONTRIBUTING.md

@@ -1,3 +1,3 @@
-# Contributing to the SignalFx Terraform Provider
+# Contributing to the Splunk Observability Cloud Terraform Provider
 
 We're excited you'd like to contribute! We follow the [same guidelines used in the Terraform project](https://github.com/hashicorp/terraform/blob/master/.github/CONTRIBUTING.md#pull-requests).

CHANGELOG.md

@@ -1,4 +1,13 @@
-## Unreleased 
+## Unreleased
+
+## 9.0.1
+
+IMPROVEMENTS:
+* Updated documentation with correct names and terminology. [#458](https://github.com/splunk-terraform/terraform-provider-signalfx/pull/458)
+* Style and grammar improvements in the docs. [#458](https://github.com/splunk-terraform/terraform-provider-signalfx/pull/458)
+
+BUGFIXES:
+* Fixed broken links in the documentation. [#458](https://github.com/splunk-terraform/terraform-provider-signalfx/pull/458)
 
 ## 9.0.0
 BREAKING CHANGES:

CODE_OF_CONDUCT.md

@@ -0,0 +1,90 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+- Demonstrating empathy and kindness toward other people
+- Being respectful of differing opinions, viewpoints, and experiences
+- Giving and gracefully accepting constructive feedback
+- Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+- Focusing on what is best not just for us as individuals, but for the overall
+  community
+
+Examples of unacceptable behavior include:
+
+- The use of sexualized language or imagery, and sexual attention or advances
+  of any kind
+- Trolling, insulting or derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others’ private information, such as a physical or email address,
+  without their explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Project maintainers are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Project maintainers have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for
+moderation decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail
+address, posting via an official social media account, or acting as an
+appointed representative at an online or offline event. Representation of a
+project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at <splunk-oss-admin@splunk.com>. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.0, available at
+[https://www.contributor-covenant.org/version/2/0/code_of_conduct.html][v2.0].
+
+Community Impact Guidelines were inspired by
+[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
+
+For answers to common questions about this code of conduct, see the FAQ at
+[https://www.contributor-covenant.org/faq][FAQ]. Translations are available
+at [https://www.contributor-covenant.org/translations][translations].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.0]: https://www.contributor-covenant.org/version/2/0/code_of_conduct.html
+[Mozilla CoC]: https://github.com/mozilla/diversity
+[FAQ]: https://www.contributor-covenant.org/faq
+[translations]: https://www.contributor-covenant.org/translations

CONTRIBUTING.md

@@ -0,0 +1,91 @@
+# Contributing Guidelines
+
+Thank you for your interest in contributing to our repository! Whether it's a bug
+report, new feature, or question, we greatly value feedback and contributions from
+our community. Read through this document before submitting any issues or pull
+requests to ensure we have all the necessary information to effectively respond
+to your bug report or contribution.
+
+In addition to this document, review our [Code of Conduct](CODE_OF_CONDUCT.md).
+For any code of conduct questions or comments, send an email to <oss@splunk.com>.
+
+## Reporting Bugs/Feature Requests
+
+We welcome you to use the GitHub issue tracker to report bugs or suggest
+features. When filing an issue, check existing open, or recently closed,
+issues to make sure somebody else hasn't already reported the issue. Try
+to include as much information as you can. Details like these can be useful:
+
+- A reproducible test case or series of steps
+- The version of our code being used
+- Any modifications you've made relevant to the bug
+- Anything unusual about your environment or deployment
+- Any known workarounds
+
+When filing an issue, do *NOT* include:
+
+- Internal identifiers such as Jira tickets
+- Any sensitive information related to your environment, users, etc.
+
+## Reporting Security Issues
+
+See [SECURITY.md](SECURITY.md#reporting-security-issues) for instructions.
+
+## Documentation
+
+The Splunk Observability documentation is hosted on the [Splunk Observability
+Cloud docs site](https://docs.splunk.com/Observability), which contains all the
+prescriptive guidance for Splunk Observability products. Prescriptive guidance
+consists of step-by-step instructions, conceptual material, and decision support
+for customers. Reference documentation and development documentation is still
+hosted on this repository.
+
+To contribute documentation for this project, open a pull request in the
+[public-o11y-docs](https://github.com/splunk/public-o11y-docs) repository. See
+the [CONTRIBUTING.md](https://github.com/splunk/public-o11y-docs/blob/main/CONTRIBUTING.md)
+guide of the Splunk Observability Cloud documentation for more information.
+
+## Contributing via Pull Requests
+
+Contributions via Pull Requests (PRs) are much appreciated. Before sending us a
+pull request, make sure that:
+
+1. You are working against the latest source on the `main` branch.
+2. You check existing open, and recently merged, pull requests to make sure
+   someone else hasn't addressed the problem already.
+3. You open an issue to discuss any significant work - we would hate for your
+   time to be wasted.
+4. You submit PRs that are easy to review and ideally less 500 lines of code.
+   Multiple PRs can be submitted for larger contributions.
+
+To send us a pull request:
+
+1. Fork the repository.
+2. Modify the source; a single change per PR is recommended. If you also
+   reformat all the code, it will be hard for us to focus on your change.
+3. Ensure local tests pass and add new tests related to the contribution.
+4. Commit to your fork using clear commit messages.
+5. [Sign your commits](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits).
+6. Send us a pull request, answering any default questions in the pull request
+   interface.
+7. Pay attention to any automated CI failures reported in the pull request, and
+   stay involved in the conversation.
+
+GitHub provides additional documentation on [forking a
+repository](https://help.github.com/articles/fork-a-repo/) and [creating a pull
+request](https://help.github.com/articles/creating-a-pull-request/).
+
+Before your contribution can be accepted, you will be asked to sign our
+[Splunk Contributor License Agreement (CLA)](https://github.com/splunk/cla-agreement/blob/main/CLA.md).
+
+## Finding contributions to work on
+
+Looking at the existing issues is a great way to find something to contribute
+on. As our repositories, by default, use the default GitHub issue labels
+(enhancement/bug/duplicate/help wanted/invalid/question/wontfix), looking at
+any 'help wanted' issues is a great place to start.
+
+## Licensing
+
+See the [LICENSE](LICENSE) file for our repository's licensing. We will ask you to
+confirm the licensing of your contribution.

README.md

@@ -1,76 +1,86 @@
-Terraform `signalfx` Provider
-=========================
+# Splunk Observability Cloud Terraform Provider (`signalfx`)
 
+Splunk Observability Cloud is a Software as a Service (SaaS) solution for infrastructure monitoring (Splunk IM), application performance monitoring (Splunk APM), real user monitoring (Splunk RUM), and synthetic monitoring (Splunk Synthetic Monitoring). For more information, see [the official documentation](https://docs.splunk.com/observability/en/).
+
+Use this Terraform provider to automate the configuration of Splunk Observability Cloud.
+
+- Documentation: https://registry.terraform.io/providers/splunk-terraform/signalfx/latest/docs
 - Website: https://www.terraform.io
 - [![Gitter chat](https://badges.gitter.im/hashicorp-terraform/Lobby.png)](https://gitter.im/hashicorp-terraform/Lobby)
 - Mailing list: [Google Groups](http://groups.google.com/group/terraform-tool)
 
-Requirements
-------------
+## Requirements
 
--	[Terraform](https://www.terraform.io/downloads.html) 0.12.x+
--	[Go](https://golang.org/doc/install) 1.19+ (to build the provider plugin)
+-	[Terraform](https://www.terraform.io/downloads.html) 0.12.x or higher
+-	[Go](https://golang.org/doc/install) 1.19 or higher to build the provider plugin
 
-Building The Provider
----------------------
+## Build the provider
 
-Clone repository to: `$GOPATH/src/github.com/splunk-terraform/terraform-provider-signalfx`
+To build the provider, follow these steps:
 
-```sh
-$ git clone git@github.com:splunk-terraform/terraform-provider-signalfx.git $GOPATH/src/github.com/splunk-terraform/terraform-provider-signalfx
-```
+1. Clone the repository to: `$GOPATH/src/github.com/splunk-terraform/terraform-provider-signalfx`:
 
-Enter the provider directory and build the provider
+   ```sh
+   $ git clone git@github.com:splunk-terraform/terraform-provider-signalfx.git $GOPATH/src/github.com/splunk-terraform/terraform-provider-signalfx
+   ```
 
-```sh
-$ cd $GOPATH/src/github.com/splunk-terraform/terraform-provider-signalfx
-$ make build
-```
+1. Enter the provider directory and build the provider:
 
-Using the provider
-----------------------
-If you're building the provider, follow the instructions to [install it as a plugin.](https://www.terraform.io/docs/plugins/basics.html#installing-a-plugin) After placing it into your plugins directory,  run `terraform init` to initialize it.
+   ```sh
+   $ cd $GOPATH/src/github.com/splunk-terraform/terraform-provider-signalfx
+   $ make build
+   ```
 
-Further [usage documentation is available on the Terraform website](https://www.terraform.io/docs/providers/signalfx/index.html).
+## Use the provider
 
-Developing the Provider
----------------------------
+If you're building the provider, follow the instructions to [install it as a plugin.](https://www.terraform.io/docs/plugins/basics.html#installing-a-plugin). After placing it into your plugins directory,  run `terraform init` to initialize it.
 
-If you wish to work on the provider, you'll first need [Go](http://www.golang.org) installed on your machine (version 1.11+ is *required*). You'll also need to correctly setup a [GOPATH](http://golang.org/doc/code.html#GOPATH), as well as adding `$GOPATH/bin` to your `$PATH`.
+Further [usage documentation](https://www.terraform.io/docs/providers/signalfx/index.html) is available on the Terraform website.
 
-To compile the provider, run `make build`. This will build the provider and put the provider binary in the `$GOPATH/bin` directory.
+## Develop the provider
 
-```sh
-$ make bin
-...
-$ $GOPATH/bin/terraform-provider-signalfx
-...
-```
+If you wish to work on the provider, you need the following:
 
-In order to test the provider, you can simply run `make test`.
+- [Go](http://www.golang.org) version 1.11 or higher
+- Configured [GOPATH](http://golang.org/doc/code.html#GOPATH)
+- `$GOPATH/bin` added to your `$PATH`
 
-```sh
-$ make test
-```
+To compile the provider, run `make build`. This builds the provider and put its binary inside the `$GOPATH/bin` directory:
+
+   ```sh
+   $ make build
+   ...
+   $ $GOPATH/bin/terraform-provider-signalfx
+   ...
+   ```
+
+To test the provider, run the following command:
 
-In order to run the full suite of Acceptance tests, run `make testacc`.
+   ```sh
+   $ make test
+   ```
 
-*Note:* Acceptance tests create real resources, and often cost money to run.
+To run the full suite of acceptance tests, run `make testacc`.
 
 ```sh
 $ export SFX_API_URL=https://api.signalfx.com # or https://api.eu0.signalfx.com
 $ export SFX_AUTH_TOKEN=XXXXXX
 $ make testacc
 ```
 
-To also run the AWS integration tests for CloudWatch Metric Streams and AWS logs synchronization, you must create an actual AWS IAM user with an access key and secret that SignalFx can use to manage AWS resources, and define the `SFX_TEST_AWS_ACCESS_KEY_ID` and `SFX_TEST_AWS_SECRET_ACCESS_KEY` environment variables:
+> [!IMPORTANT]
+> Acceptance tests create real resources, and often cost money to run.
+
+### Run AWS integration tests
+
+To run the AWS integration tests for CloudWatch Metric Streams and AWS logs synchronization, create an AWS IAM user with an access key and secret that Splunk Observability Cloud can use to manage AWS resources, and define the `SFX_TEST_AWS_ACCESS_KEY_ID` and `SFX_TEST_AWS_SECRET_ACCESS_KEY` environment variables. For example:
 
 ```sh
 export SFX_TEST_AWS_ACCESS_KEY_ID=AKIAXXXXXX
 export SFX_TEST_AWS_SECRET_ACCESS_KEY=XXXXXX
 ```
 
-The following permissions must be granted. Additional permissions may be required to capture logs from specific AWS services.
+Grant the following permissions. Additional permissions may be required to capture logs from specific AWS services.
 
 ```
 "cloudwatch:DeleteMetricStream",
@@ -92,15 +102,19 @@ The following permissions must be granted. Additional permissions may be require
 
 See [Connect to AWS using the guided setup in Splunk Observability Cloud](https://docs.splunk.com/Observability/gdi/get-data-in/connect/aws/aws-wizardconfig.html) and [Enable CloudWatch Metric Streams](https://docs.splunk.com/Observability/gdi/get-data-in/connect/aws/aws-apiconfig.html#enable-cloudwatch-metric-streams) in Splunk documentation for more details about creating that IAM policy.
 
-Note that we use an IAM user instead of an IAM role as the latter requires an External ID that is only known at AWS integration creation time.
+> [!NOTE]
+> Use an IAM user instead of an IAM role, as the latter requires an External ID that is only known at AWS integration creation time.
+
+## Release the provider
+
+To release the provider, install https://goreleaser.com/install/ if you don't already have it, then follow these steps:
+
+1. Update the changelog and create a release in GH (vx.y.z format) in pre-release state
+
+1. `git pull` (Locally)
 
-Releasing the Provider
-----------------------
+1. `export GPG_TTY=$(tty)` (avoid gpg terminal issues if using iTerm2)
 
-Install https://goreleaser.com/install/ if you don't already have it.
+1. `GITHUB_TOKEN=xxx GPG_FINGERPRINT=xxx goreleaser --rm-dist` (github token must have `repo` scope)
 
- - Update changelog and create release in GH (vx.y.z format) in pre-release state
- - `git pull` (Locally)
- - `export GPG_TTY=$(tty)` (avoid gpg terminal issues if using iTerm2)
- - `GITHUB_TOKEN=xxx GPG_FINGERPRINT=xxx goreleaser --rm-dist` (github token must have `repo` scope)
- - Go back to release in github and mark as released/published
+1. Go back to release in github and mark as released/published