Fix deprecated doc links (#2737)

Signed-off-by: Catherine Chan-Tse <[email protected]>

Author: oceanc80

CONTRIBUTING.md

@@ -31,8 +31,8 @@ This is a rough outline of what a contributor's workflow looks like:
 - Identify or create an issue.
 - Create a topic branch from where to base the contribution. This is usually the master branch.
 - Make commits of logical units.
-- Make sure commit messages are in the proper format (see below).
-- Ensure all relevant commit messages contain a valid sign-off message (see below).
+- Make sure commit messages are in the proper format ([see below][commit-messages]).
+- Ensure all relevant commit messages contain a valid sign-off message ([see below][commit-messages]).
 - Push changes in a topic branch to a personal fork of the repository.
 - Submit a pull request to the operator-framework/operator-lifecycle-manager repository.
 - Wait and respond to feedback from the maintainers listed in the OWNERS file.
@@ -47,7 +47,7 @@ It can be helpful after submitting a PR to self-review your changes. This allows
 
 When opening PRs that are in a rough draft or WIP state, prefix the PR description with `WIP: ...` or create a draft PR. This can help save reviewer's time by communicating the state of a PR ahead of time. Draft/WIP PRs can be a good way to get early feedback from reviewers on the implementation, focusing less on smaller details, and more on the general approach of changes.
 
-When contributing changes that require a new dependency, check whether it's feasable to directly vendor that code [without introducing a new dependency](https://go-proverbs.github.io/).
+When contributing changes that require a new dependency, check whether it's feasible to directly vendor that code [without introducing a new dependency](https://go-proverbs.github.io/).
 
 Each PR must be labeled with at least one "lgtm" label and at least one "approved" label before it can be merged. Maintainers that have approval permissions are listed in the "approvers" column in the root [OWNERS][owners] file.
 
@@ -62,19 +62,19 @@ In addition to the linked style documentation, OLM formats Golang packages using
 
 Please follow this style to make the OLM project easier to review, maintain and develop.
 
-### Sign-off ([DCO][DCO])
+### Commit Messages and Sign-off ([DCO][DCO])
 
 A [sign-off][sign-off] is a line towards the end of a commit message that certifies the commit author(s).
 
-For more information on the structuring of commit messages, read the information in the [DCO](https://github.com/apps/dco) application that the OLM projects uses.
+For more information on the structuring of commit messages, read the information in the [DCO][dco] application that the OLM projects uses.
 
 ## Documentation
 
 If the contribution changes the existing APIs or user interface it must include sufficient documentation to explain the use of the new or updated feature.
 
 The OLM documentation mainly lives in the [operator-framework/olm-docs][olm-docs] repository.
 
-[operator_framework]: https://groups.google.com/forum/#!forum/operator-framework
+[operator_framework]: <https://groups.google.com/forum/#!forum/operator-framework>
 [dco]: <https://developercertificate.org/>
 [owners]: <https://github.com/operator-framework/operator-lifecycle-manager/blob/master/OWNERS>
 [issues]: <https://github.com/operator-framework/operator-lifecycle-manager/issues>
@@ -84,3 +84,4 @@ The OLM documentation mainly lives in the [operator-framework/olm-docs][olm-docs
 [sign-off]: <https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---signoff>
 [goimports]: <https://pkg.go.dev/golang.org/x/tools/cmd/goimports>
 [gofmt]: <https://pkg.go.dev/cmd/gofmt>
+[commit-messages]: <https://github.com/operator-framework/operator-lifecycle-manager/blob/master/CONTRIBUTING.md#commit-messages-and-sign-off-dco>

README.md

@@ -10,9 +10,10 @@
 
 User documentation can be found on the [OLM website][olm-docs].
 
+
 ## Overview
 
-This project is a component of the [Operator Framework](https://github.com/operator-framework), an open source toolkit to manage Kubernetes native applications, called Operators, in an effective, automated, and scalable way. Read more in the [introduction blog post](https://operatorhub.io/what-is-an-operator) and learn about practical use cases at [OLM-Book](https://operator-framework.github.io/olm-book/).
+This project is a component of the [Operator Framework](https://github.com/operator-framework), an open source toolkit to manage Kubernetes native applications, called Operators, in an effective, automated, and scalable way. Read more in the [introduction blog post](https://operatorhub.io/what-is-an-operator) and learn about practical use cases at the [OLM website][olm-docs].
 
 OLM extends Kubernetes to provide a declarative way to install, manage, and upgrade Operators and their dependencies in a cluster. It provides the following features:
 
@@ -47,13 +48,13 @@ Operators can behave like managed service providers. Their user interface on the
 
 ## Getting Started
 
-Check the [Getting Started][olm-getting-started] section.
+Check out the [Getting Started][olm-getting-started] section in the docs.
 
 ### Installation
 
 Install OLM on a Kubernetes cluster by following the [installation guide][installation-guide].
 
-For a complete end-to-end example of how OLM fits into the Operator Framework, see the [Operator Framework Getting Started Guide](https://github.com/operator-framework/getting-started). Also, see [Getting Started on OperatorHub.io](https://operatorhub.io/getting-started).
+For a complete end-to-end example of how OLM fits into the Operator Framework, see the [Operator Framework website](https://operatorframework.io/about/) and the [Getting Started guide on OperatorHub.io](https://operatorhub.io/getting-started).
 
 ## User Interface (Running the console Locally)
 
@@ -96,13 +97,14 @@ Learn more about the components used by OLM by reading about the [architecture]
 
 OLM standardizes interactions with operators by requiring that the interface to an operator be via the Kubernetes API. Because we expect users to define the interfaces to their applications, OLM currently uses CRDs to define the Kubernetes API interactions.
 
-Examples: [EtcdCluster CRD](https://github.com/operator-framework/community-operators/blob/master/community-operators/etcd/0.9.4/etcdclusters.etcd.database.coreos.com.crd.yaml), [EtcdBackup CRD](https://github.com/operator-framework/community-operators/blob/master/community-operators/etcd/0.9.4/etcdbackups.etcd.database.coreos.com.crd.yaml)
+Examples: [EtcdCluster CRD](https://github.com/redhat-openshift-ecosystem/community-operators-prod/blob/main/operators/etcd/0.9.4/etcdclusters.etcd.database.coreos.com.crd.yaml), 
+[EtcdBackup CRD](https://github.com/redhat-openshift-ecosystem/community-operators-prod/blob/main/operators/etcd/0.9.4/etcdbackups.etcd.database.coreos.com.crd.yaml)
 
 ## Descriptors
 
 OLM introduces the notion of “descriptors” of both `spec` and `status` fields in kubernetes API responses. Descriptors are intended to indicate various properties of a field in order to make decisions about their content. For example, this can drive connecting two operators together (e.g. connecting the connection string from a mysql instance to a consuming application) and be used to drive rich interactions in a UI.
 
-[See an example of a ClusterServiceVersion with descriptors](https://github.com/operator-framework/community-operators/blob/master/community-operators/etcd/0.9.2/etcdoperator.v0.9.2.clusterserviceversion.yaml)
+[See an example of a ClusterServiceVersion with descriptors](https://github.com/redhat-openshift-ecosystem/community-operators-prod/blob/main/operators/etcd/0.9.2/etcdoperator.v0.9.2.clusterserviceversion.yaml)
 
 ## Dependency Resolution
 
@@ -129,7 +131,7 @@ OLM has the concept of catalogs, which are repositories of application definitio
 
 Catalogs contain a set of Packages, which map “channels” to a particular application definition. Channels allow package authors to write different upgrade paths for different users (e.g. alpha vs. stable).
 
-Example: [etcd package](https://github.com/operator-framework/community-operators/blob/master/community-operators/etcd/etcd.package.yaml)
+Example: [etcd package](https://github.com/redhat-openshift-ecosystem/community-operators-prod/blob/main/operators/etcd/etcd.package.yaml)
 
 Users can subscribe to channels and have their operators automatically updated when new versions are released.
 
@@ -154,7 +156,7 @@ Catalogs are served internally over a grpc interface to OLM from [operator-regis
 
 ## Samples
 
-To explore any operator samples using the OLM, see the [https://operatorhub.io/](https://operatorhub.io/) and its resources in [Community Operators](https://github.com/operator-framework/community-operators/tree/master/upstream-community-operators).
+To explore any operator samples using the OLM, see the [https://operatorhub.io/](https://operatorhub.io/) and its resources in [Community Operators](https://github.com/k8s-operatorhub/community-operators/tree/main/operators).
 
 ## Community and how to get involved
 
@@ -194,6 +196,6 @@ Operator Lifecycle Manager is under Apache 2.0 license. See the [LICENSE][licens
 [operator-framework-community]: https://github.com/operator-framework/community
 [operator-framework-communication]: https://github.com/operator-framework/community#get-involved
 [operator-framework-meetings]: https://github.com/operator-framework/community#meetings
-[contributor-documentation]: https://olm.operatorframework.io/docs/contribution-guidelines/
+[contributor-documentation]: ./CONTRIBUTING.md
 [olm-getting-started]: https://olm.operatorframework.io/docs/getting-started/
 [installation-guide]: doc/install/install.md

doc/dev/reporting_flakes.md

@@ -1,7 +1,7 @@
 # Reporting flakes
 
 If you are struggling to get your PR through because unrelated e2e or unit tests are randomly failing, it's likely
-you are being plagued by a flaky test 😱, a test that wasn't constructed as carefully as it should have been as is
+you are being plagued by a flaky test 😱, a test that wasn't constructed as carefully as it should have been and is
 failing even when it should be succeeding. When this happens, check our [issues](https://github.com/operator-framework/operator-lifecycle-manager/issues) 
 to see if it has been filed before. Search also in the `closed issues`. If you find one, re-open it if necessary. 
 Otherwise, [file](https://github.com/operator-framework/operator-lifecycle-manager/issues/new) a flaky test issue.