The Ronstation Wiki

This is RonStation’s wiki.

Important

Technical Issues ?
If you are having difficulties with logging into the game, please try the following resources:

• 🔊 Discord. This is the where the RonStation community is.

Caution

*Work in progress This documentation is still a work in progress. We are doing what we can to keep it up-to-date. When in doubt, please ask on the Discord.

This wiki is written in Markdown using mdbook.

Tip

Making contributions
If you would like to make contributions to this documentation site, it’s hosted fully open source on GitHub and you can make a webedit PR to any page using > the button in the top right.

What is this wiki for ?

This wiki will contain the current banning policy, the hierarchy of the server, mostly administrative content.

Community

RonStation Admin Policy

(heavily inspired from Wizden’s policies)

1. General Administration

General admin-guidelines. These apply to all ranks of admins.

1.1 Administrators will be held responsible for their actions.

Administrators are not unaccountable, and should be held to higher standards than the playerbase. If you have a problem with an admin’s behavior, discuss with the head admin. All administrators are expected to have a solid reason behind their actions.

1.2 Be professional, polite and welcoming.

Professionalism is important, and in general will help reduce the number of issues you run into as staff. We expect you to deescalate, rather than escalate situations. As staff, you’re often the first person that a player with an issue will talk to. No matter your opinion on the player, do your best to be respectful towards them.

1.3 Do not leak or share sensitive information without permission.

This does pertain to any information posted in the game admin Discord chats, forum categories, information discussed in admin chat in-game, as well as PII (IP, Hardware ID) accessible through the central ban DB. This does not pertain to basic ban info (time, reason, count), admin notes, or admin log information.

This policy also covers and prohibits internal leaks. An example of an internal leak would be an Admin A sharing information about Admin B’s application vote/discussion with Admin B, if Admin B doesn’t have direct access to all the information that was being shared by Admin A. Generally, “leak” means to share the information in whole or in part with someone who does not have direct access.

1.4 Ban Appeals

Ban appeals are covered by the Banning Policy.

1.5 Refer to the rules regularly

While the project management board will try to keep everyone updated, it might be easy to miss updates. Please keep your wiki knowledge up-to-date, or have it nearby when admining.

2. Game administration

Rules specific to adminning a round of SS14.

2.1 Do not ever process a case you are/were a part of.

Even if you’ve started adminning after dying, do not process a case you were involved in. Request help for your fellow admins in case you need to process a case.

2.2 Deadmin when you play the game.

Don’t misuse your game admin tools to metagame, this is pretty self-explanatory. Do not use your admin powers to message players whilst IC. If something happens that breaks the rules, you should engage with admins as a normal player via the regular ahelp command.

Exceptions to this are:

• You may start adminning a round after you have died and that you are considered round-removed. Do note that policy 2.1 still applies !
  • If no other admins are on, you may re-admin while part of a round. Policy 2.1 still applies in any case.
• You may use admintools when running adminevents if necessary, even if you are playing a character for it.

2.3 Admin events should be done in moderation without heavily altering the flow of the round.

An “event” here is generally meant to be any admin intervention in the round that affects more than a handful of people. For instance :

• Spawning a cookie for a prayer is not considered as an event.
• Spawning a sentient monkey that runs around and messes with people is considered as an event.

Heavily round-altering admin events (e.g. powerful wizard invasion, nations) should be voted for by the playerbase with customvote and only done on Extended (which means forcing the preset before the round starts !).

Events overall should not be something that occur multiple rounds in a row. Log what events you’ve done in Discord (when & what, and no need to log very minor stuff), and try not to overwhelm players. That said, a lot of lenience is given towards what kinds of events can be run.

When in doubt, you are free to ask on eventmin channels.

2.4 Do not interfere unless you are needed.

If it looks like the situation will be able to resolve itself, or escalated naturally; and nothing actually actionable has happened, then there is no reason to interfere.

2.5 Check with other admins before enacting bans outside of guidelines.

Bans and ban appeals are covered by the Banning Policy. Administrators who place bans outside of the guidelines are required to be able to justify the decision to the admin team at any point in time.

2.6 Use notes as consideration for punishment, and give notes frequently

If a player is AHelped for some behavior, but this behavior skirts the rules and is not explicitly bannable, you should always give them a note for it. When handling AHelps, you should always check their notes before interrogation or applying punishment. If a user is noted to have been skirting the rules multiple times previously in their notes, you may apply a ban for this behavior.

3. Head Admin Policy

3.1 Hold vote / discussion threads for all major decisions made

In discord, just make a new private thread and ping game admins. If it’s related to junior admin promotion/accepting, remove all current junior admins from the thread. Not all of them need to be votes, and votes can often hamper actual discussion, but they should always be done. Some discretion is given on what counts as a ‘major’ enough decision to warrant a thread.

3.2 Junior Admin discussions should be held at least every two weeks.

Can happen more frequently. These don’t necessarily need to be votes, but just a check-up on how all of the current trials are doing, what we can nudge them on, whether anyone is already promotable, etc.

This rule is suspended until the server gets enough traction.

3.3 Vote threads relating to admins in Discord should always be archived/locked after the fact

Any information that needs to be long-term from these should be outside of the thread.

3.4 Attempts should be made to further discussion on ban appeals older than one week

Don’t have to forcibly come to agreement on them, but its the headmin’s job to ensure that some discussion gets started on these. The actual discussion and specific decision making can be delegated to others obviously but the headmin is working in a managerial position here.

4. Server Admin Policy

4.1 Guide the junior admins to the best of your capacity

Junior admins are supposed to learn just like a security cadet should. Show responsibility and answer their questions to the best of your capacity. When in doubt, you may ask your fellow admins or head admins for advice.

You are also requested to report any incident that might have happened with a junior admin to head admins.

5. Junior Admin Policy

5.1 Listen to instructions

Until your get to server admin, listen to instructions from head admins and station admins.

RonStation Discord Policy

1. Discord Administration Policy

1.1 Check tickets regularly

The playerbase will often use tickets, as well as ahelps, to ask questions, services and such. Make sure to check the Tickets section of the discord regularly.

The main loop for processing tickets is :

1. Verify you are eligible to take the ticket

   • Are you a part of the ticket ? If so, avoid it. Refer to policy 2.1.
   • Are you authorized to answer in the ticket ? Some tickets will escalated to Head Admins. If the ticket has already been escalated, please refrain from interacting with it.

2. Claim the ticket by using the “Claim” button.

3. Answer the ticket to the best of your abilities.

4. Refer to colleagues (Head Admins, maintainers, host and so on) if you need help.

5. Once the ticket has been solved, close the ticket.

1.2 Do not ever ban someone that you banned in-game

The Discord is also used to lodge complaints about staff, other players and so on. Banning someone from the Discord prevents them from doing so. Only ban people on Discord as a last resort.

There are no exceptions to this rule.

1.3 Check with others before sending information to the playerbase

Avoid unscheduled announcements. Some lenience is given for announcements for days, weeks or months with specific events, admin events, and so on. Use common sense before publishing something to the playerbase, whether it is in an announcement or in any other public-facing channel, such as #general, #shitposting, and #questions.

Caution

It’s generally a good idea to check what the others before you did.
When in doubt, ask around.

RonStation GitHub Policy

1. General rules

1.1 Any change should have its issue on GitHub.

When working on something, please make sure it has its related task, issue, suggestion, PR or whatever on GitHub. Exceptions to this are emergency patches.

Comments on a task isn’t enough to qualify to work on a task.

1.2 Do not ever work on secret features

Staff should be aware on what you’re working on.

1.3 No AI work

AI work, except tiny-considerations such as Rider’s comment completion, are forbidden.

1.4 Licensing

Maintainers are solely responsible to check that licenses from other codebases match our own.

1.5 Merging PRs

All PRs, regardless of their priority, are to be validated by someone else than the PR’s authors. In cases where this is not possible, the approver takes responsibility of the merge.

1.6 Quality standards

All PRs, regardless of their priority, should match certain quality standards. The Head Maintainer sets these standards. As of last discussion, those were :

• All PRs should be tested beforehand, and making sure no regressions, no crashes, and no odd behaviour appear.
• All warning, errors and such should be kept at a strict minimum.

RonStation Banning Policy

(heavily inspired from Wizden’s policies)

This is the ban policy for RonStation’s servers. The admin policy can be found at Admin Policy

Definitions

• Indefinite: Refers to a ban with no defined end time. This type of ban generally requires a successful appeal for it to be removed. Indefinite bans which have no extra requirements are sometimes called appeal bans.

• Voucher: Confirmation from the admin team of another well-known SS14 server that you have played on that server for a significant amount of time without any recent major issues. A voucher is required when appealing a voucher ban.

• Voucher ban: A ban which requires a voucher to appeal. These bans can also typically only be appealed after at least 6 months from the date of the ban. They are often used as an alternative to a permanent ban that allows players to return if they can demonstrate an ability to follow a server’s rules.

• Warning: A warning is a clear communication from an admin that some behavior is not acceptable. Warnings should always be paired with an account note making note of the warning and behavior.

• Permanent ban: A ban which cannot be appealed. These bans are sometimes called perma bans.

• Game ban: A ban from the servers. A player who is game banned cannot connect to the servers during the ban. These bans are sometimes called server bans.

• Role ban: A ban from a specific role or roles.

• Ban evasion: Attempting to circumvent an active ban.

Special Banning Requirements

Permanent Bans

Permanent bans should typically only be placed as the result of an unsuccessful appeal of an indefinite ban or a voucher ban. Except for cases of ban evasion after an accepted voucher ban, a vote by the admin team is required to place a permanent ban. Placing a permanent ban may be an option in a vote for the appeal. It is recommended that any indefinite ban after a prior voucher ban within 6 months of the date of the current ban be upgraded to a permanent ban.

Voucher Bans

Voucher bans should typically only be placed as the result of an unsuccessful appeal of an indefinite ban. Except for cases of ban evasion, a vote by the appeals team or the admin team as a whole is required to place a voucher ban. Placing a voucher ban may be an option in a vote for the appeal. Unless the prior indefinite bans were solely for contacting the player, it is recommended that any indefinite ban after a prior indefinite ban within 6 months of the date of the current ban be upgraded to a voucher ban.

Banning Guidelines

Note

Administrators are not required to follow the times suggested by the banning guidelines when placing a ban, but bans placed within the guidelines are presumed to be of an appropriate length.

Note

All instructions in the subsections of the Banning Guidelines section only refer to the guidelines, not policy. A statement saying “X is not permitted” means it is not permitted under the guidelines, not that it may never be done.

Warning

Administrators who place bans outside of the guidelines are required to be able to justify the decision to the admin team.

Note

Consulting the admin team via Discord, or consulting multiple (2 or more) other game admins in-game through admin chat or ahelp does not result in those bans being presumed to be of an appropriate length, but is sufficient justification for straying from the guidelines.

Note

Any total suggested time greater than, not equal to, 30 days can be substituted with an indefinite ban and still be considered within guidelines.

Evading AHelp

A player is considered to have evaded an ahelp if:

• They disconnect almost immediately after breaking a rule or after being arrested/killed for breaking a rule.

• They disconnect during an ahelp where they should have reasonably believed the administrator was investigating an issue that they contributed to or were suspected of contributing to.

• Without responding, they continue to play after receiving at least 2 reasonably spaced ahelp messages asking them a question since their last response.

• They do not respond at least 5 minutes after receiving at least 2 reasonably spaced ahelp messages asking them a question since their last response.

If a player evades an ahelp:

• Their ban should be extended by at least 7 days.

• Their ban may be extended up to indefinite.

• If their ban is extended, it must include an instruction to appeal to explain the situation or continue the ahelp.

Ban reasons

In most cases, ban reasons should clearly communicate the reason for the ban to the banned player whenever they are not evading a ban. Admins should be able to easily identify the reason for a ban through either the ban or account’s notes.

Alternate account bans should typically be in the form Alt of OriginalUsername or AltUsername alt of OriginalUsername.

Bans of additional non-username information should typically include the GUID of the targeted player as a ban detail and should have a reason with just the account username. The earliest placed ban’s reason will appear for the player when trying to connect.

Offense Table

Note

First, second, third, and fourth offense refers to the amount of offenses in the grouping category in the last 6 months. Suggestions for subsequent offenses are double the last defined suggestion.

Note

Bolded suggestions in ranges are recommended for most cases.

Note

Rule violations not in the offense table can still have bans applied, but have no guidelines. Administrators can look to guidelines of similar offenses to aid in determining a response.

Modifiers Tables

Note

Modifiers can be applied to each offense that meets their conditions. They are typically in the form of multipliers.

Important

Warnings cannot be multiplied. An offense which lists W as a suggestion cannot have that suggestion multiplied into a GB, but the guideline can still be strayed from with the same conditions as other parts of the guidelines can be strayed from.

Note

An offense which lists W - 12h GB as a suggestion that is affected by a 2x multiplier would become a W - 24h GB suggestion.

Mitigating: Required

Note

These mitigating modifiers must be applied if they are applicable.

Mitigating: Discretionary

Note

These mitigating modifiers are applied at the discretion of the admin and may be partially applied. Admins are highly encouraged to consider applying these when they are relevant as they can significantly help to avoid bans which will be accepted on appeal.

Aggravating

Note

Aggravating modifieres are applied at the discretion of the admin and may be partially applied.

Grouping and Stacking

• When separate offenses occur, the suggested time should be determined by summing the suggestions for each separate offense.
• Offenses across multiple rounds can always be treated as separate offenses, but are not required to be.
• Offenses within the same round are “grouped”, and not separate offenses if there is no relevant ahelp between them¹³ and if any of the following are true:
  • the offenses are non-grouping and one is necessary for the other to have occurred, or
  • the offenses are in the same grouping category.
• Grouped offenses should use the guideline for the most specific offense.

Role Ban Rounding

The total time of a role ban may be rounded to the nearest available autofill.

Examples

Important

These examples may be outdated due to a banning policy update. Please point out any issues if you notice them.

AME Sabotage

A technical assistant sets the AME to 50. Their offenses are:

• Self antag
• Station sabotage
• Unreasonable incompetence in role

Self antag and station sabotage are part of the same grouping category, so are treated as only station sabotage. Both remaining offenses can have the new player modifier applied if the player is new to the game, which would allow the offenses to result in only a warning and an instruction to read the rules. The station sabotage offense may optionally have the role specific modifier applied. Any of the following total suggestions are valid:

• With new player modifier

  • W - 3d GB + W - 7d RB

• With role specific modifier

  • W - 3d GB + W - 13d RB if the role ban is applied in addition to the game ban, or
  • W - 13d RB if the role ban is applied as an alternative

RDM + Lying

A player RDMs another. When asked why they killed the other player, they say they haven’t done anything all round other than walk around, despite having just beaten the victim to death with a bat. Their offenses are:

• 1x RDM

The lying in ahelp modifier applies. The resulting guideline is:

• 36hr - 4.5d GB

Over escalation with history of issues

A player over escalates in a way unlikely to result in the victim’s round removal. They have a prior offense of RDM, a prior offense of self-antagging, and a prior offense of griefing the arrivals terminal. They have no prior bans. The offenses in this case are:

• 1x over escalation

No modifiers apply. Only the prior RDM offense is relevant because it is the only one in the same grouping category. The prior RDM offense means that for the current over escalation incident, second offense guidelines are used.

Appeals

Appeals Team

The Appeals Team is the whole Admin Team, tasked with handling ban appeals. Any member of the Appeals Team is capable of handling any appeal on their own. Head game admins are always members of the Appeals Team.

Any member of Appeals Team must put an appeal to a vote within the Appeals Team.

Should the appeal be challenged or if the appeal vote did not reach a consensus (at least 75% of voters agree), then the vote is passed to the head admins.

The appeals process is monitored by the Project Management Board.

Appeals of Incorrect Bans

Unless the ban was an upgrade resulting from an unsucessful appeal, if an appeal disputes the events which were used to justify the ban, the first appeal of a voucher or permanent ban may only be declined after it has been verified that it was appropriately placed.

Appeal Hijacking

If an appeal is currently assigned to someone, it is generally best to let them finish processing it. Cases where it may be acceptable to “hijack” an appeal are:

• the processor has not responded to the appeal recently,
• the processor has somehow indicated that they are not going to process the appeal, or
• a head game admin has told you that you can process the appeal.

Appealling the same ban multiple times

After an appeal, a banned player with a correctly handled appeal is only entitled to appeal their ban again if the ban is an Indefinite Ban, or a Voucher Ban. Typically the wait period between attempts is 6 months.

A player with a temporary ban may be told when they can appeal again by the processing admin. This is at the processing admin’s discretion, but is typically 2 weeks or double the waiting period for the previous appeal.

A player may have their appeal reviewed again or be allowed to submit a new appeal regardless of any waiting period if their appeal was handled improperly(e.g. The Handling Appeals Team member relied on incorrect facts). This may only be authorized by a head game admin following a successful complaint.

If a ban appeal is handled by the banning admin and the ban is not fully removed then the banned player may appeal again immediately.

Appeal Procedure

1. Check for ban evasion. If found deny the appeal.

2. If the ban has expired you may, but are not required to, deny the appeal.

3. If you are not the banning admin and the appeal is extremely low effort, or a “troll appeal” deny the appeal. An appeal is considered to be low effort if it meets any of the following critera:

   • The appeal is clearly the output of an LLM such as ChatGPT.
   • The appellant is clearly not expecting their appeal to be accepted, and made it simply to troll.
   • The appeal is incomprehensible or written in a language other than English.
   • The appeal has such little effort put into it that no other outcome can be derived from it but to close it.
   • The appeal is unable to be accepted for reasons outside the administrative team’s control; for example, the appeal was clearly intended for a different fork or server host.

4. If you are not the banning admin, an Appeals Team Member or under the supervision of an Appeals Team member you may not process the appeal.

5. If you placed the ban, you are only allowed to process the appeal if you intend to remove or reduce the ban.

6. Collect information

   1. Check the player’s history of appeals.
   2. Make a reasonable attempt to verify any claims made in the appeal by the player, or accept them to be true.
   3. Check the player’s note and ban history.
   4. Read the ahelp that led to the ban if it exists.
   5. Attempt to contact the banning admin.
   6. Ask the player questions that are important for the processing of the appeal.
   7. Attempt to allow the player to respond to information which will be considered in the appeal that it would be unfair to not allow them the opportunity to address.

7. Run a vote

   • Votes must run at least 24 hours unless the net vote criteria is met.
   • Votes must not be closed if there is ongoing discussion unless the net vote criteria is met.
   • Votes must be made in one of the designated internal appeals discussion channels.
   • Votes should present as much relevant information as possible.
   • Votes should indicate if the ban is within guidelines, preferably by presenting the guideline range for the ban.

8. Check for ban evasion. If found deny the appeal.

9. Post a response on the appeal which must be a summary of the following:

   • The outcome of the appeal.
   • The facts relied on for the outcome.
   • An opinion detailing why you, the appeals team or the admin team as a whole have decided upon the outcome.
   • If applicable, when the player is able to reappeal.

10. Implement the outcome

Self Requested Bans

A player may request a ban for any reason, for any duration of time. Such bans are not considered a ban for further administrative actions. Self-requested bans may only be requested through AHelp or admin messages on the forum. Requests through other channels should be met with instructions to submit them through the proper channels. At the player’s request, the ban may be lifted before the requested time via a ban appeal. While admins are not required to honour ban requests, they should be honoured unless there are compelling reasons against placing a ban.

Self Requested Ban appeal procedure

Self-requested bans may only be prematurely removed through a successful appeal on the forums. Any other attempts (e.g., Discord) should be responded to by instructing the player to appeal on the forums.

1. Check for ban evasion. If found, deny the appeal.

2. If the ban has expired you may, but are not required to, deny the appeal.

3. If you are not an Appeals Team Member or under the supervision of an Appeals Team member you may only process the appeal if you intend to remove the ban, or reduce it in line with the appellants request.

4. If you placed the ban, you are only allowed to process the appeal if you intend to remove or reduce the ban.

5. If you do not intend to remove or reduce the ban in line with the appealants request, follow steps 5 & 6 of the appeals policy.

6. Post a response on the appeal which must be a summary of the following:

   • The outcome of the appeal. If the outcome is not a removal or specific reduction requested by the appellant, this must also include:
     • The facts relied on for the outcome.
     • An opinion detailing why you, the appeals team or the admin team as a whole have decided upon the outcome.
     • If applicable, when the player is able to reappeal.

7. Implement the outcome.

1. Includes IC racism/speciesism. ↩

2. To qualify as bad faith, there should be no reasonable way that something is being done with good intentions. It is not required for the person to actually be acting in bad faith, only that it is unreasonable for them to think that they are. ↩

3. Offenses where the admin does not believe a violation to have been intentional may be reduced to a warning and do not need to be considered a past offense when evaluating guidelines for future offenses. ↩

4. Use of admin discretion to not enact penalties is highly recommended in cases where the offending player is not negatively impacting players, and is attempting to ensure players have a positive experience. For example, using LOOC to get permission to perform an IC act which would be allowed even without that permission. ↩

5. Use of admin discretion to not enact penalties is highly recommended in cases where the offending player only commits an offense after attempting and failing to teach a new player appropriately. ↩

6. This includes any information that a character should have not known from the same “life”. Depending on server rules, this may include information like the information leading to your death. A “life” ends when a player takes a different role, like a ghost role. For the purposes of banning guidelines, a “life” does not end on cloning. ↩

7. Does not include escalation issues. ↩

8. Acts that result in station wide, or near station wide disruption. Spacing a hallway is not station sabotage, but cutting HV or destroying substations likely is. Arrivals or arrivals terminal sabotage is not sufficient to apply the station sabotage offense. ↩

9. Only applies to antagonists and free agents. ↩ ↩2 ↩3

10. Guideline is multiplied by the number of victims. ↩ ↩2

11. This should be used in cases where there are deaths that result from a station sabotage offense, like people being killed by an AME being overloaded or dying in a loosed singularity. ↩

12. This includes frequently disconnecting in an important role, disconnecting in an important role without notification when there is reason to believe that the disconnection was not urgent, and failing to attempt to perform the duties of a role. ↩

13. This means that if two otherwise grouped offenses occur within the same round, but the player is ahelped between the two offenses occurring about the first offense, the second offense does not need to be grouped with the first. The second offense may also be considered as a prior offense for determining suggested ban times. ↩

Staff

RonStation’s Hierarchy

flowchart TD
    %% Mod Team
    subgraph ModTeam["Moderation Team"]
        Trialmin[Junior Admins]
        Admin[Server Admins]
        Oldmin[Senior Admins]
    end

    Trialmin --"Answer to"--> Admin
    Admin --"Answer to"--> Oldmin

    %% Dev team
    subgraph DevTeam["Development Team"]
        Contrib[Contributors] 
        Maint[Maintainer]
        LM[Lead Maintainer]
    end

    Contrib --"Answer to"--> Maint
    Maint --"Answer to"--> LM

    %% Project Management Board
    subgraph PMB["Project Management Board"]
        PMBM[Project Management Board Members]
    end
    ModTeam --"Answer to" --> PMB
    DevTeam --"Answer to" --> PMB

Project Management Board

TODO