Paradise/docs/CODE_OF_CONDUCT.md

# Contributor Code of Conduct

## Important

The Paradise GitHub is not exempt from [Paradise Station community and server rules][rules],
especially rules 0, 1, and 4. An inability to abide by the rules on the
GitHub will result in disciplinary action up to, or including, a repository ban.

[rules]: https://www.paradisestation.org/rules/

## General Expectations

### PR Discussion

Comments on Pull Requests should remain relevant to the PR in question and not
derail discussions.

Under no circumstances are users to be attacked for their ideas or
contributions. While constructive criticism is encouraged, toxicity or general
mean-spirited behaviour will not be tolerated. All participants on a given PR or
issue are expected to be civil. Failure to do so will result in disciplinary
action.

"Merge-nagging" or similar behaviour is not acceptable. Comments of this nature
will result in warnings or an outright ban from the repository depending on
general behaviour.

If you exhibit behaviour that's considered to be a net-negative to the community
(offensive commentary, repeat violations, constant nagging, personal attacks,
etc.), you may be banned from other Paradise services (Discord, forums, server,
wiki, etc.)

Headcoders reserve the right to permanently revoke access from the repository if
your behaviour is considered to be a net negative.

### PR Approval/Objection Info

Headcoders (who will take into account the votes from the relevant teams) have
the final say on Pull Requests. While thumbs-up/thumbs-down reaction ratios are
generally taken into account, they do not dictate whether or not a PR will be
merged.

After a twenty four hour minimum waiting period, Pull Requests can be merged
once they receive approval from the relevant team. An exception is made for
refactors and fixes, which may be merged by any maintainer with no waiting period.

While normally provided, voting team members are not obligated to publicly state
their objections to a Pull Request. Attacking or berating a voting team member
over an objection will not be tolerated. Additionally, whining over the closure
of a PR, the existence of an objection, or similar behaviour, will not be
tolerated.

Headcoders may close your PR at their discretion if your PR history has little
focus on improving repo maintainability (ie: making nothing but 20 balance or
feature PRs). Likewise, balance PRs may be closed if the PR author has
little-to-no time played on the server. This is to ensure balance changes are
made by people actually in-touch with the server atmosphere.

### PR Expectations

All Pull Requests are expected to be tested prior to submission. If a submitted
Pull Request fails to pass CI checks, the likelihood of it being merged will be
significantly lower. If you can't take the time to compile/test your Pull
Request, do not expect a warm reception.

Barring highly specific circumstances (such as single line changes, submissions
from advanced users, or changes to repo documentation), we will not accept Pull
Requests utilising the web editor.

Pull Requests regarding heavy-handed nerfs, particularly immediately after said
mechanic was used, will be tagged with `I ded pls nerf`. A bad experience with a
particular mechanic is not a justification for nerfing it.

Reactionary revert PRs are not tolerated under any circumstances. Posting a
revert immediately after a Pull Request is merged will result in a repo-ban.

It is expected that contributors discuss larger changes on the
[Paradise Station forums](https://www.paradisestation.org/forum/91-code-discussion/),
[GitHub discussions tab](https://github.com/ParadiseSS13/Paradise/discussions),
or the [Discord project-discussion forum](https://discord.com/channels/145533722026967040/1110966752898207824)
prior to starting work on a Pull Request. The amount of time spent on any given
Pull Request is not relevant. Repo staff are not responsible for contributors
wasting their time creating features nobody asked for. Be sure to inform the
corresponding teams about the forum post or discussion.

For changes to content listed below, contributors **must** obtain approval from
a headcoder or a member of either the balance, design, mapping, or sprite team
(depending on which teams are relevant to the changes) before opening their Pull
Request. This approval must be displayed in the Pull Request description body in
the form of a screenshot. The Headcoders may grant an exemption to this
requirement on a case-by-case basis, as the need arises.

### Generative AI

The use of generative AI tools is not permitted on the ParadiseSS13 repository. This includes pull request code, code review, and filing issues. If you proceed to post PRs, issues, or comments that are clearly AI generated, you will be warned against this and your content will be closed/deleted. Multiple infractions will result in an outright ban from the repository.

<!-- Add a fixed link so that changing the heading name doesn't break the link. -->

<a id="types-of-changes-that-need-approval"></a>

> [!IMPORTANT]
>
> <h3>Currently, changes to the following types of content requires pre-approval:</h3>
>
> - **Security content (excluding fixes, code improvement, refactors, sprites, and mapping changes)**
> - **Antagonist content (excluding fixes, code improvement, refactors, sprites, and mapping changes)**
> - **Species content (excluding fixes, code improvement, and refactors)**
> - **Large changes (for example PRs that touch multiple systems, many files, many lines of code)**
> - **Changes that might be controversial**
> - **Changes with wide-ranging balance or design implications**