docs: cleaning up CONTRIBUTING.md

Author: giulong

CONTRIBUTING.md

@@ -16,7 +16,7 @@ Found a bug? Take these steps:
 
 # Feature Request
 
-If you think there's something missing in Spectrum that is a good candidate to become a feature of the framework, please
+If you think there's something missing in Spectrum that is a good candidate to become a new feature, please
 [open a feature request](https://github.com/giulong/spectrum/issues/new?assignees=giulong&labels=&projects=&template=feature-request.md&title=%5BRFE%5D+%3CProvide+a+short+title%3E)
 by fulfilling the provided template.
 
@@ -25,25 +25,25 @@ by fulfilling the provided template.
 If you found something missing in the [docs](https://giulong.github.io/spectrum/#spectrum),
 or you want to contribute with real configuration examples of how you use Spectrum, feel free to open a Pull Request.
 
-> ⚠ Minor changes such as fixing typos or rewriting the current docs will not be accepted.
+> ⚠️ Minor changes such as fixing typos or rewriting the current docs will be rejected.
 
 # Discussions
 
-If you just want to ask something about Spectrum, either to maintainers or to other users, check the
+If you just want to ask something about Spectrum, either to maintainers or other users, check the
 [Discussions section](https://github.com/giulong/spectrum/discussions)
 to see if there's something on that topic already. If not, feel free to open a new one.
 
 # Submitting Changes
 
-> ⚠ Purely cosmetic changes, such as just fixing whitespaces or formatting code, will not be accepted.
+> ⚠️ Purely cosmetic changes, such as just fixing whitespaces or formatting code, will not be accepted.
 > Neither refactoring will.
 
 If you'd like to actively contribute to Spectrum, whether it's source code or documentation, take these steps:
 
 1. First of all, be sure to read the [DEV.md](DEV.md) to be able to build Spectrum and its docs locally
 2. [Fork the repository](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo)
 3. Checkout a `feature/*`, `bugfix/*`, or `docs/*` branch with a short and meaningful name
-4. Make your changes and be sure you have a successful local build (at least the framework-only build)
+4. Make your changes and be sure you have a successful local build (at least the _framework-only_ build)
 5. Be sure your code complies to the [Coding Conventions](#coding-conventions)
 6. Submit a Pull Request towards `develop`
 
@@ -62,9 +62,9 @@ Do's:
 
 * be [SOLID](https://en.wikipedia.org/wiki/SOLID)
 * Take a look around: your code should follow the conventions already in place
-* Write small classes and methods, with reusability and evolvability in mind
+* Write small classes and methods, with reusability and maintainability in mind
 * Leverage [convention over configuration](https://en.wikipedia.org/wiki/Convention_over_configuration), providing defaults to reduce the boilerplate code a user would need to explicitly write
-* Explicitly mark variables as final. Mutable variables are not accepted, with very few exceptions
+* Explicitly mark variables as `final`. Mutable variables are not accepted, with very few exceptions
 * Leverage Java 21 api
 * Lines up to 180 chars are ok, with a grain of salt: put methods-chained calls on a new line only if they're many
 * Write few meaningful logs at a proper level
@@ -85,33 +85,34 @@ Don'ts:
 Every line of code must be unit-tested. There's no reason not to do so.
 If you write conditional logic, be sure you test each branch.
 You can leverage the coverage report produced by the build at [docs/jacoco/index.html](docs/jacoco/index.html)
-to see what's missing. Keep in mind that coverage is an important way to check missing branches, not just as an empty number.
+to see what's missing. Keep in mind that coverage _per se_ is just an empty number, but it's an important way to check missing branches.
 
 Rules:
 
-* Each class must:
+* Each test class must:
   * be in the same package of its source counterpart
   * have a name that is made up of the **source** class' name + 'Test', such as `MySourceClass` → `MySourceClassTest`
-* Each method must:
-  * be `public void`
+* Each test method must:
+  * be package-private
   * have a short and clear `@DisplayName`
-  * not contain any conditional logic
-* Strict mocking is required, as per mockito's default
-* Use dummy values as arguments. Suggestion: if you have a method with an argument like `String fileName`, use a variable like `String fileName = "fileName";` in your test
+  * contain no conditional logic
+* Strict mocking is required, as per mockito's default, with few exceptions allowed
+* Use dummy values as arguments. Suggestion: if you have a method with an argument like `String fileName`, use a variable with name and value matching, 
+like `String fileName = "fileName";`
 * Avoid generic argument matchers such as `any()` when possible. Knowing what we're passing to methods calls matter, even if they're dummy values
 
 ### Integration Tests
 
-Integration tests are not always needed. They are, for example, when implementing a new feature that produce some kind of artifact, such as a report.
+Integration tests are not always needed. They are, for example, when implementing a new feature that produces some kind of artifact, such as a report.
 In that case, we need an integration test that checks that artifact, and provide a way to avoid regressions.
 
-Generally speaking, you can write integration tests if you think they're useful, but maybe it's **better asking** before wasting time.
+Generally speaking, you can write integration tests if you think they're useful, but maybe it's **better asking** before wasting your time.
 
 Rules:
 
-* Each class must:
+* Each test class must:
   * have a name that ends with 'IT', such as `ExtentReportVerifierIT`
-* Each method must:
-  * be `public void`
+* Each test method must:
+  * be package-private
   * have a short and clear `@DisplayName`
-  * not contain any conditional logic
+  * contain no conditional logic