mirror of
https://github.com/ParadiseSS13/Paradise.git
synced 2026-07-09 14:15:22 +01:00
Burzah
112 lines
5.4 KiB
Markdown
112 lines
5.4 KiB
Markdown
# 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
|
|
|
|
Contributors may only have a maximum of **2** feature or balance Pull Requests
|
|
open at any given time. Any additional Pull Requests beyond this limit will be
|
|
closed at the discretion of the Headcoders. The Headcoders may grant an
|
|
exemption to this limit on a case-by-case basis, as the need arises.
|
|
|
|
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.
|
|
|
|
<!-- 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**
|