# Fabrique Moderation Guidelines Draft

## Overview

This provides general guidelines that the moderators and administrators on each platform Fabrique has a presence on should follow.

The vision of this document is that it is living; this means that it can evolve and change over time to reflect the state of the project.

## Expectations

Being part of the moderation staff has a few expectations:

1. Follow the community guidelines as would a regular user.
2. All calls to action from the community shall be given fair consideration, up to and including the termination of a project lead.
3. No one who is part of the moderation may use their position for financial or social gain.

Moderation staff are expected to follow these guidelines at all times.

## Organisation

### Administrative Board

The administrative board refers to the group of "Admins" who run the Fabrique community spaces.

To prevent deadlock, there must be at least three people on the administrative board at once.

#### Appointing Members

If there is an absence on the board, one of the following may apply:
- Each remaining admin can nominate somebody (potentially not a moderator) to take the spot
- Any moderators who wish to take on the role can "run" for it

The remaining moderation staff vote on the nominees (those who are running cannot vote in this case but current Administrative Board members can).

#### Voting and Logs

A quorum is needed to make any decisions and is considered a of three members.

Decisions of the board are made by simple majority voting.

If a vote is tied (has no majority) then the vote is considered failed and the status quo is resumed.

All votes must be logged and posted in a place for the entire moderation team to see.

#### Removal

Removal of a board member can be achieved by a simple majority vote of all moderators.

A vote for removal is called when a moderator lodges a formal notice with the Fabrique moderation team. This notice must contain the reason for removal and seconded by another moderator. This other moderator may be on the board.

Once received, the notice is to be posted for the moderation team to review and the board member notified.

The board member in question has one week from the posting to answer the body of the complaint in a counter. This counter is designed to be one concise answer in one place.

Failing any changes in the decisions of the moderation team, a vote to remove will occur.

#### Decision Jurisdiction and Powers
The board may make decisions in the following areas:
- Acceptance of new moderators
    - The acceptance is subject to the rules of moderator appointment
- Direction of development
- Final appeal of banned users
- Moderator Decisions

The board may:
- Establish teams and delegate issues within the main boards purview as established in these guidelines
    - If a committee is established, decisions made by it may not be rejected if in relations to appeals of bans
    - Teams must have at least two members
    - Teams can either establish their own procedures or have rules set by the main board.
    - Teams are ultimately required to follow the Fabrique community guidelines.
- Establish their own rules of order, unless they are in contradiction to this document

The board may not:
- Remove moderators
- Delegate powers to anyone that are exclusive to the board, or delegate moderator powers to regular users who are not moderators.


### Moderators

#### Appointment

Any member of the community may be a moderator and may be appointed.

Moderators are suggested by any current member of the wider team and must be seconded by another team member who is not on the board.

Final appointment is subject to a vote of the board by a simple majority.

#### Removal

Moderators may not be removed by the board.

Moderators may be removed by a simple majority vote of all moderators.

#### Role

Moderators are expected to uphold the community guidelines.

Their decisions may be reviewed and overruled by a member of the board.

### Trainee Positions

Trainee positions can be created by the board for any role, though typically in the context of moderation.

A trainee is appointed in a similar way to a moderator, but is designated a trainee by the board.

They are not considered full members, and do not have voting powers.

Trainees appointed then need re-confirming by the board by a simple majority to become full members.

## Amendments

The amendment of this document should be handled through the RFC process.


# (WIP) Fabrique Community Guidelines

This document is the community guidelines for the Fabrique project.

This document borrows directly from PaperMC's community guidelines plus and minus a few things.
You can find Paper's community guidelines here: https://papermc.io/community-guidelines
As such this document is also licensed under the "Creative Commons Attribution-ShareAlike 4.0 International Public License" like Paper's community guidelines as a derivative.

The current reference of Paper's community guidelines was taken on the 6rd of February 2021
-->

## Overview

This document describes what the Fabrique Community is, general guidelines for the community, how rules will be changed and outlines some forms of unacceptable behavior.

This document should be referred to first in most instances and any confusion arising from it should be directed towards the staff team.

## The Fabrique Community

The community guidelines defines "The Fabrique community" as all communication within the Fabrique ecosystem. This includes every forum of communication that is officially part of the Fabrique project.

For clarity, these community guidelines apply to all of the following:

- Fabrique Discord server
- Fabrique GitHub organization
    - This includes: issues, pull requests and any discussion inside issues or pull requests.
- User comments on the Fabrique Twitch channel

<!--Insert additional platforms as necessary-->

## Guidelines

Fabrique has a fairly short and sweet set of rules. These boil down to:

1. Don't be a jerk
2. Listen to project staff

Creating an exhaustive list for all negative behavior we want to avoid is impossible and likely won't help. The kinds of people who would engage in such a way in the first place probably aren't the people we want around at all.

However, there are specific behaviors we want to avoid in our community. The following example of behaviors are not permitted in the Fabrique community:

1. Using language or posting content that can reasonably be considered discriminatory.
   a. Most of the language banned here should be obvious, but will be listed in more detail below in Zero Tolerance Items.

2. Posting pornographic, distasteful, or excessively violent content.
   a. This is similar to the first rule.

3. Spamming or excessively sending messages, including repeating questions, resending links too frequently, or posting the same question to multiple channels.
   a. Spam bots and trolling users will be immediately banned without warning.
   b. Users who are looking for help and are incessantly repeating questions because they aren't receiving any answers should be asked to stop repeating their question so often and be patient instead.
   i. Repeating a question after some time has passed and the question is no longer current and the conversation has changed is fine, as long as it's not too repetitive.
   ii. Repeating a question because the user is receiving help but doesn't like the answer they received is not fine.

4. Non-hateful and non-bigoted cursing is fine for the most part
   a. However this is no acceptable in user names
   b. If someone is cursing in every message, they should be asked to calm down and stop using those words so much.

5. Formatting usernames to be difficult to read, to impersonate others, to advertise, or to be inappropriate.
   a.  If a curse word is in their username, that's basically the same as saying that word every time they send a message - so must be removed.
   b. Impersonating people includes anyone in or out of the server, not just staff and not just those in Fabrique.
   c. Usernames that are nothing but a bunch of symbols that are impossible to pronounce aren't very conducive of a good conversation environment. However, this does not apply to usernames in different languages and alphabets. There is a difference between having a username in Japanese and having only random symbols as your username.

6. Pinging server staff, moderators, or contributors without a valid reason.
   a. Valid reasons include when normal users may not be able to help, or when reporting dupe glitches or critical bugs. However you should responsibly disclose the critical bugs and dupe glitches first.
   b. Someone pinging a particular person because they are responding to that person is not a problem and not even warranting of a warning.
   c. There are some users who don't want to be pinged, so please respect their decision.

## Zero Tolerance Items

Particularly severe issues represent a behavior and a kind of person we don't want associated with Fabrique in any way. These behaviors will result in an immediate ban without warning:

- Racial slurs or racist speech
- Sexist slurs or sexist speech
- Homophobic or transphobic slurs or speech
- Ableist slurs or speech — there's confusion around this term, so to help clarify:
    - Ableist slurs are words that refer to people with disabilities used as insults
    - Ableist speech is hate speech directed towards people with disabilities
- Any other hate speech not already listed
- Doxxing people
- Personal attacks
- Use of Fabrique for the purpose of cheats
    - A cheat is a modification to the game that intentionally grants the user an unfair advantage over another user who may or may not have the modification installed.
    - Moderators have the final say over what classifies as a cheat.
- Use of Fabrique for the creation and or spread of malware.

This list is not exhaustive. If someone is engaging in bad behavior not conducive to a friendly environment and moderators believe it warrants an immediate ban, then they will do so.

When someone is removed for violating one of these items, all messages in question will be removed and reported to discord if necessary.

## Ban appeals

TODO: Detail ban appeals, probably needs platform specific means?

## Interpretation

Moderators have final say in interpreting the community guidelines.

## Amendments

Changes to the community guidelines must be announced via a blog post through the website and given a  week approval period with allowance for comments before changes are made.

**Last Updated \__INSERT_DATE_HERE_BEFORE_RELEASE**


# fabri**Q**ue **S**tandard **L**ibrary Structure (RFC)
## Summary
This documents provides the basis on how to structure the Fabrique Standard Library. It seeks to define how Fabric's current API will be split into several "super" modules for the purposes of development. It does not define the structure of the submodules within these modules; that is left to the teams discretion when creating QSL.

Additionally, it defines that mods will depend on QSL as a fat jar, and Loom is expected to detect what (sub/super)modules are being used and automatically mark them to be downloaded at runtime.
## Motivation
### Prior Art
Organization of code into visible, transparent modules is a zero-sum game involving QSL maintainers, mod developers, and the end users.
Here is a quick comparison between current systems that exist today:
- Fabric API
  -
    - Large amount of single-purpose, small, and sometimes interconnected modules, consumed by developers and users as a manually downloaded fat jar.
    - Maintainers
      -
        - Benefits
            - Replacing large swaths of code is easy
            - The small parts keep scope in check, avoiding "dumping grounds"
        - Drawbacks
            -  Everybody just uses the fat jar
            -  API visibility is low since modules don't usually inter-connect
                -  Compare Forge's Item.setModelRenderer (devoldified) to using a registry for everything
            -  The massive amount of modules makes navigating FAPI confusing
            -  Even though there are small modules, there are no larger groups, so you can't go looking for "item extensions", you need to find Content Registries, Tool Attribute API, Item API, etc.
- Forge
  -
    - TODO
### Goals
- Be mobile and quick to update like Fabric
- Have high API visibility like Forge
- Find a balance between Forge's confusingly monolithic and Fabric's confusingly modular structures
- Have teams in charge of different parts of QSL's code
- Avoid making users download and run code they don't need
## Explanation
This is an overview of the top-level structure of QSL. Modules are included, with the names of the FAPI modules that would be under its scope. The actual structure of the submodules is up to each team when developing their module.

Each module would be its own repository (disputed). For the purposes of internal structure, each module would have it's own team.

To modders, most mods would not explicitly depend on modules or submodules (with the exception of things like a potential ModMenu), but Loom would automatically determine the (sub/super)modules to depend on by scanning each class, and those (sub/super)modules will be downloaded at runtime by Loader.

- `slim` - The bare minimum. As close to `#![no_std]` as you can reasonably get.
    - API Base
    - Crash Reports
    - Resource Loader
- `core` - What most mods will actually depend on; contains things needed for almost every single mod. All other QSL modules depend on `core`.
    - depends on `slim`
    - Lifecycle Events
        - Some parts might be split into `entities` and `world`
    - Networking API (maybe with relevant parts split into other modules)
        - BlockEntity Networking (merged in)
        - Registry Sync (merged in)
        - (future) Proper Handshake API
    - Mod menu?
        - Config API screens?
- `transfer`
    - API Lookup API
    - fluid api
    - item transfer api
- `item_groups`
    - ItemGroups API
- `blocks`
    - depends on `item_groups`
    - Object Builder API (FabricBlockSettings, FabricBlockEntityBuilder and FabricMaterialBuilder)
    - (future) Block Extensions (think IForgeBlock)
    - Content Registries (Flammable Block Registry)
- `items`
    - depends on `item_groups`
    - Item API
    - Content Registries (Fuel Registry, Composting Registry)
    - Tool Attribute API
    - (future) Item Extensions (think IForgeItem)
- `entities`
    - Object Builder API (EntityType Builder, Trades, Villager Professions and Types)
    - Entity Events
- `configuration_and_administration` // better name needed
    - Command API
    - Game Rule API
    - (future) Permissions API
- `rendering` // these submodules need merged into larger chunks, assuming we keep submodules
    - BlockRenderLayer Registration
    - Indigo
        - need an easy way to exclude this
    - Models
    - Renderer API
        - This may need a better name?
    - Rendering
    - Renderer Registries
    - Rendering Fluids
    - Textures
    - Object Builder API (FabricModelPredicateProviderRegistry)
- `data` - Tools for working with, generating, or consuming data (i.e. datapacks, advancements, recipes, tags)
    - (future) Recipe API
    - (future) Datagen APIs
    - Rendering Data Attachment
    - Tag Extensions
    - Loot Tables
    - Object Builder API (Criterion)
- `world` // Needs better name to avoid confusion with Worldgen
    - Particles
    - Object Builder API (Point of interest)
    - Interaction Events
        - Could probably use refactoring, but as it stands this absolutely deals with events happening in the world
    - Key Binding API
        - I'm not even confident these can be used outside of worlds, and either way all of the Vanilla examples point to being world-ly
- `worldgen`
    - Dimension API
    - Biome API
    - Structure API
- `gui`
    - Screen API
        - Despite the name, all this module really does is add hooks for modifying prexisting screens
    - ScreenHandler API
        - if this module is dropped this could also go in `world`
    - (potentially in the future) Screen Extensions
## Drawbacks
TODO
## Rationale and Alternatives
TODO
## Unresolved Questions
What kind of granularity should we provide with modules? Should mods be able (either explicitly, or through auto-detection) be able to depend on sub-modules, or just the larger modules?

## Expected Response
Because Fabric API is almost always used in a monolithic structure anyway, this new structure is expected to have little impact on the average modder.

The separation of QSL into teams and their own repositories may increase the complexity of submitting PRs, but if executed properly this shouldn't be a big issue.