User:Nashoid/code

From WormRP
Jump to navigation Jump to search

Our Community Code covers all the edge cases and procedural issues not covered by our main Ground Rules. Most of the rules herein aren't something the average member will need to worry about or ever come across, but some (in particular the rules regarding character limits) come up pretty often.

As with the Ground Rules, if you would like to see a rule added, changed, or amended, talk to the staff, in particular your Community Rep.

Title 1. Community Conduct

Outside venues

Rule 14 states that behavior outside WormRP can result in bans from this community. Players are expected to avoid the following non-exhaustive list of actions:

  • Harassment
  • Doxxing
  • Espousement of hateful or bigoted beliefs
  • Ban evasion
  • Hacking

Title 2. Gameplay Conduct

Metagaming by omission

Users are responsible for ensuring their characters' public actions are disclosed via the proper out-of-character channels. This includes updating the proper sections of the Wiki, and using the proper discord channels to notify staff and the public of any relevant changes.

In addition, users are responsible for notifying the @PRT tag for any issues relevant to them.

(For example, if a Ward hasn't gone to school for a month, or a villain is robbing the PRT gift shop.)

Roleplaying Pregnant Characters

Unless otherwise approved by the staff, roleplaying any pregnant PCs is forbidden.

PRT, Wards, & Protectorate Policies

Roleplaying as the PRT

Only players with the @PRT tag can roleplay the PRT (Parahuman Response Team). Requests to be added to this group of authorized players can be made by contacting the Setting Team.

Patrols with Wards

Wards are required to patrol in pairs, either with each other or with an adult hero.[1]

Mentally Stable Law-Enforcement Only

Protectorate members (including Wards) must be able to pass PRT psychological evaluations.[2]

Team size limits

The Protectorate and Wards are limited to a combined total of twenty (20) members. Additional members may join (or return to active status from NPC) only upon an existing member leaving the roster.

Exceptions may be waivered with unanimous consent of the Lore team and the Protectorate Captain's player.

Title 3. Approvals

Character Limitations

Limits on number of characters

While there is no hard cap on the number of active characters a member may play, approvers can deny additional characters to those with an excessively large roster. Note, however, there are some caps on types of characters, as outlined below:

  1. Players may have a maximum of one active Tinker or pseudo-Tinker.
  2. Players may have a maximum of one active Trump.
  3. Players are allowed a total of two capes collectively from the following categories
    1. Multi-triggers/Cluster-triggers
    2. Meshed-triggers (Case-70s)
    3. Parallel-triggers (Ex:Menja/Fenja)
Exception Waivers

If a player wishes to play a character that would put them over the roster limits as listed above. they may petition the Approval Team for a waiver to allow said character to be played. Players should have the proposed character roughed out at least as this will be taken into consideration in granting the waiver.

If a waiver is requested, active Character Approvers will vote on whether to allow it. A majority is needed for the waiver to be granted. In addition, a similar vote can be made to revoke this waiver at any time, requiring the player to immediately bring their roster into compliance.

Breaker limitations

Breakers need to have consequences for long term usage.


Character/Equipment Approval Procedures

UPDATE THIS!!!!!! Character approval process

Characters and equipment are posted to the server with the appropriate flair tag, after which a Character Approver will look over the submission. They will typically ask some questions or clarifications as comments to the thread, answers should be given as a reply to these comments (members SHOULD NOT edit their actual submission until told to do so by their Approver).

Once edits have been made and the Approver has signed off, the member must submit the edited post to the Wiki.

Equipment is only usable in threads that are posted after that equipment is approved. If an event thread is GM-run, the GM may (at their discretion) waive this requirement for story-specific equipment.

Queue prioritization

New players are given priority in the approval queue.

Secret approvals

While normally not encouraged by staff, secret approvals (as in, a character or equipment that is not publicly viewable) can be made in certain situations. For example, a GM running an arc may wish to keep their NPCs secret, or a player may have a character whose power is especially vulnerable to unintentional metagaming.

In order to have a secret approval done, the author must petition the Administrators, who will go over the character with them in private. A secret approval cannot be made without the approval of both Administrators. In the event an Administrator wishes to do a secret approval, or another conflict of interest is present, the Community Rep will be asked to choose Approvers as replacements.

Updating after the Approval

Players wishing to change or update a character's power should submit an updated sheet, along with a comment detailing what changes have been made. This will then go through the standard approval process.

Sanity checks

Lore Approvers are authorized to run approval processes on the lore aspects (such as backstory) concurrently with the Character Approver's balancing process. In practice, however, this responsibility has been delegated to the Character Approvers.

If a reputable community member takes issue with a submission, they may petition to have a hold placed on the approval process so as to discuss specific grievances with the submission. Approvers will discuss the matter with the relevant parties in order to resolve the situation.

Character reworks

Sometimes maintaining a fun atmosphere on the server can require changes be made to a previously-approved character. In this case, if a majority of Character Approvers support a rework (with the Community Representative acting as a tiebreaker), a rework will be required if the character is to continue in the setting. A randomly selected member of the pro-rework approvers will spearhead the rework process.

Reworks can be expected to operate similarly to an approval process, with the Approver working with the author to resolve all outstanding issues.

Lore Limitations & Procedures

Lore approval process

Lore approvals occur in a similar fashion to Character approvals, however a 24-hour waiting period is in place for other staff to place a hold on the approval process to discuss issues with the submission. After this discussion a vote will take place with the majority answer determining the status of the lore post.

In practice, this period may be significantly less if all Lore Approvers are around to have a quick discussion.

Once edits have been made and the Approver has signed off, the member must submit the edited post to the Wiki if applicable.

Old Lore

All old lore from older versions of the setting (currently everything prior to September 2018) is to be considered non-canon unless the content is reapproved. In practice, many characters were grandfathered in from the previous iteration, and thus some portions of their backstory may be considered "soft canon".

Changes with respect to Ward

WormRP was established prior to Wildbow's release of Ward, and while we've always generally followed similar mechanisms to the Parahumans canon, some changes have come to light with the revelations in this new serial. In order to maintain consistency with our own "fork" of the canon, revelations from Ward will not be implemented automatically. Staff discussions will occur and implementations will be made via Staff motions.

Lore Retcons

Lore can be made non-canon by way of a majority vote of lore mods.


Title 4. Staff and Organization

Chapter 4.1. Motions

Section 4.1.1. Motion process

Motions may be brought forward by any member of staff, and upon making their motion will notify the rest of the Staff via a discord ping.[3] A motion will be approved only if a two-thirds quorum is present.[4] A waiting period of one business day will be put in place to allow offline Staff to voice their opinions and have a chance to vote.[4]

In the event of a tie, the Community Rep's vote will act as a tiebreaker.[5]

Chapter 4.2. Community Representative

Section 4.2.1. Community Rep election

The Community Representative is elected by all the members of the community, with a one-year term beginning on the 20th of September each year.

Elections will be conducted with a suitably secure system that will be chosen by the staff at the time. Nominations will be conducted for a period ending no less than two days from the announcement of elections. Members are free to nominate themselves or decline nominations from another member; a valid candidate must have accepted their nominations. Once the staff have compiled a list of valid candidates, voting will be open for no less than five days. Results will be posted and implemented no greater than two days after the end of elections.[6]

Chapter 4.3. Removal of a staff member

Section 4.3.1. Removal via public vote

The Community Representative may initiate a vote process to remove any staff member from office. At that time a community vote will take place with a public ballot, with a 50% majority determining if the member is removed.[7]

Chapter 4.4. Policies for all staff

Section 4.4.1 Inappropriate name changes

Staff cannot change users names without their permission, unless the name is inappropriate. Staff cannot change the room names for factions without the faction's permission, unless it is inappropriate.[8]

Chapter 4.5. Rule Enforcement and Sanctions

Section 4.5.1. Staff Jurisdiction and responsibilities

Lore Approvers are authorized to issue citations for issues with metagaming and lore misconduct (such as violations of section 2.2.1 of the CC).[9]

Character Approvers are authorized to issue similar citations for balance and power use misconduct (such as violations of Rule 2 or Rule 4).[9]

Administrators can issue citations for all other misconduct (such as violations of Rule 1).[9]

Infractions against staff members may be issued by any other member of staff.[10]

Section 4.5.2. Citation procedure

When a member is issued a citation by an appropriate authority (as listed in section 4.5.1), it will be recorded by staff for future reference. The citation will then be referred to the Administrative staff who will determine what action, if any, should be taken (unless the member in question is an Administrator, in which case the Community Rep will determine the punitive action required[10]). This range from a warning, up to and including a permanent ban for egregious violations.[9]

Section 4.5.3. Minimum punishments for repeat offenses

For the third citation issued to a member, some form of punitive action must be issued by the Administrators (unless the member in question is an Administrator, in which case the Community Rep will determine the punitive action required[10]), such as a 48-hour mute or other more severe punishments.[9] If the member in question reaches three more infractions, this "minimum sentence" will once again be required.

Section 4.5.4. Appeals

If a community member believes they have been falsely issued a citation, they may petition the Community Rep for an appeal. The Community Rep may, at their discretion, allow an appeal to be made. They will hear the arguments of the community member and the staff member who issued the citation, and determine whether or not to overturn the citation. This decision will be final.[11]

Chapter 4.6. Appointment of new staff members

New staff members other than the Community Rep are to be appointed via staff motion. A majority is required for appointment. However, the Community Representative may veto any appointment which will require two-thirds majority to overrule.[12]

In addition, Admins/Head Mods must be confirmed via a community vote using a suitably secure system. A 50% majority is required to confirm their position.[12]

  1. Cite error: Invalid <ref> tag; no text was provided for refs named 18-009
  2. Cite error: Invalid <ref> tag; no text was provided for refs named 19-013
  3. Cite error: Invalid <ref> tag; no text was provided for refs named 19-007
  4. 4.0 4.1 Cite error: Invalid <ref> tag; no text was provided for refs named 19-006
  5. Cite error: Invalid <ref> tag; no text was provided for refs named 18-012
  6. Cite error: Invalid <ref> tag; no text was provided for refs named 19-012
  7. Cite error: Invalid <ref> tag; no text was provided for refs named 18-013
  8. Cite error: Invalid <ref> tag; no text was provided for refs named 19-002
  9. 9.0 9.1 9.2 9.3 9.4 Cite error: Invalid <ref> tag; no text was provided for refs named 20-003
  10. 10.0 10.1 10.2 Cite error: Invalid <ref> tag; no text was provided for refs named 20-008
  11. Cite error: Invalid <ref> tag; no text was provided for refs named 20-009
  12. 12.0 12.1 Cite error: Invalid <ref> tag; no text was provided for refs named 20-007