made the contributing guide more clear

Author: Pesekjak

CONTRIBUTING.md

@@ -1,104 +1,84 @@
 # Machine Contribution Guide
-Greetings! It's great to see that you have chosen to access this document.
-I hope you find it helpful.
-
 To begin with, we want to express our gratitude for your willingness to
-contribute to Machine project. Your participation is highly valued and
+contribute to Machine project. Every contribution is highly valued and
 much appreciated!
 
 ### Requirements
-To begin with, we assume that you possess adequate knowledge in Java
-programming and have selected your preferred IDE.
-However, if you lack proficiency in Java programming, we recommend that
-you refer to the official [Java documentation](https://docs.oracle.com/en/java/).
-
-Before continuing, please ensure that you have **JDK 17 and
-Kotlin** installed on your system.
-
-Subsequently, to kickstart your contributions,
-you will require a few essential tools.
-While most of these tools come pre-installed with your IDE,
-some may require additional installation:
-- Gradle - *In case your IDE does not support Gradle,
-  fret not, you can use the Gradle wrapper (gradlew or gradlew.bat)
-  without the need for any installation or configuration.*
+- JDK 17
+- Gradle - *you can use the Gradle wrapper (gradlew or gradlew.bat)
+  without the need for any installation or configuration*
 - Git
 
-### Safety Rules
-- Contributions must not include any malicious code intended to cause harm to the user or their device.
-- Under no circumstances should contributions contain confidential tokens, passwords, personal API keys, GitHub tokens, or any similar sensitive information.
-- Contributions should avoid slowing or making the server unstable.
-
 ### General Information
-Adhere to the project's prescribed style guide,
-which is comprehensively detailed in the `STYLE_GUIDE.md` file.
-
-It is imperative to test your modifications rigorously.
-Go beyond testing just your alterations; test for any possible
-side effects that may have unintentionally resulted from your changes and
-avoid the frustration of breaking existing functionality.
-
-Finally, when you are ready to submit your pull request,
-kindly conform to the provided template.
+- Adhere to the project's style guide, which is comprehensively
+described in the `STYLE_GUIDE.md` file.
+- Test your modifications carefully, make sure they don't cause
+side effects that may cause unintentional behaviour.
+- Contributions must not include any malicious code intended to cause harm to
+  the end-user and contain confidential tokens, passwords, personal API keys,
+  or any similar information.
+- Finally, when you are ready to submit your pull request, make
+  sure to follow the provided template.
 
 #### Nullness
 All variables that are either not annotated or annotated with `@NotNull` are
-presumed to be non-null.
+expected to be non-null.
+Null value is allowed only for variables marked with `@Nullable`.
 
-#### Other
+#### Recommendations
 - Prevent Stream API if not dealing with large collections of data, use classic loop instead.
 
 ### Specific Information
 
 #### API
-The API is fashioned after its forerunners. It prioritizes brevity
-to ensure simplicity for novices, while still offering ample
-advanced features for more seasoned developers.
+The API is designed after its forerunners. It prioritizes simplicity to
+ensure ease for beginners, while offering enough advanced features for
+more experienced developers.
 
-We derive inspiration for designing new APIs mainly from Bukkit,
-Sponge, Minestom, and Krypton, credits where credits due.
+We draw inspiration for the design of new APIs primarily from Bukkit,
+Sponge, Minestom, and Krypton.
 
 The Machine API should be structured to evolve seamlessly
 with new Minecraft versions. You should always weigh the potential use cases
-against the prospective maintenance expenses. If the downsides outweigh the
-benefits, it is perhaps not worth pursuing. In addition, it is crucial to
-document your code thoroughly.
+against the maintenance expenses. If the downsides outweigh the
+benefits, it is most likely not worth implementing the idea.
+
+Make sure that 100% of your API code is documented with the correct use of code
+contract annotations.
 
-Plugin design should rely heavily on dependency injection,
-and avoid the use of static accessors wherever feasible.
-However, some exceptions may exist.
+Plugins should rely on dependency injection, and avoid the use of static
+accessors. Exceptions do exist, but make sure you discuss your idea of
+implementation with others first if you are not sure about the design choice.
 
 #### Server
-The server is a bit more intricate than the API and does not impose
-many of the same strict requirements, but there are still some guidelines
+The server is more complex than the API and does not follow many of the
+same strict requirements, but there are still some guidelines
 that you should attempt to follow.
 
-The server is not designed to maintain backward compatibility for its
-dependents as it would be prohibitively expensive to maintain and severely
-limit the ability to evolve across Minecraft versions.
+The server is not designed to maintain backwards compatibility as it would
+be expensive to maintain and severely limit the ability to evolve
+across Minecraft versions.
 
-Moreover, when designing implementations, it is imperative to ensure that you:
-- Follow the API specification thoroughly.
-- Conduct comprehensive testing to ensure that your code operates
-  precisely as intended.
+When designing implementations, ensure that you:
+- Follow the API specification.
+- Test it to make sure that your code operates as intended.
 - Avoid introducing any potentially problematic elements,
-   such as unexpected exceptions.
+  such as unexpected exceptions.
 
 ### Licensing
-In order to contribute code, it must be licensed under **GPLv3** by you.
-We assume that any code you contribute is either your own or that you
-have explicit permission to license it to us.
+In order to contribute code, it must be licensed under **GPLv3**;
+it is either your property, or you have express permission to provide
+and license it to us.
 
 Third-party code may be accepted in the following circumstances:
 - It is under a compatible license and part of a public, freely-available resource.
 - You have been granted permission to include it.
 
 ### Lombok
-Throughout the project, we utilize [Lombok](https://projectlombok.org/)
-to minimize boilerplate code and enhance the readability of certain areas.
-If you intend to use Lombok in your commitments, it is essential that you
-use only annotations that do not modify how the code works, rather
-adds functionality and reduce extra code.
+Throughout the project, we use [Lombok](https://projectlombok.org/)
+to minimize boilerplate code and improve its readability.
+If you intend to use Lombok in your commitments, use only annotations
+that do not modify how the code works, rather reduce boilerplate code.
 
 **Banned Lombok Features** *(Annotations can't be detected by checkstyle so make sure
 you don't use these in your code)*
@@ -114,7 +94,7 @@ you don't use these in your code)*
 | `@Helper`            | Makes the code readability worse, doesn't really help much.
 | `@StandardException` | Makes the code readability worse, doesn't really help much.
 
-Please be aware that we may choose to remove Lombok from the project
+Please be aware that we may decide to remove Lombok from the project
 at some point in the future. Therefore, avoid overusing it when it is unnecessary.
 
 ### Code Contract Annotations