RetroMC Staff Policy Manual
The RetroMC Staff Policy Manual (RSPM) is designed to outline the responsibilities and actions of staff members. The RSPM is intended to serve as the primary high-level reference document for all staff indicating the Operators' intent.
In instances where a staff member needs to deviate from this policy, they must seek approval from an Operator. If applicable, this situation should prompt a proposed amendment to the RSPM for future reference.
1. Ban Transfer Policy
A ban implemented on either the Discord platform or the RetroMC server does not automatically apply to the other. RetroMC staff have the authority to "transfer" a ban to the second platform, as determined by specific circumstances. Due to the manual nature of transferred bans, these transfers should only be carried out when the ban on the opposing platform is permanent.
2. Documentation of Ban Evidence
When issuing a ban, the staff member in question must provide evidence on the JBans platform.
If a player lodges an appeal against a ban and there is insufficient evidence to justify the ban, the ban is deemed invalid and the player is pardoned.
2.1 Handling of Sensitive Evidence
When potential evidence is deemed sensitive and cannot be presented publicly on JohnyBans, a staff-only ticket with the evidence is to be raised on Discord.
This evidence is then to be stored in the RetroMC archive managed by Johny, with an appropriate note added to the ban in question.
2.2. Handling Pre-2022 Bans
Bans issued prior to January 1, 2022, are not subject to Section 1 stipulations and do not require evidence. However, if a request concerning the ban is made by the banned player or any concerned party, staff members are expected to strive to locate any possible documented evidence and share it, unless it is deemed sensitive. If the reasoning or evidence behind the ban can no longer be justified, an Operator Pardon should be issued in accordance with section 3.2.3.
3. Ban Appeal Process
All players are afforded the right to appeal against a ban. Staff members are encouraged to grant an appeal if there is a "reasonable" likelihood that the player will not re-offend.
3.1. Decision Making
In deciding to accept a ban appeal, staff must weigh the efficiency of available tools such as LogBlock, JGriefAlert, JVillage. Often, predicting whether a player will re-offend is challenging; however, staff are encouraged to give players the "benefit of the doubt," considering prior offenses on the server, playtime history, and other factors.
- Note: A player with multiple offences over 10 hours should be assessed differently than a player with a thousand hours.
3.2. Pardon Types
Various methods exist for pardoning a player, including but not limited to:
3.2.1. General Pardon
A ban appeal may be accepted if a majority of staff members vote in favour of pardoning a user. Staff must allow a reasonable time for discussion among enough staff members.
3.2.2. Issuer Pardon
The staff member who initially issued a ban retains the right to invalidate it. Operators possess the authority to reverse this decision.
3.2.3. Operator Pardon
Operators may unilaterally choose to accept a ban appeal.
3.3. Reinstating Bans
Bans that have been successfully appealed can be reinstated at the discretion of staff, particularly if they deem the player is acting in bad faith or in violation of community rules and expectations.
4. Transference of Ban from Other Servers
Players are not automatically banned from RetroMC if they are banned on another server. A player's ban may be "transferred" in accordance with 4.1. If the player is banned on another JBan server, a moderator or higher authority can initiate a ban transfer. If the player is not banned on another JBan server, an operator must approve the ban transfer.
- 4.1.1. There is a reasonable belief that the user on the original server and RetroMC is the same person. If the person on RetroMC is a cracked user, they should have their password reset instead.
- 4.1.2. They are assessed as being of poor character and are likely to break the rules on RetroMC. A primary factor for determining if this is true is the extent of damage they did to receive their original ban and how many times they have been banned previously across JBans servers. If it is a ban for minor griefing or something similar, that isn't sufficient enough reason in of itself.
5. Use of Beta Evolutions Mode (/authme betaevo)
This raid-response mode is reserved for temporarily mitigating high-risk situations by requiring players to auth via BetaEvolutions or similar (Though it negatively impacts player count).
Moderators and staff with higher authority can toggle this mode, and each toggle must be communicated via staff chat on the Discord guild.
This mode should be activated only for a few hours, but if the server is being raided and the staff members who are available at that point of time are about to become unavailable (bedtime, outdoor errands, other IRL stuff), then BetaEvo enforcement can be left enabled – the key part is letting other staff know that it's enabled.
6. Confidentiality and Need to Know
Staff should use common sense when discussing information from private forms regarding RetroMC, BetaLands and associated services. Closed source plugins, internal files, and documentation are not to be published unless authorized by an Operator. Documents such as ban appeals and staff applications should be considered to be personal information and, therefore, shouldn’t be distributed without the express permission of the originator.
7. Staff Conduct
Staff are expected to be familiar with the Staff Onboard Guide.
7.1. General Discipline
Staff are to remain in control of a situation at all times and should never stoop down to the level that the offending member is residing at.
Staff members must also not do the following:
- Editing the roles or ranks of a user on the Server or Discord, thereby granting access to restricted commands, channels, or voice communications.
- Engaging in power trips, arbitrary moderation, or similar actions.
- Making major, non-approved alterations to the server.
- Disclosing confidential staff operations outside of designated Staff chats.
- Publicly revealing information related to Staff applications.
- Providing regular members with methods to bypass automated moderation, security protocols, or other functions.
7.2 Actions in other communities
A staff member can be dismissed from RetroMC as a result of poor behaviour in other communities.
Example: A staff member raids/"attacks" another Legacy Minecraft Server.
8. Rule Implementation
Our staff are charged with the enforcement of rules concerning both the Minecraft and Discord server.
8.1 Definitive Source of Rules
The Server rules page serves as the official page documenting rules to be enforced.
9. Staff Recruitment Protocol
The continuous recruitment of staff members is required to retain an effective and active staff team within RetroMC.
9.1 Eligibility Criteria for Applicants
An individual seeking to apply for a staff position must fulfil the following prerequisites:
- 9.1.1 Be a minimum of 16 years of age. Exceptions to this rule may be made with the explicit approval of an operator.
- 9.1.2 Satisfy the activity requirements for the Citizen rank, notwithstanding the possession of a donator rank.
- 9.1.3 Demonstrate a history of active participation in the community for no less than one month prior to the submission of an application.
- 9.1.4 Possess a Discord account and be prepared to undertake additional responsibilities pertaining to Discord moderation.
- 9.1.5 Have no record of severe punishments within the preceding six-month period. An exception to this requirement is given if the user is asked to apply by an existing staff member.
- 9.1.6 Members seeking a developer role may be exempt from certain requirements and are advised to initiate a Discord ticket instead.
9.2 Procedure for Staff Promotion
The elevation of an individual to a staff position may occur if the submitted application receives support from over 75% of the existing staff team.
- 9.2.1 In evaluating a staff application, consideration should be given to factors including but not limited to activity, skills, maturity, and offence history.
- 9.2.2 An operator retains the unilateral authority to accept or reject a staff application if deemed to be in the server's best interest.
- 9.2.3 Final approval for a staff promotion must be given by an Operator, or an Admin who has been delegated the responsibility.
9.3 Reapplication by Former Staff Member
- 9.3.1 Former staff members desiring to rejoin the staff team must undergo the standard application process.
- 9.3.2 Subject to an assessment by an operator, a rank higher than trial helper may be given.
10. Staff Activity Requirements
RetroMC staff are requested to adhere to specified activity levels. Those who fail to maintain this level of activity will have their permissions revoked, aligning with the principles of least privilege.
- 10.1 Administrative staff, with the exception of developers and operators, must engage in an average of ten hours of play per month to retain their standing as effective staff members. Failure to meet this requirement will result in demotion.
- 10.2 Staff members unable to fulfil these requirements are requested to notify fellow staff of the expected duration of their absence to prevent an inactivity-related demotion.
- 10.3 In cases where a staff member anticipates an extended absence (two months or more), they should be demoted and subsequently repromoted upon resuming active participation in the community.
11. Staff Hierarchy
Information about each rank's privileges may be seen in Ranks#Staff_ranks.
The hierarchy of RetroMC staff is outlined as follows:
11.1. Trial Helper
- Observe other Staff and learn from how they handle situations.
- Monitor channels and chat for rule violations.
- Participate in moderation when confident in the commands.
11.2. Helper
- Address rule-breaking issues within the server chats and voice.
- Ensure that issues are resolved without creating public drama.
11.3. Moderator
- Thorough understanding of the rules and server functions.
- Maintain a high level of activity within the Staff team.
11.4. Administrator
- Entrusted with managing the Community and Moderators at large.
- Report directly to the Operators, providing essential information.
11.5. Server Operator
- Possess an in-depth understanding of the server and its functions.
- Handle server functions, payments, and other high-tier issues.
11.6. Developer
- Develop different applications and/or plugins for RetroMC, depending on their skill set.
- Are issued the same powers as a Helper.
11.7. Infrastructure
- Have access to the server itself for troubleshooting and maintenance.
- Work alongside the server operators and developers to ensure the functioning of the server remains smooth.
12. Utilization of WorldEdit
WorldEdit is a powerful tool that allows for efficient modification of large areas within the Minecraft world.
Its use by staff members is regulated to ensure that it is employed only in scenarios that benefit the server environment and its community.
Staff members are permitted to use WorldEdit under the following conditions:
12.1 Acceptable uses
- 12.1.1 When a player is removed from a village: If a player's house is located within a village from which they are removed and they are unable to modify it, their house can be moved using WorldEdit.
- 12.1.2 Resolution of player drama: In cases where drama occurs between players, and the most straightforward solution involves relocating one's build, WorldEdit may be employed.
- 12.1.3 To repair griefing: WorldEdit can be utilized to repair griefing incidents when other tools, such as LogBlock, prove unsuitable for the task.
- 12.1.4 Improvement of protected server areas: Staff members may use WorldEdit to improve or modify protected server areas, such as the spawn area, mob areas, parkour courses, and minigames.
- 12.1.5 For event preparation and management: WorldEdit may be utilized for the preparation, creation, or management of server events, such as Spleef games, where the use does not confer any competitive or material advantage to players or staff. This includes setting up event arenas, resetting event spaces to their original state post-event, and any modifications required to facilitate the smooth running of server-sponsored events. The intent is to enhance the community experience through engaging and fair events, ensuring that WorldEdit is used in a way that maintains the integrity and enjoyment of the game for all participants.
- 12.1.6 Other instances: WorldEdit may also be used in other instances, provided there is explicit written permission from an Operator within a support ticket.
12.1 Unacceptable uses
- 12.2.1 Personal Projects Without Approval: Using WorldEdit for personal projects or builds without explicit approval from an Operator. This includes altering or creating new structures for personal use or benefit on the server.
- 12.2.2 Interfering with Player Builds: Modifying, relocating, or deleting player-owned builds without the owner's consent or without a valid, server-approved reason. This does not include:
- Inactive Builds in Spawn Town: Inactive builds located within Spawn Town can be moved at the discretion of staff or upon the request of the Spawn Town Mayor, pending staff approval. This exception is made to maintain the aesthetics and functionality of Spawn Town, ensuring it remains an inviting and well-organized space for all players. Staff are expected to exercise judicious consideration in these cases, balancing the need for community development with respect for player creations.
- 12.2.3 Creating Lag or Server Stress: Employing WorldEdit in a manner that creates unnecessary lag or stress on the server's hardware, such as generating large structures or performing massive terrain alterations without proper justification and planning.
- 12.2.4 Bypassing Gameplay Mechanics: Using WorldEdit to bypass normal gameplay mechanics, for example, to instantly generate resources or items that would otherwise require significant player effort to acquire.
- 12.2.5 Affecting Server Economy: Utilizing WorldEdit in ways that could unfairly influence or disrupt the server's economy, such as creating shops, farms, or other structures that give certain players an unfair advantage.
- 12.2.6 Without Proper Documentation: Using WorldEdit without proper documentation if required or without following the server's procedures leading to a lack of transparency and potential abuse of power.
These guidelines are established to ensure that WorldEdit is used responsibly and in ways that align with the overall objectives of the RetroMC community.
Any use outside these conditions requires explicit operator approval to maintain the integrity and fairness of the server's environment.
13. Adherence to sub-policies
Punishment Manual
All staff members are required to adhere to the guidelines and procedures outlined in the RetroMC Punishment Manual (RPM).
The RPM serves as a comprehensive guide for handling offences and issuing punishments within the RetroMC community, ensuring that disciplinary actions are fair, consistent, and transparent.
Staff must familiarize themselves with the contents of the RPM and apply its principles in their moderation activities. Failure to comply with the RPM not only undermines the integrity of the server's disciplinary process but also compromises the community's trust in the fairness and effectiveness of the staff team.
It is the responsibility of each staff member to ensure their actions align with the RPM, and any deviations or uncertainties regarding its application should be discussed with a Server Operator for clarification or potential amendment to the RPM for future guidance.
Change Management Policy
The RetroMC Change Management Policy (RCMP) outlines policies set for implementation of various backend changes, such as plugin implementation on the MC server, implementing a new bot feature on the Discord guild, making changes to the wiki's backend, etc.
All developers and infrastructure team members have to abide by this.
14. Wiki-Related Responsibilities
Staff members who are involved in managing the wiki should audit Special:RecentChanges periodically just to check if any potentially malicious action was taken (Blanking pages, renaming pages to not-so-nice names, etc.).
They may block an account that either broke the rules, or got compromised or both, via Special:Block.
Such blocks must be reported to other staff.
Staff members who have access to the wiki backend have to follow certain procedures:
- Any extension/skin addition, and/or other major addition must be approved by server operators.
- Updating extensions can be undertaken without approval, unless said extension is critical, then in which case, approval should be taken.
- Edits to configuration files must be documented.
- Maintenance scripts are incredibly powerful and, these words must be heeded when using them:
"Caution. MUST. Be. Taken."
In other words, if these scripts are improperly used, it could lead to data loss. And while backups of the virtual machine are available (as mistakes can happen), caution must always be taken. This also applies to any infrastructure-related role in other fields.
15. Communication of Major Changes
Due to the nature of voice communications and the fact that various members of the staff team live in different timezones, not all of them can be in VC at once.
As such, changes related to staff, infrastructure, etc., that are announced in VC must also be announced in staff chats or the staff announcements channel.
Change Management
Approvers and Their Responsibilities
- Change Approver
- Role: Operator.
- Responsibility: Approves significant content changes. Ensures changes align with the overarching goals and standards of the community.
- Details: All content alterations (excluding exceptions below) must be approved by the designated Change Approver if an individual. If a rank must be approved by that rank or higher.
- Minor Changes Approver
- Role: RetroMC Community Management Team.
- Responsibility: Handles minor edits such as grammar, spelling, and formatting.
- Details: Corrections related to grammar, spelling, and formatting can be approved by a wider group of editors to ensure swift corrections without compromising content quality.
Change Management
- Approval Process
- All rule changes require approval from an Operator.
- Before finalizing, gathering feedback from the broader staff team is encouraged to incorporate diverse perspectives and ensure comprehensive consideration of the impact on the community.
- Implementation Process
- Communicate significant changes through an official staff announcement on Discord.
Changelog
All changes to the RSPM are to be documented accordingly.
| Date DD/MM/YY | Change | Author |
|---|---|---|
| 26/06/23 | The initial version of the RSPM has been drafted. The intent of the document is to serve as the overarching staff policy document. This document is meant to outline the Operator's intent alongside providing authorizations on various actions. | |
| 27/06/23 | Removed header from the first line of the page, and thus, the table of contents now match up with the section numbers. Author names are now clickable & direct users to the respective author's user page. | |
| 04/07/23 | Added avatars of respective authors into the changelog. | |
| 11/07/23 | Added this page to Category:Server internals. | |
| 30/07/23 | Add section 8 regarding rule implementation, add section 3.3 regarding reinstating bans, add section 1.1 regarding handling of evidence for bans pre 2022. | |
| 07/08/23 | Add sections 9 and 10, 11, and 12, reformat section three, redo RSPM information. | |
| 08/08/23 | Added Ranks#Staff ranks to section 11. | |
| 09/08/23 | Added a missing point in section 7.1 from https://docs.retromc.org/en/latest/guide.html#code-of-conduct | |
| 18/09/23 | Added this page to Category:Guides. | |
| 10/02/24 | Added Developer rank to section 11. | |
| 17/02/24 | Add 12. WorldEdit use section and 13. RPM section. | |
| 17/02/24 | Formatting fixes. | |
| 17/02/24 | Implemented Template:User-bust. | |
| 17/02/24 | Added infrastructure rank. | |
| 09/03/24 | Remove section 12, and 13 from draft. | |
| 9/03/24 | Removed a clause from section 12. (regarding BetaLands build transfers, original clause can be viewed here) | |
| 14/03/24 | Updated terminology in section 2.1. | |
| 30/03/24 | Updated terminology in sections 11.6 and 11.7. | |
| 16/04/24 | Add change management section. | |
| 14/05/24 | Added section 14 to document staff responsibilities for the wiki. | |
| 15/07/24 | Added mention of the RCMP, and renamed section 13. (And updated Shark's username) | |
| 30/07/24 | Clarified and reworded § 5. | |
| 18/08/24 | Added a new section for changes announced in VC. | |
| 27/08/24 | Aforementioned section approved by Johny. |
