Apr 4th, 2021
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 16.91 KB | None | 0 0
  1. # Fabrique Moderation Guidelines Draft
  3. ## Overview
  5. This provides general guidelines that the moderators and administrators on each platform Fabrique has a presence on should follow.
  7. 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.
  9. ## Expectations
  11. Being part of the moderation staff has a few expectations:
  13. 1. Follow the community guidelines as would a regular user.
  14. 2. All calls to action from the community shall be given fair consideration, up to and including the termination of a project lead.
  15. 3. No one who is part of the moderation may use their position for financial or social gain.
  17. Moderation staff are expected to follow these guidelines at all times.
  19. ## Organisation
  21. ### Administrative Board
  23. The administrative board refers to the group of "Admins" who run the Fabrique community spaces.
  25. To prevent deadlock, there must be at least three people on the administrative board at once.
  27. #### Appointing Members
  29. If there is an absence on the board, one of the following may apply:
  30. - Each remaining admin can nominate somebody (potentially not a moderator) to take the spot
  31. - Any moderators who wish to take on the role can "run" for it
  33. The remaining moderation staff vote on the nominees (those who are running cannot vote in this case but current Administrative Board members can).
  35. #### Voting and Logs
  37. A quorum is needed to make any decisions and is considered a of three members.
  39. Decisions of the board are made by simple majority voting.
  41. If a vote is tied (has no majority) then the vote is considered failed and the status quo is resumed.
  43. All votes must be logged and posted in a place for the entire moderation team to see.
  45. #### Removal
  47. Removal of a board member can be achieved by a simple majority vote of all moderators.
  49. 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.
  51. Once received, the notice is to be posted for the moderation team to review and the board member notified.
  53. 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.
  55. Failing any changes in the decisions of the moderation team, a vote to remove will occur.
  57. #### Decision Jurisdiction and Powers
  58. The board may make decisions in the following areas:
  59. - Acceptance of new moderators
  60. - The acceptance is subject to the rules of moderator appointment
  61. - Direction of development
  62. - Final appeal of banned users
  63. - Moderator Decisions
  65. The board may:
  66. - Establish teams and delegate issues within the main boards purview as established in these guidelines
  67. - If a committee is established, decisions made by it may not be rejected if in relations to appeals of bans
  68. - Teams must have at least two members
  69. - Teams can either establish their own procedures or have rules set by the main board.
  70. - Teams are ultimately required to follow the Fabrique community guidelines.
  71. - Establish their own rules of order, unless they are in contradiction to this document
  73. The board may not:
  74. - Remove moderators
  75. - Delegate powers to anyone that are exclusive to the board, or delegate moderator powers to regular users who are not moderators.
  78. ### Moderators
  80. #### Appointment
  82. Any member of the community may be a moderator and may be appointed.
  84. 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.
  86. Final appointment is subject to a vote of the board by a simple majority.
  88. #### Removal
  90. Moderators may not be removed by the board.
  92. Moderators may be removed by a simple majority vote of all moderators.
  94. #### Role
  96. Moderators are expected to uphold the community guidelines.
  98. Their decisions may be reviewed and overruled by a member of the board.
  100. ### Trainee Positions
  102. Trainee positions can be created by the board for any role, though typically in the context of moderation.
  104. A trainee is appointed in a similar way to a moderator, but is designated a trainee by the board.
  106. They are not considered full members, and do not have voting powers.
  108. Trainees appointed then need re-confirming by the board by a simple majority to become full members.
  110. ## Amendments
  112. The amendment of this document should be handled through the RFC process.
  115. # (WIP) Fabrique Community Guidelines
  117. This document is the community guidelines for the Fabrique project.
  119. This document borrows directly from PaperMC's community guidelines plus and minus a few things.
  120. You can find Paper's community guidelines here:
  121. 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.
  123. The current reference of Paper's community guidelines was taken on the 6rd of February 2021
  124. -->
  126. ## Overview
  128. 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.
  130. This document should be referred to first in most instances and any confusion arising from it should be directed towards the staff team.
  132. ## The Fabrique Community
  134. 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.
  136. For clarity, these community guidelines apply to all of the following:
  138. - Fabrique Discord server
  139. - Fabrique GitHub organization
  140. - This includes: issues, pull requests and any discussion inside issues or pull requests.
  141. - User comments on the Fabrique Twitch channel
  143. <!--Insert additional platforms as necessary-->
  145. ## Guidelines
  147. Fabrique has a fairly short and sweet set of rules. These boil down to:
  149. 1. Don't be a jerk
  150. 2. Listen to project staff
  152. 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.
  154. However, there are specific behaviors we want to avoid in our community. The following example of behaviors are not permitted in the Fabrique community:
  156. 1. Using language or posting content that can reasonably be considered discriminatory.
  157. a. Most of the language banned here should be obvious, but will be listed in more detail below in Zero Tolerance Items.
  159. 2. Posting pornographic, distasteful, or excessively violent content.
  160. a. This is similar to the first rule.
  162. 3. Spamming or excessively sending messages, including repeating questions, resending links too frequently, or posting the same question to multiple channels.
  163. a. Spam bots and trolling users will be immediately banned without warning.
  164. 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.
  165. 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.
  166. ii. Repeating a question because the user is receiving help but doesn't like the answer they received is not fine.
  168. 4. Non-hateful and non-bigoted cursing is fine for the most part
  169. a. However this is no acceptable in user names
  170. b. If someone is cursing in every message, they should be asked to calm down and stop using those words so much.
  172. 5. Formatting usernames to be difficult to read, to impersonate others, to advertise, or to be inappropriate.
  173. 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.
  174. b. Impersonating people includes anyone in or out of the server, not just staff and not just those in Fabrique.
  175. 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.
  177. 6. Pinging server staff, moderators, or contributors without a valid reason.
  178. 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.
  179. b. Someone pinging a particular person because they are responding to that person is not a problem and not even warranting of a warning.
  180. c. There are some users who don't want to be pinged, so please respect their decision.
  182. ## Zero Tolerance Items
  184. 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:
  186. - Racial slurs or racist speech
  187. - Sexist slurs or sexist speech
  188. - Homophobic or transphobic slurs or speech
  189. - Ableist slurs or speech — there's confusion around this term, so to help clarify:
  190. - Ableist slurs are words that refer to people with disabilities used as insults
  191. - Ableist speech is hate speech directed towards people with disabilities
  192. - Any other hate speech not already listed
  193. - Doxxing people
  194. - Personal attacks
  195. - Use of Fabrique for the purpose of cheats
  196. - 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.
  197. - Moderators have the final say over what classifies as a cheat.
  198. - Use of Fabrique for the creation and or spread of malware.
  200. 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.
  202. When someone is removed for violating one of these items, all messages in question will be removed and reported to discord if necessary.
  204. ## Ban appeals
  206. TODO: Detail ban appeals, probably needs platform specific means?
  208. ## Interpretation
  210. Moderators have final say in interpreting the community guidelines.
  212. ## Amendments
  214. 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.
  216. **Last Updated \__INSERT_DATE_HERE_BEFORE_RELEASE**
  219. # fabri**Q**ue **S**tandard **L**ibrary Structure (RFC)
  220. ## Summary
  221. 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.
  223. 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.
  224. ## Motivation
  225. ### Prior Art
  226. Organization of code into visible, transparent modules is a zero-sum game involving QSL maintainers, mod developers, and the end users.
  227. Here is a quick comparison between current systems that exist today:
  228. - Fabric API
  229. -
  230. - Large amount of single-purpose, small, and sometimes interconnected modules, consumed by developers and users as a manually downloaded fat jar.
  231. - Maintainers
  232. -
  233. - Benefits
  234. - Replacing large swaths of code is easy
  235. - The small parts keep scope in check, avoiding "dumping grounds"
  236. - Drawbacks
  237. - Everybody just uses the fat jar
  238. - API visibility is low since modules don't usually inter-connect
  239. - Compare Forge's Item.setModelRenderer (devoldified) to using a registry for everything
  240. - The massive amount of modules makes navigating FAPI confusing
  241. - 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.
  242. - Forge
  243. -
  244. - TODO
  245. ### Goals
  246. - Be mobile and quick to update like Fabric
  247. - Have high API visibility like Forge
  248. - Find a balance between Forge's confusingly monolithic and Fabric's confusingly modular structures
  249. - Have teams in charge of different parts of QSL's code
  250. - Avoid making users download and run code they don't need
  251. ## Explanation
  252. 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.
  254. Each module would be its own repository (disputed). For the purposes of internal structure, each module would have it's own team.
  256. 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.
  258. - `slim` - The bare minimum. As close to `#![no_std]` as you can reasonably get.
  259. - API Base
  260. - Crash Reports
  261. - Resource Loader
  262. - `core` - What most mods will actually depend on; contains things needed for almost every single mod. All other QSL modules depend on `core`.
  263. - depends on `slim`
  264. - Lifecycle Events
  265. - Some parts might be split into `entities` and `world`
  266. - Networking API (maybe with relevant parts split into other modules)
  267. - BlockEntity Networking (merged in)
  268. - Registry Sync (merged in)
  269. - (future) Proper Handshake API
  270. - Mod menu?
  271. - Config API screens?
  272. - `transfer`
  273. - API Lookup API
  274. - fluid api
  275. - item transfer api
  276. - `item_groups`
  277. - ItemGroups API
  278. - `blocks`
  279. - depends on `item_groups`
  280. - Object Builder API (FabricBlockSettings, FabricBlockEntityBuilder and FabricMaterialBuilder)
  281. - (future) Block Extensions (think IForgeBlock)
  282. - Content Registries (Flammable Block Registry)
  283. - `items`
  284. - depends on `item_groups`
  285. - Item API
  286. - Content Registries (Fuel Registry, Composting Registry)
  287. - Tool Attribute API
  288. - (future) Item Extensions (think IForgeItem)
  289. - `entities`
  290. - Object Builder API (EntityType Builder, Trades, Villager Professions and Types)
  291. - Entity Events
  292. - `configuration_and_administration` // better name needed
  293. - Command API
  294. - Game Rule API
  295. - (future) Permissions API
  296. - `rendering` // these submodules need merged into larger chunks, assuming we keep submodules
  297. - BlockRenderLayer Registration
  298. - Indigo
  299. - need an easy way to exclude this
  300. - Models
  301. - Renderer API
  302. - This may need a better name?
  303. - Rendering
  304. - Renderer Registries
  305. - Rendering Fluids
  306. - Textures
  307. - Object Builder API (FabricModelPredicateProviderRegistry)
  308. - `data` - Tools for working with, generating, or consuming data (i.e. datapacks, advancements, recipes, tags)
  309. - (future) Recipe API
  310. - (future) Datagen APIs
  311. - Rendering Data Attachment
  312. - Tag Extensions
  313. - Loot Tables
  314. - Object Builder API (Criterion)
  315. - `world` // Needs better name to avoid confusion with Worldgen
  316. - Particles
  317. - Object Builder API (Point of interest)
  318. - Interaction Events
  319. - Could probably use refactoring, but as it stands this absolutely deals with events happening in the world
  320. - Key Binding API
  321. - 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
  322. - `worldgen`
  323. - Dimension API
  324. - Biome API
  325. - Structure API
  326. - `gui`
  327. - Screen API
  328. - Despite the name, all this module really does is add hooks for modifying prexisting screens
  329. - ScreenHandler API
  330. - if this module is dropped this could also go in `world`
  331. - (potentially in the future) Screen Extensions
  332. ## Drawbacks
  333. TODO
  334. ## Rationale and Alternatives
  335. TODO
  336. ## Unresolved Questions
  337. 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?
  339. ## Expected Response
  340. 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.
  342. 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.
Add Comment
Please, Sign In to add comment