View source for RetroMC Change Management Policy

[[Category:Server internals]]
[[Category:Guides]]
{{Notice|This policy is currently in draft form, and efforts should be made to adhere to its guidelines to the best extent possible.}}
As part of the [[RSPM]], this policy set outlines the procedures for managing changes, particularly regarding the implementation of plugins on the Minecraft server.
__NOTOC__
=== Types of Changes, Approving Authority, and Examples ===
{| class="wikitable"
|+
|-
! No. !! Type of Change !! Approving Authority !! Example
|-
| 1. || Major feature and/or new plugin || Operator || Implementing a new plugin that replaces the [[JVillage|current village system]].
|-
| 2. || Minor feature addition || 2 Admins or 1 Operator || Adding a feature such as <code>/hat</code>, <code>/mail</code> to Discord, or something relatively small.
|-
| 3. || Bug/Security Patching || Admin || Implementing a new version of Poseidon or Essentials to patch security vulnerabilities or fix bugs affecting gameplay.
|}
Changes should be tracked and authorised via [[Ticket system|a staff-only ticket]].

=== Plugin Implementation Guidelines ===
When implementing new plugins on the server, special precautions must be taken to ensure security and stability:

* Avoid using JAR files provided directly by developers to mitigate the risk of compromised code. Malicious actors may provide JARs that contain malicious code. Precedence does exist for this type of attack within the legacy Minecraft community, and other servers such as MinecraftOnline have faced sophisticated attacks by developers. 
** One such case study is the [https://blog.gradle.org/wrapper-attack-report 2023 Gradle Wrapper Attack] and was a novel type of attack hitherto unknown by the Gradle developers.
* Preferentially use JAR files compiled from trusted sources, such as GitHub actions. Before deployment, verify the commit history between the current production version and the new version to confirm the absence of malicious code.
* In cases where a developer-provided JAR is necessary or any public plugin is introduced, decompile the plugin when feasible to inspect for potentially malicious code.
* Staff members are encouraged to delay implementation if there is uncertainty about the integrity of a JAR file, pending further verification and review.
* The community management team can request the development team to verify the safety of plugins, ensuring there is no conflict of interest (e.g., ensuring developers are not closely affiliated).
* Documentation of all changes ([[Ticket system|preferably via ticket]]), including approvals and implementation details, should be maintained for transparency and accountability.

== Implementation and Review ==

This policy is effective immediately upon approval and applies to all changes made to the RetroMC Minecraft server environment; additionally this will be reviewed annually to incorporate any necessary updates based on changing security threats or operational needs.

== Changelog ==
All changes to this policy are to be documented accordingly.

{| class="wikitable" style="margin:auto"
|-
! Date (DD/MM/YY) !! Change !! Author
|-
| 29/06/24 || First draft of the RetroMC Change Management Policy || {{user-bust|JohnyMuffin}}
|-
| 15/07/24 || Made some formatting changes || {{user-bust|Noggisoggi}}
|}