Prolog-Cookbook: tidy up rule status descriptions

Change-Id: I3fef34f837381b046180c04b726add68c865569a

1 files changed, 8 insertions, 9 deletions

diff --git a/Documentation/prolog-cookbook.txt b/Documentation/prolog-cookbook.txt
index 5bff6bfe03..2fedb9ec87 100644
--- a/Documentation/prolog-cookbook.txt
+++ b/Documentation/prolog-cookbook.txt
@@ -139,15 +139,14 @@ be any other string (see examples below). The `status` is one of:
 
 * `ok(user(ID))` or just `ok(_)` if user info is not important. This status is
    used to tell that this label/category has been met.
-* `need(_)` is used to tell that this label/category is needed for change to
-   become submittable
-* `reject(user(ID))` or just `reject(_)`. This status is used to tell that label/category
-   is blocking change submission
-* `impossible(_)` is used when the logic knows that the change cannot be submitted as-is.
-   Administrative intervention is probably required. This is meant for cases
-   where the logic requires members of "FooEng" to score "Code-Review +2" on a
-   change, but nobody is in group "FooEng". It is to hint at permissions
-   misconfigurations.
+* `need(_)` is used to tell that this label/category is needed for the change to
+   become submittable.
+* `reject(user(ID))` or just `reject(_)`. This status is used to tell that this
+   label/category is blocking submission of the change.
+* `impossible(_)` is used when the logic knows that the change cannot be submitted
+   as-is. This is meant for cases where the logic requires members of a specific
+   group to apply a specific label on a change, but no users are in that group.
+   This is usually caused by misconfiguration of permissions.
 * `may(_)` allows expression of approval categories that are optional, i.e.
    could either be set or unset without ever influencing whether the change
    could be submitted.