OTA-1179: README: Clarify managed-cluster risk scoping

README.md

@@ -142,11 +142,22 @@ The `[+].*` portion absorbs [the architecture-suffix](#release-names) from the r
 
 If site reliability engineers want to declare a risk for managed clusters updating into a release:
 
+1. For issues expected to be related to the core OpenShift payload, ensure there is [an OCPBUGS issue][OCPBUGS], opening a new issue if necessary.
+2. Add the `UpgradeBlocker` label to the bug to [initiate generic risk assessment][risk-assessment].
+
+If you want to let that process cook, you're done :).
+If you want to declare your own risk in the meantime (or instead, if generic risk assessment decides the risk is not worth declaring, or that the confusion generated by a declaration outweighs the increased visibilty a declaration would deliver):
+
 1. Pick an impacted target release for `to`, e.g. `4.13.4`.
 2. Build a regular expression for relevant source releases (which would pick up the risk by updating into `to`), e.g. `.*` for "all releases", for `from`.
 3. Find (or create) a URI documenting the risk, e.g. https://access.redhat.com/solutions/7024726 or similar KCS, for `url`.
+    The linked document should explain that the declaration is specific to managed clusters, so customer-managed cluster administrators who hear about the declaration can easily see that it is not aimed at them.
 4. Create a PascalCaseSlug for the risk, e.g. `MultiNetworkAttachmentsWhereaboutsVersion` for `name`.
+    See existing names for inspiration; you want something that is unique to the issue, and unlikely to overlap with future issues.
+    Again, avoid giving the impression that you are talking to customer-managed cluster administrators, e.g. `ARO...` instead of `Azure...` for a declaration aimed at the ARO fleet (one managed subset of the Azure fleet).
 5. Create a sentance or two summarizing the risk for `message`.
+    An English version of the PromQL filter is a good start, e.g. "All GCP OSD clusters...", and then finish with a quick summary of the impact.
+    Again, avoid giving the impression that you are talking to customer-managed cluster administrators.
 
 And then create a file `blocked-edges/${TO}-${NAME}.yaml`, e.g. `blocked-edges/4.13.4-MultiNetworkAttachmentsWhereaboutsVersion.yaml` with the following content:
 
@@ -161,14 +172,26 @@ matchingRules:
 - type: PromQL
   promql:
     promql:
-      group(sre:telemetry:managed_labels{sre="true"})
+      group(sre:telemetry:managed_labels{_id="",sre="true"})
       or
-      0 * group(cluster_version)
+      0 * group(cluster_version{_id=""})
 ```
 
 to declare that risk only for managed clusters.
 See [here](blocked-edges/4.13.4-MultiNetworkAttachmentsWhereaboutsVersion.yaml) for an example where the values are filled in, although that is using different PromQL, and not the managed-cluster selecting PromQL from the above template.
 
+`sre:telemetry:managed_labels` does not exist in ARO, and in that case use:
+
+```yaml
+matchingRules:
+- type: PromQL
+  promql:
+    promql:
+      group(cluster_operator_conditions{_id="",name="aro"})
+      or
+      0 * group(cluster_operator_conditions{_id=""})
+```
+
 If the risk applies to multiple target releases, create multiple files with different `to`.
 
 ### Signatures
@@ -190,6 +213,8 @@ For example, the [`amd64` 4.12.0 is `sha256:4c5a7e26d707780be6466ddc9591865beb2e
 [json-array]: https://datatracker.ietf.org/doc/html/rfc8259#section-5
 [json-object]: https://datatracker.ietf.org/doc/html/rfc8259#section-4
 [json-string]: https://datatracker.ietf.org/doc/html/rfc8259#section-7
+[OCPBUGS]: https://issues.redhat.com/projects/OCPBUGS/issues
+[risk-assessment]: https://github.com/openshift/enhancements/blob/master/enhancements/update/update-blocker-lifecycle/README.md
 [rfc-3339-p13]: https://tools.ietf.org/html/rfc3339#page-13
 [semver]: https://semver.org/spec/v2.0.0.html
 [semver-build]: https://semver.org/spec/v2.0.0.html#spec-item-10