Follow up comments on sig scalability charter

sig-scalability/block_merges.md

@@ -7,8 +7,11 @@ from merging into the relevant repos. This document describes the underlying
 ### Rules of engagement.
 The rules of engagement for blocking merges are as following:
 
-- Observe as scalability regression on one of release-blocking test suites.
-- Block merges of all PRs.
+- Observe as scalability regression on one of release-blocking test suites
+  (defined as green to red transition - if tests were already failing, we
+  don't have a right to declare a regression).
+- Block merges of all PRs to the relevant repos in the affected branch,
+  declaring which repos those are and why.
 - Identify the PR which caused the regression:
   - this can be done by reading code changes, bisecting, debugging based on
     metrics and/or logs, etc.
@@ -19,7 +22,7 @@ The rules of engagement for blocking merges are as following:
   - reverting the PR
   - switching a feature off (preferably by default, as last resort only in tests)
   - fixing the problem (if it's easy and quick to fix)
-- Unblock PR merged.
+- Unblock merges of all PRs to the relevant repos in the affected branch.
 
 The exact technical mechanisms for it are out of scope for this document.
 
@@ -34,7 +37,8 @@ if we want kubernetes to maintain scalability SLOs. The reasoning is:
   - once a regression is merged, and no other action is taken, it is only
     a matter of time until another regression is merged on top of it,
   - debugging the cause of two simultaneous (piled-up) regressions is 
-    exponentially harder, see issue 53255 which links to past experience
+    exponentially harder, see issue [53255](http://pr.k8s.io/53255) which
+    links to past experience
 - we need to keep flakiness of merge-blocking jobs very low:
 - regarding benchmarks, there were several scalability issues in the past
   caught by (costly) large-scale e2e tests, which could have been caught and