Non-Admin Staff Conduct

Note: This page is moderated and can be referenced in OOC issues, such as ban appeals, complaints, reports, etc. This may not apply to the pages this page links to.

This document is intended to set out a clear set of rules and guidelines for our mentors and other non-admin specific roles (TBA)

Universal Conduct

All types of non-admin staff must follow these guidelines. Admins who break these rules are liable for punishment as if they had broken admin conduct.

1: You are our most trusted players. Act like it:

You’ve been granted access to either sensitive policy or round info. As such, you are held to a higher standard than regular players. You should not accumulate large numbers of notes or bans as a mentor or maintainer. Some leeway is permitted, as nobody is perfect and we don’t expect you to be, but you should keep a generally clean record. The ballpark estimate for how many notes you can get away with is 0.033 per hour at the most, or one note per 30 hours of play. This does not apply retroactively, so do not panic if you have a pile of notes, so long as you improve and show a willingness to at least try to be a good player, you will not be removed from your position.

2: Do not be toxic to other players:

Likewise, you should act as an example to others during your interactions in OOC, the forums and discord. While you are not expected to coddle other players and never criticise anyone, you should not go out of your way to provoke fights or arguments for little to no reason. Do not harass other players, and do not constantly mock new players for being new. If someone is trying to provoke you and you end up in a massive fight with them, this is understandable, but try to avoid it regardless.

3: You are part of the staff team and as such represent us:

Do not raid or grief other servers. Do not advertise us on servers where this is not allowed. Use common sense and don’t do stuff that’d get other servers massively mad at us. Depending on the severity of your actions, you may be liable for offences within other server communities as if you had committed them within our community.

4: Follow forum/discord conduct:

Don’t peanut post in ban appeals. Do not spam threads with random images. Meming is allowed, but don’t do it in serious topics (Feedback threads, ban appeals, admin/player reports).

5: Follow the Legal and Operations Policy:

Follow and adhere to all of the policies and guidelines found on Legal and Operations Policy

Mentor-Specific Conduct

1: Mentorhelp conduct:

• Your job is to provide assistance for players with gameplay issues.
• Do not leak the contents of mentorhelps outside of mhelp, msay or #mentors.
• Do not mock or insult players for any reason in an mhelp, do not give meme answers unless the mhelp is an obvious meme mhelp (use common sense).
• Do not give false or misleading information to a player during an mhelp, and if you are not sure if the information you are providing is accurate, make this clear in the message.
• For rules/grief related mhelps, transfer them to adminhelp. Only admins are allowed to answer rules related questions.
• Do not act upon any information you receive in mhelps about the current round.

2: Msay/IC OOC conduct:

• By the nature of your position, you have access to means of private OOC communication. As you are supposed to be trustworthy, the IC OOC rules for these channels are somewhat loosened to allow you to function properly.
• You may freely discuss the contents of mhelps in both #mentors and msay.
• You may give IC information that is relevant to an mhelp freely in both channels.
• You may IC OOC in these channels for the purposes of expanding your collective knowledge of new features during a testmerge as well as to test for bugs.
• Do not act upon any information you receive from either channel about the current round.
• Do not release these private discussions outside of mhelp, msay and #mentors

3: Mentor Application conduct:

• When asking questions on mentor applications, you should not be asking more than 4 questions per person per mentor application.

Demotion Procedure

• A report may be opened against you on the forums, or you may be internally investigated by the admin team.
• The facts are verified and it is decided if you are guilty or not of a conduct breach.
• If you are found guilty, you will be either officially warned or immediately dementored.
• Breaking a part of the conduct that is underlined is grounds for immediate removal.
• The results of the investigation will be published in a public channel similar to #admin-strikes, with the reasoning being given.
• If you are inactive for a significant period of time you may be dementored due to your knowledge of the game being out of date. You may reapply when ready to regain your mentor status.

Maintainer-Specific Conduct

Maintainer Rules

• Do not disclose any information from the ops channels (#server-ops and #downstream-ops) without permission from the persons who posted it.
• Follow and enforce the code contribution guidelines.
• PRs may only be closed under the following conditions:
  • PRs may be given 'close keys' via the github label system. A PR may be closed once it has recieved 3 keys, including your own key. A reason must be included when applying a close key.
  • A PR that has had no other maintainer activity for 2 weeks may be closed 24h after pinging the maintainer role and requesting reviews for said PR, as long as the opinions from maintainers who have provided input is unanimous.
  • The head-developer may choose to close a PR for any reason, however this reason must be clearly stated in the PR.
• Acting maliciously will result in demotion.
  • Do not use any granted privileges for reasons other than what they are intended for.
• Feedback must be constructive and maintainers should not talk about other members of the development community in a way that they do not want to be talked about, this applies to developers involved with other SS13 projects. To report an issue, contact the head-developer or host via discord DMs.

PR Merging

Maintainer Conduct Key information

Pull-requests should not be merged within 24 hours of their opening, this it to give maintainers the opportunity to keep track of the codebase without requiring constant monitoring, unless they meet all of the following conditions: The pull-request has been approved by 2 or more maintainers (including the maintainer who presses the merge button), or the head-developer. The pull-request is simple, has a small number of changes that can be manually checked for logical validity, and does not violate any programming norms which make it confusing or hard to verify the correctness of. The pull-request is conclusive, and will not need further fixes or reversion. (Temporary fixes should be test-merged) The pull-request is not introducing any new features which were previously not present or accessible in the game. The pull-request is not a quality of life change. The pull-request is not a balance change, excluding simple changes to numbers which were clearly not intended and are having a significant, negative impact on gameplay. The pull-request is not a refactor, and does not significantly change the underlying logic in an unnecessary way. Test-merges may be applied within 24 hours of a PR being opened. Maintainers are permitted to test-merge their own PRs unless that PR interacts with the database or requires configuration changes (PRs which have optional configuration that is not required to be set may be test-merged by its author). All PRs should be considered as they are and will be treated as if they will have no more follow up PRs. If it does not provide a stable solution, it should not be merged. If a PR has been merged and doesn't function as expected, the author will be notified and it will be reverted if the issues cannot be fixed within a few days. Any other PRs that modify code added by a non-functioning PR should be frozen to allow for reversion. Do not merge any pull request with config or SQL changes. Review and approve it then request a review from Crossed. Do not merge any pull requests with the "Requires Approval" label. Review and approve it and then request a review from the Head Developer. Do not self-merge a pull request, even if it has been approved by another maintainer. If the merge queue fails for an unexpected reason unrelated to the PR, then you may re-queue it. Do not unilaterally merge pull-requests that you were heavily involved in the development of. Do not unilaterally merge balance changes or any changes which need a review of their design. Do not unilaterally merge PRs that have had a key placed on them. If a PR has a key on it, then there should be a discussion about the PR before merge. If an consensus is not reached then it is up to the head-developer to make the decision. Changes that affect balance or add features should be given time and discussed with other maintainers and contributors for opinions. If a significant amount of time passes (Minimum of 2-weeks) and there has been no discussion, ping maintainers for comment and indicate the action that you wish to perform (merge/close). If there are no responses within 24-hours, then you may perform that action unilaterally. All discussion points should be resolved first, do not merge the PR if the conversation does not reach a conclusion. If there are no strong opinions, then the PR can be put to vote (See below). Any PRs that make substantial player-facing changes to the game should be signed off by the head-developer first. Any PRs which make substantial changes to the codebase which will affect how code is being written (changing a pre-existing coding convention) should also be signed off on first. Maintainers specific to a single area of the code (Maptainer, Spritetainer) should only testmerge/merge PRs in their area.

Maintainer Recruiting

Maintainers have a lot of trust placed upon them, and as such it is difficult to appoint maintainers. New maintainers are selected by the current development team and there is no formal application process.

Below are some important qualities that we look out for when trying to abduct recruit new maintainers.

• At least a few large scale projects which implement a new, original and well-designed feature into the game.
• High standard of coding and enough contributions in order to prove this.
• Performed reviews on other contributor's code, highlighting potential issues with code and design.
• Good communication skills, feedback given is easy to understand.
• Some level of involvement in the community. The maintainer role is quite a highly trusted role and as such, some level of 'clout' is required.
• Being a nice person to work around and communicate with.

We understand that not everyone will be perfect in every regard and there are a lot of things that go into the discussions of recruiting new maintainers. We won't veto a maintainer simply because they haven't made any good balance PRs that align with the game, we value, and need, a wide range of skills across our maintainer team.

PR Vote Procedure

PR Vote Procedure

Player votes are indicative and do not imply that a PR will be merged. A majority vote does not imply that the vote has a positive outcome, and the maintainers have the sole discretion to judge whether or not it was a positive or negative result. Votes in the discord server should only be used when there are no opinions either way, the feature is not important, and the design-goals do not prefer a certain outcome. For gathering feedback about something in-game, prefer using in-game polls as the discord community is a disproportionate sample of our playerbase.

In-Game perms

PR Vote Procedure

In game perms are primarilly for debugging purposes and should not be used to influence the rounds outside of testmerges. Maintainers should be de-adminned while playing, unless there is a specific reason to be adminned. That being said, influencing the rounds is a good way to test different design elements. Performing this kind of in-round modifications requires permission from an administrator or from the head-developer. All round modifying actions should not affect the person performing them (You should be observing the round and not taking roles that you spawn). All round modifications performed by maintainers should have a purpose rather than being for fun. All round modifications should abide by the server rules, anything that appears in-character should only contain in-character information. If you are deemed to be abusing the in-game maintainer perms, they may be temporarilly removed. Maintainers should avoid interacting with players through the ticket system due to insufficient perms preventing them from being closed. Do not use Admin PM functionality. If you really, really need to talk to a player during a testmerge (due to a bug or other situation that needs explaining), use LOOC (Admins can talk in LOOC while ghosted) or ask another admin to help.

Head-developer

Head-Developer Key Points

The head-developer has the following goals: Ensure that the GitHub repository is running smoothly, identify and correct any issues with the GitHub repository. Ensure the quality of the player experience. Ensure an appropriate design direction for the server, and push the server along that direction. Manage the development section of the Beestation organization (maintainers and contributors). The head-developer has full discretionary authority over the code and design for the server. The head-developer is expected to always maintain their knowledge about the current state of the server, including any issues, the opinions of players, and the best direction to move forward. They should keep up to date with all pull-requests opened and merged, should use polls to gather the opinions of players, and should use data metrics to understand trends of the server. The head-developer is expected to review the design-documents and guide development of the server along that path. The head-developer is expected to appoint and manage the maintainer team. The head-developer is expected to collaborate with the other heads (server host and head administrators) to ensure that other aspects of server policy are in alignment with the game being presented to the players. If the head-developer is unable to perform their duties, an acting head-developer should be appointed. The acting head-developer may not make changes to the design direction of the server, but otherwise has the standard authority of the head-developer. The head-developer may grant or remove the contributor discord role to any server-member. The head-developer may, in correspondence with the host, demote maintainers. Head-developer is a high intensity role and comes with a significant burden and stress. The head-developer should seek ways to improve this through distributing work or introducing new development roles that may assist them with their goals.