Rewording according to reviewer feedback

Author: matejak

_posts/2023-04-21-mrac.md

@@ -7,7 +7,7 @@ author_url: https://github.com/matejak
 ---
 
 Systems that our content aims to harden are very often large collections of separate components whose life cycle is independent from the life cycle of the product that ships them.
-For example, the Red Hat Enterprise Linux consists of more than six thousand of such distinct components, although only a fraction of them s.a. OpenSSH, Grub2 and so on is supported by the ComplianceAsCode project.
+For example, the Red Hat Enterprise Linux consists of more than six thousand of such distinct components, although only a fraction of them s.a. OpenSSH, Grub2 is supported by the ComplianceAsCode project.
 
 Our Red Hat group is contemplating the idea of making the content project better equipped to handle changes in component behavior better.
 As the project is open-source and has a community, we would like to get it involved from the very start.
@@ -53,7 +53,7 @@ Let's take a look how those ideas could align to the subject of component change
 
 ### Multiple rules to address one requirement
 
-In practice, we may not know at build-time what exact version of a component will be scanned, and we may address this uncertainty by having multiple rules prepared to handle this uncertainty.
+In practice, we may not know at build-time what exact version of a component will be scanned, and we may address this uncertainty by having multiple rules prepared to handle it.
 When it comes to the actual scanning, this collection of rules has to make sure that the evaluation will be carried out correctly, regardless of what component version is present on the system.
 
 This could be achieved by a set of rules with disjoint applicability, so at the end, at most one rule is active.
@@ -97,7 +97,7 @@ Designing such product properties in a way that is smart, doesn't get in the way
 Can you think of other ways of bringing declarative principles to the project?
 
 
-###  Be able to track component changes and our reactions to them.
+###  Ability to track component changes and our reactions to them.
 
 Imagine that a component changes behavior, and you dispatch pull requests that react to that change, and they get merged successfully.
 However, later you discover that something is still not right, and you need to check out the reaction to that change.
@@ -113,15 +113,15 @@ This can be very difficult to achieve exhaustively, but a partial and good enoug
 
 ###  Polymorphic rules
 
-Rules that try to do two things don't sound like a good idea, but if those two things are almost the same, then perhaps it could make sense.
-Although `CCE` identifiers restrict the scope of rule polymorphism significantly, change of component configuration preference could be handled without splitting a rule into two, polymorphically.
+Rules that try to do two things don't sound like a good idea, but what if those two things would heavily overlap?
+Great candidats for polymorphism are changes when component configuration doesn't change, as it is the way of how to achieve this configuration that does.
+In cases like this, a rule can get a polymorphic remediation and keep the `CCE` identifier if it has one, as `CCE`s don't change if the configuration stays the same.
 
-We have some polymorphic rules in our content, but they became polymorphic on their own, the project hasn't helped them with their polymorphism.
-For instance, the rule [no_empty_passwords](https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/system/accounts/accounts-restrictions/password_storage/no_empty_passwords) mentioned earlier has polymorphic Bash remediation and a rather simple OVAL check, while [enable_fips_mode](https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/system/software/integrity/fips/enable_fips_mode) has a simple Bash remediation, but a complex OVAL.
+For instance, the rule [no_empty_passwords](https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/system/accounts/accounts-restrictions/password_storage/no_empty_passwords) also mentioned earlier, has polymorphic Bash remediation and a rather simple OVAL check.
+Another example is different - [enable_fips_mode](https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/system/software/integrity/fips/enable_fips_mode) has a simple Bash remediation, but complex OVAL and this example nicely illustrates the richness of the rule-level polymorphism in the project.
 
-Provided examples nicely illustrate the richness of the rule-level polymorphism in the project.
-Rules don't advertise that they are polymorphic, and the project doesn't provide them with any specific help with their polymorphism.
-Project support for polymorphism of rules could reduce maintenance costs, as polymorphism would become more declarative.
+We have some more polymorphic rules in our content, but they became polymorphic "maually" - they don't declare their polymorphism, and there are no build system features that would guide a rule's transformation to a polymorphic rule.
+Project support for polymorphism of rules could reduce maintenance costs by making changes cheaper, and also by enabling maintainers overview of what rules are polymorphic and what aren't.
 
 
 ## What now