content: Add newline between text and [links, code blocks]. Add trailing newlines. Remove unneeded newlines.

Author: timflannagan

README.md

@@ -91,5 +91,5 @@ Any changes will be included in real time.
 
 ## Useful resources
 
-* [Docsy user guide](wherever it goes): All about Docsy, including how it manages navigation, look and feel, and multi-language support.
-* [Hugo documentation](https://gohugo.io/documentation/): Comprehensive reference for Hugo.
+* [Docsy user guide](https://www.docsy.dev/docs/): All about Docsy, including how it manages navigation, look and feel, and multi-language support.
+* [Hugo documentation](https://gohugo.io/documentation/): Comprehensive reference for Hugo.

content/en/docs/Concepts/crds/_index.md

@@ -4,4 +4,3 @@ weight: 2
 description: > 
   A list of [CustomResourceDefinitions](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) defined by OLM. 
 ---
-

content/en/docs/Concepts/crds/clusterserviceversion.md

@@ -104,4 +104,3 @@ spec:
       version: v1alpha1
       kind: Other
 ```
-

content/en/docs/Concepts/crds/operatorgroup.md

@@ -15,6 +15,7 @@ An OperatorGroup is an OLM resource that provides rudimentary multitenant config
 ## Membership
 
 An operator defined by CSV `csv-a` is said to be a _member_ of `OperatorGroup` `op-a` in namespace `ns-a` if both of the following hold:
+
 * `op-a` is the only `OperatorGroup` in `ns-a`
 * `csv-a`'s `InstallMode`s support `op-a`'s target namespace set
 
@@ -25,6 +26,7 @@ If there exists more than one `OperatorGroup` in a single namespace, any CSV cre
 ### InstallModes and Supported OperatorGroups
 
 An `InstallMode` consists of an `InstallModeType` field and a boolean `Supported` field. A CSV's spec can contain a set of `InstallModes` of four distinct `InstallModeTypes`:
+
 * `OwnNamespace`: If supported, the operator can be a member of an `OperatorGroup` that selects its own namespace
 * `SingleNamespace`: If supported, the operator can be a member of an `OperatorGroup` that selects one namespace
 * `MultiNamespace`: If supported, the operator can be a member of an `OperatorGroup` that selects more than one namespace
@@ -85,6 +87,7 @@ The resolved set of selected namespaces is surfaced in an `OperatorGroup`'s `sta
 ## OperatorGroup CSV Annotations
 
 Member CSVs of an `OperatorGroup` get the following annotations:
+
 * `olm.operatorGroup=<group-name>`
   * Contains the name of the `OperatorGroup`
 * `olm.operatorGroupNamespace=<group-namespace>`
@@ -125,6 +128,7 @@ status:
 ## RBAC
 
 When an `OperatorGroup` is created, 3 ClusterRoles each containing a single AggregationRule are generated:
+
 * `<operatorgroup-name>-admin`
   * ClusterRoleSelector set to match the `olm.opgroup.permissions/aggregate-to-admin: <operatorgroup-name>` label
 
@@ -135,6 +139,7 @@ When an `OperatorGroup` is created, 3 ClusterRoles each containing a single Aggr
   * ClusterRoleSelector set to match the `olm.opgroup.permissions/aggregate-to-view: <operatorgroup-name>` label
 
 When a CSV becomes an active member of an `OperatorGroup` and is not in a failed state with reason InterOperatorGroupOwnerConflict, the following RBAC resources are generated:
+
 * For each provided API resource from a CRD:
   * A `<kind.group-version-admin>` ClusterRole is generated with the `*` verb on `<group>` `<kind>` with aggregation labels `rbac.authorization.k8s.io/aggregate-to-admin: true` and `olm.opgroup.permissions/aggregate-to-admin: <operatorgroup-name>`
   * A `<kind.group-version-edit>` ClusterRole is generated with the `create, update, patch, release` verbs on `<group>` `<kind>` with aggregation labels `rbac.authorization.k8s.io/aggregate-to-edit: true` and `olm.opgroup.permissions/aggregate-to-edit: <operatorgroup-name>`
@@ -190,6 +195,7 @@ spec:
 ### Rules for Intersection
 
 Each time an active member CSV syncs, OLM queries the cluster for the set of _intersecting provided APIs_ between the CSV's `OperatorGroup` and all others. OLM then checks if that set __is the empty set__:
+
 * If __true__ and the CSV's provided APIs __are a subset__ of the `OperatorGroup`'s:
   * Continue transitioning
 * If __true__ and the CSV's provided APIs __are not a subset__ of the `OperatorGroup`'s:
@@ -209,10 +215,10 @@ Each time an active member CSV syncs, OLM queries the cluster for the set of _in
     * Replace the `OperatorGroup`'s `olm.providedAPIs` annotation with the difference between itself and the CSV's provided APIs
 
 > Note: Failure states caused by `OperatorGroup`s are non-terminal.
-
 > Note: When checking intersection rules, an `OperatorGroup`'s namespace is always included as part of its selected target namespaces.
 
 Each time an `OperatorGroup` syncs:
+
 * The set of provided APIs from active member CSV's is calculated from the cluster (ignoring [copied CSVs](#copied-csvs))
 * The cluster set is compared to `olm.providedAPIs`:
   * If `olm.providedAPIs` contains any extraneous provided APIs:

content/en/docs/Concepts/olm-architecture/_index.md

@@ -14,7 +14,6 @@ Each of these Operators are responsible for managing the CRDs that are the basis
 
 **_Table 1. CRDs managed by OLM and Catalog Operators_**
 
-
 | Resource              | Short Name  | Owner   | Description                           |
 |-----------------------|-------------|---------|---------------------------------------|
 | ClusterServiceVersion | **csv**     | OLM     | Application metadata: name, version, icon, required resources, installation, etc.  |
@@ -72,9 +71,8 @@ Users can also create an InstallPlan resource directly, containing the names of
 * Watches for resolved InstallPlans and creates all of the discovered resources for it (if approved by a user or automatically).
 * Watches for CatalogSources and Subscriptions and creates InstallPlans based on them.
 
-
 ## Catalog Registry
 
 The Catalog Registry stores CSVs and CRDs for creation in a cluster and stores metadata about packages and channels.
 
-A _package manifest_ is an entry in the Catalog Registry that associates a package identity with sets of CSVs. Within a package, channels point to a particular CSV. Because CSVs explicitly reference the CSV that they replace, a package manifest provides the Catalog Operator all of the information that is required to update a CSV to the latest version in a channel, stepping through each intermediate version.
+A _package manifest_ is an entry in the Catalog Registry that associates a package identity with sets of CSVs. Within a package, channels point to a particular CSV. Because CSVs explicitly reference the CSV that they replace, a package manifest provides the Catalog Operator all of the information that is required to update a CSV to the latest version in a channel, stepping through each intermediate version.

content/en/docs/Concepts/olm-architecture/dependency-resolution/_index.md

@@ -15,15 +15,15 @@ graph TD;
     v(BarOperator) --> |Provides|vs(Kind: Bar<br/>apiVersion: bargroup.io/bar/v1alpha1);
     s(BazOperator) --> |Provides|ss(Kind: Baz<br />apiVersion: bazgroup.io/baz/v1alpha1)
     v--> |Requires|ec;
-    
+
     classDef foo fill:#8addf2,stroke:#333,stroke-width:4px;
     classDef bar fill:#ffcc26,stroke:#333,stroke-width:4px;
     classDef baz fill:#ff7452,stroke:#333,stroke-width:4px;
 
     class e,ec foo;
     class v,vs bar;
     class s,ss baz;
-    
+
     linkStyle default fill:none,stroke-width:2px;
 {{</mermaid>}}
 
@@ -104,26 +104,26 @@ spec:
   priority: 100
 ```
 
-`CatalogSource` has a `priority` field, which is used by the resolver to know how to prefer options for a dependency. 
+`CatalogSource` has a `priority` field, which is used by the resolver to know how to prefer options for a dependency.
 
 There are two rules that govern catalog preference:
 
- - Options in higher-priority catalogs are preferred to options in lower-priority catalogs
- - Options in the same catalog as the depender are preferred to any other catalogs.
+- Options in higher-priority catalogs are preferred to options in lower-priority catalogs
+- Options in the same catalog as the depender are preferred to any other catalogs.
 
 #### Example - Same catalog preferred to all others
 
 {{<mermaid>}}
 graph TD
     subgraph Catalog A - Priority 0
-    e(FooOperator<br /><br />Provides: Foo) 
+    e(FooOperator<br /><br />Provides: Foo)
     v(BarOperator<br /><br />Provides: Bar<br />Requires: Foo)
     end
-    
+
     subgraph Catalog B - Priority 50
-        e2(FooOperatorAlt<br /><br />Provides: Foo) 
+        e2(FooOperatorAlt<br /><br />Provides: Foo)
     end
-    
+
     classDef foo fill:#8addf2,stroke:#333,stroke-width:4px;
     classDef fooSelected fill:#8addf2,stroke:green,stroke-width:4px;
     classDef bar fill:#ffcc26,stroke:#333,stroke-width:4px;
@@ -132,7 +132,7 @@ graph TD
     class e fooSelected;
     class e2 foo;
     class v,vs bar;
-    
+
     linkStyle default fill:none,stroke-width:2px;
 {{</mermaid>}}
 
@@ -163,7 +163,7 @@ graph TD
     class e3 fooSelected;
     class e2 foo;
     class v,vs bar;
-    
+
     linkStyle default fill:none,stroke-width:2px;
 {{</mermaid>}}
 

content/en/docs/Concepts/olm-architecture/operator-registry/_index.md

@@ -1,11 +1,10 @@
-
 ---
 title: "Operator Registry"
 weight: 3
 ---
 
 ## What is Operator-Registry?
-  
+
 [Operator Registry](https://github.com/operator-framework/operator-registry) runs in a Kubernetes cluster to provide operator catalog data to [Operator Lifecycle Manager](https://github.com/operator-framework/operator-lifecycle-manager).
 
 <pre></pre>
@@ -26,7 +25,8 @@ And libraries:
  * `pkg/containertools` - providing an interface to interact with and shell out to common container tooling binaries (if installed on the environment)
 
 ## Why do I want Operator Registry?
-Operator registry allows you to package your operator in a defined format and make it available for OLM so that it can install your operator in a 
+
+Operator registry allows you to package your operator in a defined format and make it available for OLM so that it can install your operator in a
 kubernetes cluster.
 <pre></pre>   
 You can find all the releases of operator-registry in the [github release page](https://github.com/operator-framework/operator-registry/releases)

content/en/docs/Concepts/olm-architecture/operator-registry/building-a-catalog.md

@@ -78,9 +78,8 @@ opm index add --bundles quay.io/my-container-registry-namespace/my-manifest-bund
 <pre></pre>
 For more detail on using `opm` to generate index images, take a look at the [documentation](https://github.com/operator-framework/operator-registry/blob/master/docs/design/opm-tooling.md).
 <pre></pre>
+
 ## Where should I go next?
 
 * [Use the catalog of operators locally](/docs/concepts/olm-architecture/operator-registry/using-a-catalog-locally): Test your catalog locally 
 * [Using a Catalog with OLM](/docs/concepts/olm-architecture/operator-registry/using-catalog-with-olm): Make your operator available for OLM in a cluster
-
-

content/en/docs/Concepts/olm-architecture/operator-registry/using-a-catalog-locally.md

@@ -18,6 +18,7 @@ Once you have a database file, eg sqlite.db, you can serve the database locally
 ```bash
 ./bin/registry-server -d sqlite.db -p <port number to serve on (default "50051")> 
 ```
+
 [grpcurl](https://github.com/fullstorydev/grpcurl) is a useful tool for interacting with the example catalog server.
 
 ```sh
@@ -36,6 +37,7 @@ ListPackages
 ```sh
 grpcurl -plaintext  localhost:50051 api.Registry/ListPackages
 ```
+
 ```json
 {
   "name": "etcd"
@@ -48,6 +50,7 @@ grpcurl -plaintext  localhost:50051 api.Registry/ListPackages
 ```sh
 grpcurl -plaintext -d '{"name":"etcd"}' localhost:50051 api.Registry/GetPackage
 ```
+
 ```json
 {
   "name": "etcd",
@@ -65,6 +68,7 @@ grpcurl -plaintext -d '{"name":"etcd"}' localhost:50051 api.Registry/GetPackage
 $ grpcurl localhost:50051 describe api.Registry.GetBundleForChannel
 api.Registry.GetBundleForChannel is a method:
 ```
+
 ```json
 {
   "name": "GetBundleForChannel",
@@ -79,6 +83,7 @@ api.Registry.GetBundleForChannel is a method:
 $ grpcurl localhost:50051 describe api.GetBundleInChannelRequest
 api.GetBundleInChannelRequest is a message:
 ```
+
 ```json
 {
   "name": "GetBundleInChannelRequest",
@@ -113,6 +118,7 @@ api.GetBundleInChannelRequest is a message:
 ```sh
 grpcurl -plaintext -d '{"pkgName":"etcd","channelName":"alpha"}' localhost:50051 api.Registry/GetBundleForChannel
 ```
+
 ```json
 {
   "csvName": "etcdoperator.v0.9.2",
@@ -124,4 +130,4 @@ grpcurl -plaintext -d '{"pkgName":"etcd","channelName":"alpha"}' localhost:50051
     "{\"apiVersion\":\"apiextensions.k8s.io/v1beta1\",\"kind\":\"CustomResourceDefinition\",\"metadata\":{\"name\":\"etcdrestores.etcd.database.coreos.com\"},\"spec\":{\"group\":\"etcd.database.coreos.com\",\"names\":{\"kind\":\"EtcdRestore\",\"listKind\":\"EtcdRestoreList\",\"plural\":\"etcdrestores\",\"singular\":\"etcdrestore\"},\"scope\":\"Namespaced\",\"version\":\"v1beta2\"}}"
   ]
 }
-```
+```

content/en/docs/Concepts/olm-architecture/operator-registry/using-catalog-with-olm.md

@@ -62,4 +62,4 @@ spec:
   name: etcd
   source: example-manifests
   sourceNamespace: default
-```
+```