Improve Readme (#88)

README.md

@@ -95,16 +95,16 @@ once for each completed build.
                the next rule is applied to the same build, and goes to the next iteration of the "for each rule" loop.
             4. If `continueAfterMatch` is `false`,
                the plugin stops applying rules to this build, and goes to the next iteration of the "for each completed build" loop.
-        3. If one or more optional condition are not met,
-           go to the next completed build (next iteration of the "for each completed build" loop).
+        3. If one or more optional conditions are not met,
+           the build continues to the next rule (next iteration of the "for each rule" loop).
 
 __Notes__:
 
 1. If the `matchAtMost` value is set to zero, the rule is effectively disabled.
    This is useful if the user wants to disable a rule while keeping its other configuration values.
 2. Once the `matchAtMost` value is reached, the rule is effectively disabled and is no longer applied.
 3. It may not make sense to continue to apply rules after a build is deleted, but the plugin handles this case gracefully.
-4. Having no condition is a way to unconditionally apply actions to builds, for example to delete all the builds.
+4. Having no condition is a way to unconditionally apply actions to builds, for example to delete all the builds. Use it wisely.
 5. Having no action is a way to ignore builds and keep them in the build history.
 
 ## Use cases
@@ -113,7 +113,7 @@ By using conditions and actions, it becomes straightforward to achieve a number
   or [aborted](https://javadoc.jenkins.io/hudson/model/Result.html#ABORTED)
   builds from the build history if they do not provide any value.
 - Keep only the last builds depending on their [result](https://javadoc.jenkins.io/hudson/model/Result.html),
-  so the history contains the most recent builds with the specified result(s): aborted, unstable, failure, or success.
+  so the history contains the most recent builds with the specified result(s): aborted, unstable, not built, failure, or success.
 - Keep builds only from `master` branch if the project builds all branches including feature branches
 - Remove any builds with a [build number](https://javadoc.jenkins-ci.org/hudson/model/Run.html#getNumber--)
   lower than the specified value to easily discard all old builds at once.

src/main/resources/pl/damianszczepanik/jenkins/buildhistorymanager/model/Rule/help-continueAfterMatch.html

@@ -1,22 +1,20 @@
 <p><b>Description</b></p>
-<p>
-    By default, after the conditions of a rule are met and the action are apllied,
-    the plugin moves on to the next completed build in the build history and
-    starts to process all the rules again from the start of the list of rules.
-</p>
-<p>
-    When this flag is set to <code>false</code> (default) AND this rule's conditions are met,
-    this rule is the last rule applied to the build. The plugin moves on to the next completed build
-    and starts processing the rules from the start of the list of rules.
-</p>
-<p>
-    When this flag is set to <code>true</code> AND this rule's conditions are met,
-    the plugin moves on to the next rule with the same build. This way multiple consecutive rules
-    can be applied to the same build.
-</p>
+<ul>
+    <li>
+        When this flag is set to <code>false</code>,
+        AND the conditions of this rule are met,
+        this rule will be the final rule applied to the build,
+        the plugin stops applying rules to this build,
+        and goes to the next iteration of the "for each completed build" loop.</li>
+    <li>
+        When this flag is set to <code>true</code> (which is the default),
+        AND the conditions of this rule are met,
+        the next rule is applied to the same build,
+        and goes to the next iteration of the "for each rule" loop.
+    </li>
+</ul>
 
 <p><b>Use cases</b></p>
 <p>
-    This is the way to apply more than one rule to the same build, providing the conditions of all those rules are met.
-</p>
-
+    This feature allows for the application of multiple consecutive rules to the same build, as long as the conditions for each of those rules are met.
+</p>

src/main/resources/pl/damianszczepanik/jenkins/buildhistorymanager/model/Rule/help-matchAtMost.html

@@ -1,17 +1,13 @@
 <p><b>Description</b></p>
-<p>Number of matched builds after which the rule is not processed. Then this condition is met, only other rules are
-    processed.</p>
+<p>The rule will stop being processed after a certain number of matched builds.
+    Once this condition is met, only the other rules will continue to be processed.</p>
 
 <p><b>Use cases</b></p>
-<p>Gives possibility to limit number of changes performed by given rule
-    (what of course saves the time for long build history!).</p>
+<p>This feature provides the option to control the number of builds the rule can process. It may save a significant amount of time when the build history is long.</p>
 <ul>
-    <li><code>-1</code> There is no limitation, all builds will evaluated</li>
-    <li><code>0</code> Zero builds will be evaluated. This is helpful when it is easier to match builds that should not
-        be deleted and to skip them from evaluation.
-    </li>
-    <li><code>1..n</code> When conditions match <code>n</code> times, no more builds will be processed by this rule
-    </li>
+    <li>If the value is set to <code>-1</code>, there is no limitation, all builds will be evaluated.</li>
+    <li>If the value is set to <code>0</code>, no builds will be evaluated. This disables the rule as it will not apply to any build.</li>
+    <li>If the value is set to <code>1..n</code>, once the value is reached, the rule is effectively disabled and is no longer applied.</li>
 </ul>
 <p><b>Warning!</b></p>
-<p>Zero value can be used to temporary disable to rule without deleting whole job configuration.</p>
+<p>If the <code>matchAtMost</code> value is set to zero, the rule is effectively disabled. This is useful if the user wants to disable a rule while keeping its other configuration values.</p>