Staff Guidelines
Information Last Revised: November 9, 2024
Last updated
Was this helpful?
Information Last Revised: November 9, 2024
Last updated
Was this helpful?
Within the WoodCarver State Roleplay Staff team, we uphold Staff Policies and Guidelines. Policies serve as a formal means of distinguishing between accepted and unacceptable behavior within our staff team. Guidelines, on the other hand, demonstrate how something should be done or provide information on specific topics. It is mandatory to follow all policies and guidelines. The Staff Guidelines listed below will be numbered, and most of them are repeated within the respective sections of this Staff Handbook. However, the absence of a guideline in its respective section does not imply it is not enforced, and you will still be issued a staff infraction if in violation.
This section is for guidelines relating to server startups.
1.1 The server should only be started up around 11AM Eastern Time / 4PM British Summer Time on weekdays, and around 9AM Eastern Time / 2PM British Summer Time on the weekends.
1.2 You should not be posting any inappropriate messages within the server startup channel when you run the server startup command.
1.3 Only 1 staff member is required to start the server.
1.4 There should only be one after-message posted in the server startups channel once the server startup command has been run. This message can be something like 'Join up!' or similar.
This section is for guidelines relating to the server low command.
2.1 The low command should only be used if the player count drops to around 20 players. It shouldn't be used for a slight drop in the player count of the server.
2.2 The low command should only be used once every few hours. The minimum time between low commands, including from a server startup command, is 2 hours. It cannot be used before this.
2.3 The low command can be used if the server crashes and/or is restarted. Refer to the section below for the server restart procedure.
2.4 You should consider the use of the low command before you use it. If you feel like the server is going to be shutdown shortly then do not use the low command.
This section is for guidelines relating to server shutdowns.
3.1 The server can be shut down for the reason of 'low player count' if there are fewer than 10 players in-game consistently for an extended amount of time.
3.2 The server needs to be shut down if you are the only staff member online and need to head offline, and you have done a staff request but received no response.
3.3 The server can be shut down if you are given instructions from a management member and/or director to initiate a server shut down.
3.4 The server can be shut down if there is a major outage that makes it impossible to join the in-game server. This also applies to any major server lag occurring.
This section is for guidelines relating to priority duty shifts.
4.1 When the server is online, two staff members are required to be on priority duty, which means strictly moderating rather than roleplaying and moderating, at all times.
4.2 If the server has fewer than 15 players, then all staff members can roleplay and moderate rather than being on priority duty, as there shouldn't be too many moderation calls or situations.
4.3 If you join the server and there are already two staff members on priority duty, it is advised that you inquire about their availability and how long they plan to remain on priority duty. If they are going offline shortly, you should join priority duty.
4.4 If you are roleplaying and a staff member on priority duty needs to step away, and they ask you to take over, you must do so within a reasonable timeframe. You may continue roleplaying until the scene naturally ends, unless your scene is expected to last longer than 10 minutes.
This section is for guidelines relating to rule briefings.
5.1 A Rule Briefing should only be held when the server is experiencing large amounts of fail roleplay or other rule violations. It should not occur when the player count of the server is below 30, if there are a lot of ranked units online, or if there are more than 10 staff members online.
5.2 You do not require permission from the highest-ranking member online for a Rule briefing to occur. Instead, you need to speak to all staff members in-game, and you will come to an agreement as to whether a Rule Briefing is necessary or not.
5.3 At no point should you allow members to assist with the Rule briefing in any way. All members must stand on the yellow line at all times, even if they are AFK.
5.4 All staff members must come to an agreement on who will be reading the rules, as well as who will be responsible for other duties such as the avatar check and managing users not in the Voice Channel. The staff member designated to read the rules will be referred to as the Rule Briefing Host and is responsible for sending in-game messages relating to the Rule Briefing.
5.5 There should be one staff member in the civilian spawn teleporting anyone who joins late, one staff member assisting with getting people into the Rules Briefing Voice Channel, and one staff member checking the avatars of everyone while the rules are being read.
5.6 The Rules Briefing Area must be clearly marked. This should be done with two staff cars, one on each end of the Rules Briefing Area. The use of flares, cones, barriers, etc., is not allowed and should not be placed in the area.
5.7 All vehicles should be parked in a designated parking space at the civilian spawn. There should be no vehicles other than staff vehicles in the Rule Briefing Area.
5.8 The Rule Briefing needs to be logged using the Actions tab within Melonly. The Rule Briefing Host should be the one to log the Rule Briefing. More information on how to log a Rule Briefing using Actions can be found in Action Logging.
5.9 You are not required to log when you kick a user during a Rule Briefing, as these actions do not count towards their moderation record. However, you are required to log when you ban someone, as banning a user from our server must be logged.
This section is for guidelines relating to the priority system.
6.1 You are responsible for approving the following priority scenarios: Jewelry Store Robbery, Bank Robbery, Kidnapping Scenario, and Hostage Scenario. Please ensure you consider the timing of the last high-priority scenario, as there must be a 1h 30m interval between high-priority scenes.
6.2 You are prohibited from using custom priority and cooldown lengths.
6.3 The peacetimer should only be used after several priority scenes (such as Pursuits, Foot Pursuits, etc.) have occurred consecutively.
6.4 It is required that at least one staff member be present on the law enforcement radio frequency at all times.
6.5 You are required to use the :m and :h messages that are listed in the following sections and in the in-game messages channel for priorities, peacetimers, etc.
6.6 You are required to verify that a member does not have a priority cooldown from a previous scenario before granting approval for a high-priority scenario.
6.7 You are required to accurately log the occurrence of a high-priority scene using the Actions feature in the Panel Toolbox.
6.8 If two high-priority scenes are approved simultaneously, staff members have the discretion to determine which scene will continue and which will not.
6.9 You cannot approve a high priority scene within the first hour of a server startup.
This section is for guidelines relating to the punishment system.
7.1 When moderating a user, you must adhere to the punishment structure.
7.2 When logging a punishment, you must adhere to the punishment formats.
7.3 When logging a punishment, you must adhere to the punishment presets.
7.4 When moderating a user, you must ensure that you have sufficient evidence. This means either having video evidence or witnessing the user violating one of our in-game rules. It's important to note that a group of people saying someone did something isn't considered sufficient evidence.
7.5 If there are multiple instances of the same rule violations occurring, you can teleport these users into an area where you can address them collectively. This approach saves time in moderation as you won't have to handle each case individually.
7.6 You must not automatically kick someone for not being in the Discord and/or a Voice Channel. Instead, you must make an attempt to get them into the Discord and/or a Voice Channel before resorting to kicking them.
7.7 As a staff member, you have discretion when issuing a punishment to a user. This means that if you believe the user should not receive a punishment, you have the authority to withhold it. However, exercise this discretion only in minor cases.
7.8 If a member in-game has a username that contains the word “others,” “all,” etc., do not use commands like :kick others or :kick all. You must type out their full roblox username to avoid kicking the entire server.
This section is for guidelines relating to action logging.
8.1 Only one person needs to log the Rule Briefing. This person doesn't necessarily need to be the host, but it is advised that the host does log the Rule Briefing.
8.2 If you are logging multiple Team Removals, you will need to log them separately.
8.3 The Removal Reason must be valid. You cannot remove someone from a team for a minor violation of the in-game rules. Their actions must be causing significant disruption.
8.4 The maximum duration for which someone can be removed from a team is 1 hour. It is advised that this measure is only used in the most extreme of cases.
8.5 In situations where multiple people were in the same priority, you will still list all of the users involved, separated by a comma ,.
8.6 If you are logging a hostage or kidnapping scenario, you will indicate within the 'Roblox Username' section whether the individuals were a hostage taker or a hostage (the terms 'hostage taker' and 'hostage' apply for both the hostage and kidnapping scenarios). You will highlight this by placing the correct term within brackets () after their Roblox Username.
This section is for guidelines relating to in-game messages.
9.1 You are required to use the pre-provided messages whenever possible. You should not create your own messages unless it is absolutely necessary.
9.2 If you have to create your own messages, they should include the correct spelling, punctuation, and grammar, and maintain a professional manner.
This section is for guidelines relating to voice channels.
10.1 It is required that one member be situated within the law enforcement radio at all times. This ensures they can listen for when an Individual Priority scene is occurring.
10.2 You must use the Staff Frequency voice channel appropriately.
This section is for guidelines relating to ban bolos.
This section is for guidelines relating to voiding a punishment.
12.1 If more than one staff member was present during the moderation/punishment being given, both of them must submit a separate void request.
12.2 When submitting a moderation/punishment void, you must have a valid reason for it to be voided. The only accepted circumstances are that you submitted the moderation by mistake and/or you have received new evidence that proved that the user didn't do what they were infracted for.
12.3 When reviewing a moderation/punishment appeal, you need to ensure that it is for a valid reason such as the ones stated above this specific guideline. Depending on whether or not the request is valid or invalid, you will take the steps highlighted below.
This section is for guidelines relating to the virtual server management panel.
13.1 You must only use the Virtual Server Management panel for a good reason. You shouldn't use it to change any settings in-game without justification or because you want to.
13.2 Abusing the Virtual Server Management panel is strictly prohibited. Utilizing the panel incorrectly may result in termination from our staff team. All actions related to the use of the Virtual Server Management panel are logged and can be viewed by management.
This section is for guidelines relating to using in-game commands.
14.1 You are not to abuse in-game commands.
14.2 You must have a valid reason to use an in-game command. For example, you cannot change the time of day or weather simply because you or someone else wants you to.
This section is for guidelines relating to requesting staff in-game.
15.1 Before submitting a staff request, you must check for other staff members in-game who may be roleplaying. If there are staff members roleplaying, you will need to ask them to get on priority and moderate with you.
15.2 You must not converse within the staff request channel.
15.3 The staff request must also be deleted after 30 minutes of it being sent.
15.4 If the server has fewer than 15 players, only one staff member is required to be on moderation duty. This is due to the low number of expected moderation calls.
This section is for guidelines relating to the ticket system.
16.1 When a user opens a ticket, a staff member needs to claim the ticket before speaking within it. Once a ticket is claimed, it will lock for other support members unless unclaimed.
16.2 You must use spelling, punctuation and grammar when handling tickets.
16.3 You must act professionally within tickets and ensure you provide accurate information to users. If you are unsure about an answer to a question or query, seek assistance from another staff member in any of the staff chats or ask them to take over the ticket by unclaiming it.
16.4 When you close the ticket, either through the close button or the $close command, the ticket transcript will automatically be saved, and the ticket will be deleted in 15 seconds unless it is reopened.
This section is for guidelines relating to leave of absences.
17.1 Leave of Absences cannot exceed 3 months in duration. If an extension beyond this period is required, individuals may consider retirement from the staff team or a reduction in shifts, subject to approval by management. Further details can be found in the Activity Information section.
17.2 Leave of absences are not required for durations of less than 7 days.
17.3 Leave of Absences cannot be requested to fulfill staff duties within another server.
17.4 You reserve the right to refrain from providing detail in your Leave of Absence request. However, we advise that if possible, you provide additional information for the reviewal process.
17.5 You must provide an honest reason for your Leave of Absence. Submitting false information could result in a staff infraction and denial of your Leave of Absence request.
This section is for guidelines relating to shift reductions.
18.1 You must have a valid reason to request a Shift Reduction.
18.2 To request a Shift Reduction, you need to reach out to a management member.
18.3 If you are unable to meet the activity requirements at all, then you will need to submit a Leave of Absence. More information can be found in the Leave of Absence section.
18.4 Shift Reductions last for a duration of 2 months unless you state otherwise. Shift Reductions can be a minimum of 1 month and a maximum of 4 months.
18.5 Shift Reductions cannot be requested to fulfill staff duties within another server.
This section is for guidelines relating to reinstatement.
19.1 You have 3 months from the point of retirement to choose to reinstate. If you decide you want to reinstate after this 3-month period, then you will need to re-apply.
19.2 You cannot reinstate back onto the staff team if you have been terminated.
19.3 If you have retired and reinstated a few times, you may not be allowed to rejoin the staff team. This guideline is only considered as a reason to not let you rejoin the staff team if you have retired and reinstated more than 2 times.
19.4 If you choose to reinstate, you are not guaranteed to be given your old position back. It is quite common that you will be brought back at a rank lower than what you were previously at.
11.1 When issuing a ban bolo, you should only do so if a user has received the maximum number of punishments and needs to be banned in-game, if they LTAP (Leave to Avoid Punishment), which results in an instant ban from our in-game server, or if they violate our rules to such a degree that it necessitates a ban (e.g., Mass RDM, etc.).
11.2 When completing a ban bolo, it's essential to consider whether the ban bolo is valid. You can do this by referring to the guideline on issuing a ban bolo above. If the ban bolo submitted is invalid, you will delete it using the three dots and selecting 'Delete' and inform the staff member who submitted the ban bolo that it was deleted and the reason why.
11.3 When completing a ban bolo, you need to consider whether the ban bolo follows all moderation formats found in the section. If a ban bolo doesn't follow the formats, you should inform the person who issued the ban bolo about this and tell them to correct it before the ban bolo can be completed.