├── .gitignore ├── 0000-template.md ├── LICENSE.md ├── README.md ├── figures └── quilt-goverance-diagram.png ├── rfc ├── 0009-qsl-structure.md ├── 0019-hashed-mojmap.md ├── 0032-loader-plugins.md ├── 0033-quilt-mappings-and-clean-room.md ├── 0061-sponsorships.md └── README.MD ├── specification ├── 0002-quilt.mod.json.md ├── 0041-hashed-mappings-specification.md ├── 0081-active-user-beacon.md └── README.MD └── structure ├── 0001-rfc-process.md ├── 0006-governance.md ├── 0007-community-team.md ├── 0018-technical-teams.md ├── 0039-pr-policy.md ├── 0048-outreach-team.md ├── 0054-quilt-kotlin-team.md ├── 0068-qsl-teams.md └── README.MD /.gitignore: -------------------------------------------------------------------------------- 1 | .idea/ 2 | -------------------------------------------------------------------------------- /0000-template.md: -------------------------------------------------------------------------------- 1 | # Template RFC 2 | 3 | This template is intended to serve as a guideline for what should be included 4 | in the typical RFC. Some of this may not be relevant to all RFCs, and that's 5 | fine, but it's best to follow this template where possible. (Delete this 6 | paragraph from your actual RFC.) 7 | 8 | ## Summary 9 | 10 | One paragraph explanation of this suggestion. Don't go into too much detail 11 | here; that goes in the explanation section. This should just give readers a 12 | general idea of what this RFC does. 13 | 14 | 15 | ## Motivation 16 | 17 | Why should we do this? What are the benefits? 18 | 19 | 20 | ## Explanation 21 | 22 | Explain this change in detail. This section will be different depending on what 23 | sort of change it is. 24 | 25 | For technical changes, such as changes to APIs, first give an overview of how 26 | this proposed change would work. Explain how it would be used, with code 27 | examples. Then, give a more in depth explanation of how it would be implemented 28 | and how it would interact with other parts of the project and other Quilt 29 | projects. 30 | 31 | For social changes, such as changes to community guidelines, governance, or the 32 | RFC process itself, this section should explain how the new rule or process 33 | will work. Be thorough and clear here, so that everyone can have the same 34 | understanding of this suggestion. 35 | 36 | 37 | ## Drawbacks 38 | 39 | Why should we not do this? 40 | 41 | 42 | ## Rationale and Alternatives 43 | 44 | - Why is this the best possible design? 45 | - What other designs are possible and why should we choose this one instead? 46 | - What other designs have benefits over this one? Why should we choose an 47 | alternative instead? 48 | - What is the impact of not doing this? 49 | 50 | 51 | ## Prior Art 52 | 53 | If this has been done before by some other project, explain it here. This could 54 | be positive or negative. Discuss what worked well for them and what didn't. 55 | 56 | There may not always be prior art, and that's fine. 57 | 58 | 59 | ## Unresolved Questions 60 | 61 | - What should be resolved before this RFC gets merged? 62 | - What should be resolved while implementing this RFC? 63 | - What unresolved questions do you consider out of scope for this RFC, that 64 | could be addressed in the future? 65 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | # Creative Commons Attribution-ShareAlike 4.0 International 2 | 3 | Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible. 4 | 5 | **Using Creative Commons Public Licenses** 6 | 7 | Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses. 8 | 9 | * __Considerations for licensors:__ Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. [More considerations for licensors](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensors). 10 | 11 | * __Considerations for the public:__ By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. [More considerations for the public](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensees). 12 | 13 | ## Creative Commons Attribution-ShareAlike 4.0 International Public License 14 | 15 | By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. 16 | 17 | ### Section 1 – Definitions. 18 | 19 | a. __Adapted Material__ means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. 20 | 21 | b. __Adapter's License__ means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. 22 | 23 | c. __BY-SA Compatible License__ means a license listed at [creativecommons.org/compatiblelicenses](http://creativecommons.org/compatiblelicenses), approved by Creative Commons as essentially the equivalent of this Public License. 24 | 25 | d. __Copyright and Similar Rights__ means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. 26 | 27 | e. __Effective Technological Measures__ means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. 28 | 29 | f. __Exceptions and Limitations__ means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. 30 | 31 | g. __License Elements__ means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike. 32 | 33 | h. __Licensed Material__ means the artistic or literary work, database, or other material to which the Licensor applied this Public License. 34 | 35 | i. __Licensed Rights__ means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. 36 | 37 | j. __Licensor__ means the individual(s) or entity(ies) granting rights under this Public License. 38 | 39 | k. __Share__ means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. 40 | 41 | l. __Sui Generis Database Rights__ means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. 42 | 43 | m. __You__ means the individual or entity exercising the Licensed Rights under this Public License. __Your__ has a corresponding meaning. 44 | 45 | ### Section 2 – Scope. 46 | 47 | a. ___License grant.___ 48 | 49 | 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: 50 | 51 | A. reproduce and Share the Licensed Material, in whole or in part; and 52 | 53 | B. produce, reproduce, and Share Adapted Material. 54 | 55 | 2. __Exceptions and Limitations.__ For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 56 | 57 | 3. __Term.__ The term of this Public License is specified in Section 6(a). 58 | 59 | 4. __Media and formats; technical modifications allowed.__ The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. 60 | 61 | 5. __Downstream recipients.__ 62 | 63 | A. __Offer from the Licensor – Licensed Material.__ Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. 64 | 65 | B. __Additional offer from the Licensor – Adapted Material.__ Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply. 66 | 67 | C. __No downstream restrictions.__ You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 68 | 69 | 6. __No endorsement.__ Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). 70 | 71 | b. ___Other rights.___ 72 | 73 | 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 74 | 75 | 2. Patent and trademark rights are not licensed under this Public License. 76 | 77 | 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. 78 | 79 | ### Section 3 – License Conditions. 80 | 81 | Your exercise of the Licensed Rights is expressly made subject to the following conditions. 82 | 83 | a. ___Attribution.___ 84 | 85 | 1. If You Share the Licensed Material (including in modified form), You must: 86 | 87 | A. retain the following if it is supplied by the Licensor with the Licensed Material: 88 | 89 | i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); 90 | 91 | ii. a copyright notice; 92 | 93 | iii. a notice that refers to this Public License; 94 | 95 | iv. a notice that refers to the disclaimer of warranties; 96 | 97 | v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; 98 | 99 | B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and 100 | 101 | C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. 102 | 103 | 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 104 | 105 | 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. 106 | 107 | b. ___ShareAlike.___ 108 | 109 | In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply. 110 | 111 | 1. The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License. 112 | 113 | 2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material. 114 | 115 | 3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply. 116 | 117 | ### Section 4 – Sui Generis Database Rights. 118 | 119 | Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: 120 | 121 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; 122 | 123 | b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and 124 | 125 | c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. 126 | 127 | For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. 128 | 129 | ### Section 5 – Disclaimer of Warranties and Limitation of Liability. 130 | 131 | a. __Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.__ 132 | 133 | b. __To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.__ 134 | 135 | c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. 136 | 137 | ### Section 6 – Term and Termination. 138 | 139 | a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. 140 | 141 | b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 142 | 143 | 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 144 | 145 | 2. upon express reinstatement by the Licensor. 146 | 147 | For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. 148 | 149 | c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. 150 | 151 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. 152 | 153 | ### Section 7 – Other Terms and Conditions. 154 | 155 | a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. 156 | 157 | b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. 158 | 159 | ### Section 8 – Interpretation. 160 | 161 | a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. 162 | 163 | b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. 164 | 165 | c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. 166 | 167 | d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. 168 | 169 | > Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” The text of the Creative Commons public licenses is dedicated to the public domain under the [CC0 Public Domain Dedication](https://creativecommons.org/publicdomain/zero/1.0/legalcode). Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at [creativecommons.org/policies](http://creativecommons.org/policies), Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses. 170 | 171 | > 172 | 173 | > Creative Commons may be contacted at creativecommons.org. 174 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # The Quilt RFC Process 2 | This document gives an outline of how the RFC process works and explains how contributors should submit their RFCs to the project. 3 | 4 | ## When you must submit an RFC 5 | The RFC process requires that any large top-level organizational changes should be preceded by a "Request For Comments" document just like this one, explaining the proposed change, the motivation behind it, potential drawbacks, and other considerations. These documents are then discussed and revised by the community for some period of time until a maintainer decides that enough discussion has happened and begins a final comment period, after which a final decision is made. 6 | 7 | Most smaller changes to Quilt projects (such as bugfixes) can be submitted via the normal GitHub pull request system, however some are substantial enough that we would prefer that members of the community are given some time to discuss the potential change and give their feedback. 8 | 9 | While this document describes when RFC's are required on an organizational level, individual organizational units, such as the Quilt Standard Libraries or Quilt Loader teams, may also require RFCs. 10 | 11 | ## Creating an RFC 12 | A proper RFC is a high quality, well thought out document describing in detail all the possible benefits, drawbacks, and other consequences of the suggested change. A low effort or low quality RFC is likely to be rejected quickly. 13 | 14 | Before beginning the process, it can be helpful to discuss your ideas with other community members on our [discord server](https://discord.quiltmc.org/) to get a feel for the community's opinion on the issue. 15 | 16 | Once you have a good idea of what you want to suggest, and how the community feels about it, you can begin writing your RFC. 17 | 18 | ## The Process 19 | When you are ready to submit an RFC, the process will work as follows: 20 | - Fork the RFC git repository 21 | - Copy `0000-template.md` to `0000-my-suggestion.md` (replace `my-suggestion` 22 | with a descriptive name for your RFC). Don't change the number yet; you will 23 | replace the `0000` with your pull request number from GitHub once you have 24 | submitted the PR. 25 | - Fill in the template. This should be done with care and effort. You are 26 | making a major suggestion for a change to the project – take it 27 | seriously. 28 | - Submit a pull request. An open pull request represents an RFC which is still 29 | in the commentary phase. You will receive comments and feedback from other 30 | community members. You should be prepared to revise your RFC in response to 31 | some of this feedback. 32 | - Now that you have an open pull request, rename your markdown file to replace 33 | the `0000` with your PR number. 34 | - Your PR will be labelled with the relevant project team's label. That team 35 | will be responsible for handling the RFC process from here on. 36 | - Build consensus among the community and incorporate feedback from others. 37 | RFCs with broad support are more likely to be accepted. 38 | - The team responsible for the RFC will discuss the RFC as much as possible in 39 | the pull request's comments. Discussion that occurs in other spaces should be 40 | summarized in the PR comments. 41 | - When the team responsible for the RFC decides that there has been enough discussion, a member of the team will issue a "motion for final comments". If the motion passes, it begins a 10 day period where the community has the last chance to give feedback on an RFC. 42 | + This step is taken when enough discussion has happened to make a final decision on the issue. It is designed to prevent RFCs from becoming stales. 43 | + A consensus among all community members *is not necessary* for an RFC to 44 | enter the final comment period. However, there should not be a strong 45 | consensus *against* the disposition given for the final comment period, and 46 | some argument supporting the decision should be clearly presented somewhere 47 | in prior discussion. 48 | + If discussion has gone on for a long time, the team member who motions for 49 | final comments should post a summary comment outlining all of the 50 | discussion that has occurred. 51 | + Before actually entering the final comment period, all members of the team 52 | must sign their approval. 53 | + When a team member motions for final comments, they also give a 54 | "disposition" which can be either accept, reject, or postpone. This 55 | determines what will happen to the RFC at the end of the final comment 56 | period, although the disposition may change during that period. 57 | - At the end of the final comment period, the RFC will be either accepted or 58 | rejected depending on its disposition at the close of the final comment 59 | period. 60 | + If an RFC is accepted, its PR will be merged into the main RFCs 61 | repository on GitHub and an issue (or issues) will be created on the 62 | relevant repositories to actually implement the changes. This does not 63 | necessarily mean that PRs implementing it will be automatically merged. 64 | All PRs are still subject to code quality standards and the like. 65 | + If an RFC is rejected, its PR will be closed and the suggested changes 66 | will not be implemented. 67 | + An RFC may also be "postponed". This means the RFC is effectively 68 | rejected at the moment because it does not fit into the project's 69 | near-term goals, but may be accepted at a later date. 70 | -------------------------------------------------------------------------------- /figures/quilt-goverance-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/QuiltMC/rfcs/ca458de2fef50da15d892e96be1165ce775255f2/figures/quilt-goverance-diagram.png -------------------------------------------------------------------------------- /rfc/0009-qsl-structure.md: -------------------------------------------------------------------------------- 1 | # QSL Structure 2 | ## Summary 3 | This documents provides the basis on how to structure the Quilt Standard Library. It seeks to define how Fabric's current API will be split into several libraries (collections of modules) for the purposes of development. It does not define the structure of the modules within these libraries; that is left to the teams discretion when creating QSL, besides the guideline that modules should be generally larger than what is expected in Fabric API. 4 | 5 | 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. 6 | ## Motivation 7 | ### Prior Art 8 | Organization of code into visible, transparent modules is a zero-sum game involving QSL maintainers, mod developers, and the end users. 9 | Here is a quick comparison between current systems that exist today: 10 | - Fabric API 11 | - 12 | - Large amount of single-purpose, small, and sometimes interconnected modules, consumed by developers and users as a manually downloaded fat jar. 13 | - Maintainers 14 | - 15 | - Benefits 16 | - Replacing large swaths of code is easy 17 | - The small parts keep scope in check, avoiding "dumping grounds" 18 | - Drawbacks 19 | - Everybody just uses the fat jar 20 | - API visibility is low since modules don't usually inter-connect 21 | - Compare Forge's Item.setModelRenderer (devoldified) to using a registry for everything 22 | - The massive amount of modules makes navigating FAPI confusing 23 | - Even though there are small modules, modules are often very tiny--Extensions of Items might be split across Content Registries, Item API, Tool Item API, 24 | - Forge 25 | - 26 | - Benefits 27 | - Monolithic API makes adding new features straightforward 28 | - Drawbacks 29 | - It is more difficult to remove parts of code as Mojang breaks them 30 | - Lack of compartmentalization leads to seemingly unrelated APIs being intertwined 31 | - No api/impl split makes it difficult to know what part of the code you are actually supposed to interact with 32 | ### Goals 33 | - Be mobile and quick to update like Fabric 34 | - Have high API visibility like Forge 35 | - Find a balance between Forge's confusingly monolithic and Fabric's confusingly modular structures 36 | - Have teams in charge of different parts of QSL's code 37 | - Avoid making users download and run code they don't need 38 | ## Explanation 39 | This is an overview of the top-level structure of QSL. Libraries are included, with the names of the FAPI modules that would be under its scope. The actual structure of the modules in each library is up to the team, and it is not a goal to define how they must structure their modules. 40 | ### Libraries 41 | Each library would be its own folder in the QSL monorepo, with a dedicated team responsible for triage, review, and accepting/denying pull requests. In contrast to Fabric or Forge's system of only one person signing off for the entire standard library, no authority higher than the people on the team would be required to sign off on the PR before it is merged. More clarification on team structure is expected to come in a future RFC. 42 | 43 | Ideally, there would be no common usage "fat" jars of libraries and modules because of Loader's automatic dependency downloading. We will probably have to provide fat jars until Loader is able to support dependency downloading, and discussion about stopping providing fat jars can happen there. 44 | ### Modules 45 | Modules follow the following general rules: 46 | - Maven group of `org.quiltmc.qsl.$library` 47 | - Artifact id of `mod-id` 48 | - Semantic Versioning. Hashes are *not* used to identify modules. 49 | - Can only depend on modules from `core` or within their own library. 50 | 51 | To modders, most mods would not explicitly depend on libraries or their modules, but Loom would automatically determine the modules to depend on by scanning at compile time, and those modules will be downloaded at runtime by Loader. However, they will have the choice to manually depend on individual modules. There are no plans to provide fat jars for libraries or QSL as a whole at this time, besides as a temporary solution until Loader Plugins are implemented. 52 | ### Top-level Structure 53 | Keep in mind that the modules listed here are the names of the current Fabric API modules, and the final internal structure of QSL **will not** be the same as Fabric API. 54 | - `core` - All modules here are implicitly depended on by mods by default, even if they do not use any code from them. Mods can choose to opt-out. This library may be provided by the installer by default, in order to allow a handshake API to always be present. 55 | - Lifecycle Events 56 | - Networking API (maybe with relevant parts split into other modules) 57 | - Registry Sync 58 | - (future) Proper Handshake API 59 | - Crash Reports 60 | - Resource Loader 61 | - `transfer` 62 | - API Lookup API 63 | - fluid api 64 | - item transfer api 65 | - `command` 66 | - Command API 67 | - `rendering` 68 | - BlockRenderLayer Registration 69 | - Indigo 70 | - need an easy way to exclude this 71 | - Models 72 | - Renderer API 73 | - This may need a better name in a spot? 74 | - Rendering 75 | - Renderer Registries 76 | - Rendering Fluids 77 | - Textures 78 | - Object Builder API (FabricModelPredicateProviderRegistry) 79 | - Rendering Data Attachment // This isn't client-side only, yet, because implementing an interface on one side is a pain 80 | - `data` - Tools for working with, generating, or consuming data (e.g. datapacks, advancements, recipes, tags) 81 | - (future) Recipe API 82 | - (future) Datagen APIs 83 | - Tag Extensions 84 | - Loot Tables 85 | - Object Builder API (Criterion) 86 | - `block` 87 | - BlockEntity Networking 88 | - Object Builder API (FabricBlockSettings, FabricBlockEntityBuilder and FabricMaterialBuilder) 89 | - (future) Block Extensions (think IForgeBlock) 90 | - Content Registries (Flammable Block Registry) 91 | - `item` 92 | - Item API 93 | - Content Registries (Fuel Registry, Composting Registry) 94 | - Tool Attribute API 95 | - (future) Item Extensions (think IForgeItem) 96 | - Item Groups 97 | - `entity` 98 | - Object Builder API (EntityType Builder, Trades, Villager Professions and Types) 99 | - Entity Events 100 | - Interaction Events 101 | - Object Builder API (Point of interest) 102 | - Not strictly related to entities but it is needed here so it can be used for other entity-related apis 103 | - `content_other` 104 | - Particles 105 | - Game Rule API 106 | - `worldgen` 107 | - Dimension API 108 | - Biome API 109 | - Structure API 110 | - `gui` 111 | - Screen API 112 | - Despite the name, all this module really does is add hooks for modifying prexisting screens 113 | - ScreenHandler API 114 | - (potentially in the future) Screen Extensions 115 | - Key Bindings API 116 | ## Drawbacks 117 | Yet another change in structure and interaction with the API may make it more difficult to contribute to QSL. 118 | 119 | It may be difficult to find the right level of granularity for libraries, and there might be lots of flux as we figure out the correct amount of libraries and how large we want the teams to be. 120 | 121 | The compile-time scanning of used features adds additional complexity to our build process, and might be buggy. 122 | ## Unresolved Questions 123 | Most things not defined here are left to the discretion of the QSL Technical Lead and their teams, as defined in the (future) Technical Teams RFC. 124 | 125 | In the future, there may be a "library group"--a group of modules that is allowed to bypass the library sandboxing restriction within that group. This will be defined in a later RFC if we find it is actually needed. 126 | ## Expected Response 127 | 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. 128 | 129 | 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. 130 | -------------------------------------------------------------------------------- /rfc/0019-hashed-mojmap.md: -------------------------------------------------------------------------------- 1 | # Hashed Mojmap 2 | 3 | ## Summary 4 | 5 | This RFC proposes replacing intermediary with a hashed version of Mojmap. Everywhere where intermediary is currently used, hashed Mojmap will be used instead. 6 | 7 | ## Motivation 8 | 9 | - One of the biggest, if not the biggest, reliance of Quilt on upstream Fabric is intermediary. For as long as Fabric keeps updating to new Minecraft versions, we will be behind them on updating because of this limitation. It is also not a good thing for a hard fork to have a reliance on upstream. 10 | 11 | - One of the primary goals of intermediary is to make sure that mods don't have to recompile between versions. However, when mods make the switch from Fabric to Quilt, they will have to recompile anyway. This gives us a unique opportunity to make breaking changes to the format of intermediary without breaking mods. 12 | 13 | - Intermediary was a good solution at the time of its inception. Since then, Mojang has provided us with their official mappings, with permission to use them as long as we don't redistribute them. Having to match intermediary between versions introduces a high maintenance cost for every snapshot and potentially also limits the bus factor of the whole project. The majority of the time updating Fabric to snapshots is typically spent matching. 14 | 15 | 16 | ## Explanation 17 | 18 | Hashed Mojmap will produce 8-digit base-26 hashes of information taken from Mojmap to produce names like the following: 19 | 20 | - Classes: `C_bgbfjdpu` 21 | - Fields: `f_jhuobxwz` 22 | - Methods: `m_tyyngmfw` 23 | 24 | To produce the hashes, the Mojmap names are processed as follows: 25 | 26 | 1. For classes, their simple name is used (e.g. `Class$Inner`). 27 | If the simple name is not unique, the full name is used (e.g. `com/example/Class$Inner`). 28 | 1. For fields, their name is combined with its descriptor and owning class in the format `f;.;`. 29 | The class name is again stripped of its package where possible. 30 | For fields whose names are unique in their enclosing class, the descriptor is replaced with the empty string. 31 | 1. For methods, the same formatting as for fields is used except for the prefix: `m;.;`. 32 | Again, package and descriptor are omitted where possible. 33 | 1. Some methods are required to be named identical by the jvm (for overriding). 34 | For these methods, we only consider the top-level methods and chose the one with the lexicographically last formatted name. 35 | 1. The resulting strings are hashed using SHA-256. 36 | Only the lower 8 digits of its base-26 representation are used and then prefixed with `C_` for classes, `m_` for methods and `f_` for fields. 37 | 38 | The above steps are designed to preserve some of the benefits of intermediary as much as possible without the need for matching. 39 | Testing has shown that around 50% of class renames in Mojmap are only repackages. 40 | Since only a handful of classes require the full name to be used, this is very unlikely to affect hashed Mojmap. 41 | Testing has also shown that omitting the descriptor greatly improves the stability of the mappings. 42 | While there are many more non-unique methods than classes, descriptor changes are by far even more common. 43 | 44 | ### Probability of collision 45 | 46 | As with any hash, a hash of Mojmap names is not guaranteed to be unique. Therefore, hash lengths were chosen such that the probability that we ever encounter such a collision within the lifetime of Quilt (and then some) falls below an acceptable level. 47 | 48 | The probability of any two hashes colliding is p = 1 - 2ⁿ! / (2ᵏⁿ (2ⁿ - k)!), where n is the number of bits in the hash, and k is the number of items we are hashing. Factorials of this size are hard to compute exactly, so we will instead work with the accurate approximation p = 1 - exp(-k²/2ⁿ⁺¹). 49 | 50 | To find out how many bits of the hash we need to get a certain probability, we can rearrange the formula: n = log₂(-k²/ln(1-p)) - 1. 51 | 52 | Using the estimate that there are 5000 classes in Minecraft, and that we want a probability of 0.001, we get n = 34.54 bits. 53 | From this we find that we need 7.34 base-26 digits to achieve this probability.Using an estimate of 40,000 fields/methods in Minecraft, and the same target probability, you can work out in a similar way that 7.62 digits is appropriate. 54 | 55 | If we got an entirely new set of mappings every snapshot, and snapshots were to occur on average once per week, then we would expect to get a class/field/method name collision about once every 192 years. But we don't get an entirely new set of mappings every snapshot, in reality the mappings are mostly the same from snapshot to snapshot, so it will take orders of magnitude longer than 192 years until we actually expect to run into any collision. 56 | 57 | ### Compatibility with Fabric 58 | 59 | - Fabric mods will be remapped from intermediary to hashed Mojmap when they are loaded. 60 | - Quilt Loader's mapping resolver will recognize the `intermediary` channel when Fabric mods are loaded, and remap it to the current runtime mappings (`hashed` in production). Quilt Loader will also recognize the `hashed` channel. 61 | - The buildscript in Quilt's fork of Yarn will be updated to generate hashed Mojmap to Yarn mappings when built. When we start accepting PRs to our fork, the repository itself will be changed from using intermediary to hashed Mojmap. If necessary, a tool will be written to merge upstream from that point on. 62 | 63 | ## Drawbacks 64 | 65 | - Hashed Mojmap names are more likely to change than intermediary, although not by as much as popularly believed. 66 | - After applying the aforementioned corrections for package names, we found that Mojmap class names are twice as likely to change when the intermediary doesn't, than intermediary changes when Mojmap doesn't. 67 | - However, after manually checking the nature of these renames, it turned out that some of them were renamed to reflect a change in the purpose of the class, but the intermediary still matched because the classes were most similar. It is difficult to quantify exactly how common this is, as it requires going through all renamed classes manually. 68 | - It is possible that lambda methods change when intermediary doesn't, although this is not as likely in comparison to intermediary as popularly believed. 69 | - Lambda methods are indeed included in Mojmap, and are in the javac format `lambda$enclosingMethod$index`. 70 | - This name will only change if the enclosing method name changes, or lambdas are inserted before that lambda. Other lambdas being inserted into this method is also likely to fool Matcher and therefore change the intermediary. 71 | - Not much effort is put into matching lambda methods that aren't auto-matched anyway. Lambda methods have been known to change intermediary with even the tiniest change in their content. 72 | 73 | ## Rationale and Alternatives 74 | 75 | - We could continue using Fabric intermediary. 76 | - The problems mentioned in the "Motivation" section would then persist. 77 | - We would miss our opportunity to change from intermediary without breaking mods, and would have to break mods if we decide to change in the future. 78 | - We could fork intermediary and diverge but otherwise keep it the same. 79 | - Does not improve the maintenance burden of updating to the latest Minecraft version. 80 | - Does not handle forks of Minecraft versions (e.g. April fools snapshots) very well. 81 | - We could auto-match using Mojmap using the aforementioned techniques to minimize the chance of bad renames. 82 | - Still does not handle forks of Minecraft versions (e.g. April fools snapshots) very well. 83 | - Requires a server to be online to run the update. If ever Minecraft modding becomes unpopular it is better to have a decentralized approach that will work forever. 84 | - We could use Mojmap directly in place of intermediary. 85 | - Taints Yarn contributors when seen in stack traces and unmapped code. 86 | - More likely to break mods than hashed Mojmap because no package name correction has been done. 87 | 88 | ## Prior Art 89 | 90 | Forge, Sponge and soon Paper have chosen to use Mojmap directly. Unlike those projects, we have our own thriving, and official, mapping set to cater to, Yarn, and we cannot allow Yarn contributors to be tainted. 91 | 92 | ## Unresolved Questions 93 | 94 | 95 | ## Expected Response 96 | 97 | This approach has so far been controversial, but there has been much support for it too. Discussion will take place in the PR comments of this RFC, with a poll after both sides have had enough time to put forward their arguments. 98 | 99 | Remember one of the reasons Quilt was founded: 100 | 101 | > Faster Iteration & Experimentation - The Quilt project aims to fail fast. We would rather try something and fix it then spend countless months debating whether to move forward with it in the first place. 102 | 103 | -------------------------------------------------------------------------------- /rfc/0032-loader-plugins.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | This RFC describes plugins for the Quilt mod loader, and aims to describe the 4 | purpose(s), functionality, and implications of such a system. At a high level, 5 | loader plugins will allow developers to control the mod loading process itself, 6 | giving them access to powerful tools for defining, loading, and removing mods. 7 | 8 | 9 | # Motivation 10 | 11 | One of the most common barriers of entry for new mod users is having to download 12 | and install APIs and libraries in addition to the mods they want to use. Adding a 13 | way for Quilt Loader to fetch dependencies dynamically will help ease this 14 | headache and make Quilt a more appealing option for new mod users. Plugins will 15 | allow us to add such behavior dynamically when required, while allowing the 16 | behavior to be disabled if a user does not want or need it. 17 | 18 | Plugins will allow third-party libraries to define complex mod resolution behavior 19 | such as [allowing mods to declare "API" classes that other mods can declare implementations for](https://github.com/FabricMC/fabric-loader/issues/343). 20 | 21 | Projects such as [PatchworkMC](https://patchworkmc.net/) and [Sponge](https://www.spongepowered.org/) will be able to run non-Quilt mods ([Forge](https://forums.minecraftforge.net/) and Sponge mods, respectively) on top of the Quilt platform by 22 | performing transformations during the mod loading process. 23 | 24 | Once CHASM is implemented as a universal standard for bytecode transformations 25 | across Quilt, this system will allow us to remove the special case code for Mixin 26 | and access wideners and reimplement those as loader plugins instead. This will make 27 | developing third-party libraries that modify bytecode in unique and interesting 28 | ways possible. 29 | 30 | Loader plugins could also be used to [add mod containers for mods that don't do anything](https://github.com/FabricMC/fabric-loader/issues/175), although a 31 | better system for that will likely be implemented separately into Loader itself. 32 | 33 | A loader plugin could be developed to load mods from instance-specific folders instead of the single shared mods folder. 34 | 35 | By breaking parts of the mod loading process into various projects, we can keep 36 | each repository focused on its own specific mission. This will allow for more 37 | finely grained separation of responsibility. 38 | 39 | 40 | # Explanation 41 | 42 | The addition of Quilt Loader plugins will make Quilt Loader a plugin loader, not 43 | a traditional mod loader. Much of the existing mod loading behavior will be 44 | moved to one or more first-party loader plugins that are installed by default, 45 | keeping only the bare minimum amount of code required for mod resolving in Loader 46 | proper. Loader plugins will be capable of effecting the mod loading process by 47 | adding mods and even adding other plugins. Plugins will also have the ability to 48 | open/create UI elements which can be used for as simple a thing as prompting the 49 | user for confirmation, or as complex of one as writing a full-scale mod launcher 50 | as a loader plugin. 51 | 52 | ## Application 53 | Loader plugins are initially added from the classpath, allowing default loader 54 | plugins for an instance to be added via the profile json. All plugins are then 55 | applied in cycles. During each cycle, the following things happen: 56 | - Each plugin is given a chance to add any plugin candidates 57 | - Each new plugin added this way is given a chance to add any plugin candidates. 58 | Rinse and repeat. 59 | - Each plugin is given a chance to add any required or tentative mod candidates, 60 | rules, or options 61 | - Quilt Loader will evaluate the sat4j tree 62 | - Each plugin will be given a chance to claim unsatisfied rules for resolution 63 | - Each plugins resolvers will be run sequentially 64 | 65 | If any changes to the mod set have taken place during a given cycle, another cycle 66 | will be run. Otherwise, the game will either launch or crash, depending on whether 67 | or not all rules have been satisfied. 68 | 69 | 70 | ## API Surface 71 | 72 | Below is a tentative plan of what the surface level API classes might look like. 73 | Everything here is subject (and likely) to change, but helps provide a visual 74 | idea of how developers might use this feature down the road. 75 | 76 |
77 | QuiltPluginContext 78 | 79 | ```java 80 | /** 81 | * Passed to loader plugins to define what actions they are able to take. 82 | */ 83 | public sealed interface QuiltPluginContext permits QuiltPluginContextImpl { 84 | /** 85 | * The plugin that this context is for. This method is useless, it just indicates that every other method here has an 86 | * implicit paramater of "The Loader Plugin" for the UI / logging to use in some way 87 | */ 88 | QuiltLoaderPlugin plugin(); 89 | 90 | void addCandidate(ModCandidate candidate); 91 | 92 | void addCandidate(PluginCandidate candidate); 93 | 94 | /** 95 | * Adds a tentative mod candidate which indicates that downloading / fetching a new mod will fix a rule somewhere. 96 | * This tentative mod won't be kept around to the next cycle - instead the resolver is called to actually download 97 | * the mod if {@link QuiltLoaderPlugin#canResolve} returns true after each plugin has been checked. 98 | * 99 | * @param resolver a future that will resolve this candidate, with value of null if it succeeds and an error message 100 | if it fails 101 | */ 102 | void addTentativeCandidate(String group, String modId, Version version, Future<@Nullable String> resolver); 103 | 104 | /** 105 | * Adds a rule to the current solver. 106 | */ 107 | void addRule(Rule rule); 108 | 109 | /** 110 | * Adds a LoadOption to the current solver. All existing rules will have Rule#onLoadOptionAdded called, and all plugins 111 | * will have ILoaderPlugin#onLoadOptionAdded called. 112 | * 113 | * If this is an ITentativeLoadOption then it will be removed at the end of the cycle, and handled by whatever plugin 114 | * added it. 115 | */ 116 | void addOption(LoadOption option); 117 | 118 | /** 119 | * Blames a single rule, causing loader to temporarily remove a single rule to move on to the next problem. 120 | * If another plugin is able to fix the error (by returning true from handleOtherErrors or related methods) then this call will have no affect. 121 | * 122 | * @param errorDisplayer Only one will be chosen in order to describe the error in the main error gui, using whatever UI abstraction system we end up using. 123 | * @throws IllegalStateException if this isn't called during a call to {@link QuiltLoaderPlugin#handleOtherErrors(args)}, 124 | */ 125 | void blameRule(Rule rule, Runnable errorDisplayer); 126 | 127 | /** 128 | * Gets all currently present load options for mods with the given ID. 129 | * If none are present, returns an empty set. 130 | */ 131 | Set getModLoadOptions(String modId); 132 | 133 | /** 134 | * Gets all currently present load options. 135 | */ 136 | Map> getModLoadOptions(); 137 | 138 | /** 139 | * Gets all currently present rules. 140 | */ 141 | Set getRules(); 142 | } 143 | ``` 144 |
145 | 146 |
147 | QuiltLoaderPlugin 148 | 149 | ```java 150 | /** 151 | * @param the types of resolver this plugin can resolve 152 | */ 153 | interface QuiltLoaderPlugin> { 154 | /** 155 | * Called once per cycle as the first action in the cycle. 156 | * 157 | * This is where mods can be added with {@link QuiltPluginContext#addCandidate} and 158 | * {@link QuiltPluginContext#addTentativeCandidate}. 159 | */ 160 | default void run(QuiltPluginContext context) {} 161 | 162 | /** 163 | * Called once per cycle after the sat4j solving has finished, but before any resolvers are run. 164 | * 165 | * Should NOT invoke the resolvers. 166 | * 167 | * @return true if all of the resolvers can be called, false otherwise 168 | */ 169 | default boolean canResolve(List resolvers) { 170 | return false; 171 | } 172 | 173 | /** 174 | * Called if loader can't simplify this error down into any of the other error handling methods. 175 | * @return True if this plugin did something which will solve / change the error in future, 176 | * and so loader won't ask any other plugins to solve this. 177 | * You are expected to call `QuiltPluginContext.blameRule(Rule... rules)` if you can't actually fix the issue, but can identify a rule to be removed. If no plugin can identify a rule to be removed then loader will remove a random rule in order to move on to the next error 178 | * If this returns false then no rules will be removed, and instead loader will assume that 179 | * the error has been handled in some other way. (and it will promptly crash if you haven't) 180 | */ 181 | default boolean handleOtherErrors(QuiltPluginContext context, List errorChain) { return false; } 182 | 183 | /** 184 | * @param dep The dependency which is missing completely. If you can find a valid source for this then you should add 185 | * it with {@link QuiltContext#addTentativeCandidate()} 186 | * @return True if this plugin did something which will solve / change the error in future, 187 | * and so loader won't ask any other plugins to solve this. 188 | * You are expected to call `QuiltPluginContext.blameRule(Rule... rules)` if you can't actually fix the issue, but can identify a rule to be removed. If no plugin can identify a rule to be removed then loader will remove a random rule in order to move on to the next error 189 | * If this returns false then no rules will be removed, and instead loader will assume that 190 | * the error has been handled in some other way. (and it will promptly crash if you haven't) 191 | */ 192 | default boolean handleMissingDependencyError(QuiltPluginContext context, ModDependencyRule dep, List fullErrorChain) { 193 | return handleOtherErrors(ctx, fullErrorChain); 194 | } 195 | 196 | /** 197 | * Called whenever a new LoadOption is added, for plugins to add Rules based on this. (For example the default plugin 198 | * creates rules based on the dependencies and breaks sections of the quilt.mod.json if this option is a 199 | * {@link MainModLoadOption}). 200 | *

201 | * Most plugins are not expected to implement this. 202 | */ 203 | default void onLoadOptionAdded(QuiltPluginContext context, LoadOption option) {} 204 | } 205 | ``` 206 |

207 | 208 |
209 | ITentativeLoadOption 210 | 211 | ```java 212 | /** 213 | * {@link LoadOption}s can implement this if they must be processed at the end of the cycle in order to either be 214 | * added as a normal LoadOption, or removed automatically. 215 | */ 216 | public interface ITentativeLoadOption { 217 | 218 | } 219 | ``` 220 |
221 | 222 |
223 | LoadOption 224 | 225 | ```java 226 | /** 227 | * A boolean option, which quilt loader will resolve down to "true" or "false" according to the {@link Rule}s added by plugins. 228 | */ 229 | public abstract class LoadOption { 230 | 231 | } 232 | ``` 233 |
234 | 235 |
236 | ModDependencyRule 237 | 238 | ```java 239 | sealed abstract class ModDependencyRule extends Rule /* implemented by quilt */ { 240 | abstract ModCandidate from(); 241 | 242 | abstract VersionLimits versions(); 243 | 244 | abstract @Nullable ModDependencyRule unless(); 245 | 246 | abstract List valid(); 247 | 248 | abstract List invalid(); 249 | } 250 | ``` 251 |
252 | 253 |
254 | Rule 255 | 256 | ```java 257 | /** 258 | * A boolean expression, which controls the links between {@link LoadOption}s 259 | */ 260 | public abstract class Rule { 261 | /** 262 | * Invoked for every Rule by quilt-loader whenever a load option is added, in order to update this rule. 263 | * For example {@link ModDependencyRule} uses this to add ModLoadOption to it's valid and invalid lists. 264 | */ 265 | public abstract void onLoadOptionAdded(LoadOption option); 266 | 267 | /** 268 | * Invoked when tentative LoadOptions are removed at the end of a cycle. 269 | */ 270 | public abstract void onLoadOptionRemoved(LoadOption option); 271 | 272 | /** 273 | * Called at the start of each cycle to encode this rule in sat4j. 274 | */ 275 | public abstract void define(IRuleDefiner definer); 276 | } 277 | ``` 278 |
279 | 280 | 281 | # Drawbacks 282 | 283 | All existing behavior can be implemented using loader plugins. As such, the largest 284 | drawback may be the increased scope for the Quilt project as a whole, as we will no 285 | longer be limited to mods specifically. This is less of a drawback and more of an 286 | organizational change that needs to be considered moving forward. 287 | 288 | Another drawback is the potential confusion of end users that may stem from a more 289 | complicated mod loading process. If a plugin fails to provide a required mod which 290 | therefore causes a crash, it's possible that users may receive error messages that 291 | further confuse them rather than cause clarity. Careful consideration will have to 292 | be put into the development of Quilt's official loader plugins to ensure that each 293 | of our loader plugins emits thorough and helpful error messages upon failure. 294 | 295 | 296 | # Rationale and Alternatives 297 | 298 | While we could continue with the current status quo of loading mods from the mods 299 | folder and only the mods folder, this is a rigid and outdated way of doing so that 300 | does not allow for iteration and innovation. 301 | 302 | If loader plugins are not implemented, we would have a very hard time 303 | differentiating ourselves from other mod loaders. Plugins will allow both us and 304 | the community itself to add features to Quilt loader easily, making it much easier 305 | for innovation in where mods come from and how they are loaded. 306 | 307 | 308 | # Prior Art 309 | 310 | If this has been done before by some other project, explain it here. This could 311 | be positive or negative. Discuss what worked well for them and what didn't. 312 | 313 | Similar projects have been looked at by others in the past: 314 | - FabLabs very briefly explored this concept [here](https://github.com/FabLabsMC/fabric-loader/tree/feature/modproviders). 315 | - [@Chocohead](https://github.com/Chocohead) has implemented [loading extra mods alongside Fabric Loader](https://github.com/Chocohead/Modjam/blob/master/src/com/chocohead/sm/loader/PreLoader.java), but not as actual Fabric mods. 316 | 317 | None of them have been implemented into the mod loader itself, and as such this is 318 | the first project to allow such liberal changes to the mod loading process. 319 | 320 | 321 | # Unresolved Questions 322 | 323 | Before loader plugins can be considered fully implemented, CHASM will need to be 324 | functional so that all bytecode modifications can go through a single source of 325 | truth. 326 | 327 | For the purposes of this RFC, I did not go into the drawbacks of 328 | dependency downloading specifically, as this RFC is interested more generally 329 | in the idea of loader plugins as a whole. How dependency downloading is implemented 330 | and other concerns regarding that will take place at a later date, in another RFC. 331 | 332 | 333 | # Expected Response 334 | 335 | Loader plugins have been one of the earliest features Quilt promised to deliver. As 336 | such, I expect the community will largely be excited to see this feature 337 | implemented. Projects such as [Bundle Installer](https://github.com/FoundationGames/Bundle-Installer) will be able to make use of loader plugins right from day one, and 338 | I expect that we'll see a lot of similar projects that aim to make the mod 339 | installation process as easy as possible for end users. 340 | -------------------------------------------------------------------------------- /rfc/0033-quilt-mappings-and-clean-room.md: -------------------------------------------------------------------------------- 1 | # Quilt Mappings and the Cleanroom 2 | ## Summary 3 | 4 | This RFC proposes a new approach to mappings within the Quilt project, specifically regarding Yarn's cleanroom approach, licensing, and related enforcement in Quilt community spaces. 5 | 6 | With Mojang's mappings (Mojmap) quickly becoming the de-facto mappings standard throughout the modding ecosystem, and MCP mappings effectively dead and gone, it no longer makes sense to maintain the purity of Yarn. This is especially true given the original motivations behind Yarn's cleanroom approach, the questionably impure approach taken by some of the upstream maintainers, and the lack of formal accountability for its contributors. 7 | 8 | This RFC proposes that non-Yarn mappings should be allowed to be referenced in all Quilt community and development spaces, with the goal of creating a more inclusive support ecosystem and raising the quality of Quilt's fork of Yarn. 9 | 10 | As Quilt's Yarn fork will be significantly different from upstream Yarn, this RFC also proposes changing its name to Quilt Mappings (QM). 11 | 12 | Any discussions related to migrating existing Quilt projects to other mappings standards are out of scope of this RFC, and there is - as of this writing - no intention to do so. 13 | 14 | ## Motivation 15 | 16 | In order to understand the motivation for this RFC, it's important to look at how we got here. A lot has changed since Yarn was conceived in 2016, and the approach it takes isn't really relevant in today's modding landscape. 17 | 18 | ### Background 19 | 20 | Yarn was originally created on August 12, 2016. It was created for a project called Open Mod Loader, the first iteration of what would be known as Fabric. 21 | 22 | It would remain in relative obscurity until October of 2018, when Yarn began tracking early snapshots for Minecraft 1.14. 23 | 24 | ### Rift 25 | 26 | During the 1.13 development cycle, Forge chose to rewrite most of their scaffolding, and a stable Forge build didn't appear until Minecraft 1.14. Rift was created in response to this, as a lightweight mod loader that could do basic coremodding on Minecraft 1.13. 27 | 28 | However, Rift made use of parts of the Forge toolchain without permission. Forge declined to grant this permission to them after the fact, and Rift-related discussions were effectively banned in most modding-related communities. 29 | 30 | ### Yarn's Motivation 31 | 32 | Due to the strict licensing of some parts of the Forge toolchain at the time, Fabric needed to avoid making use of Forge projects such as MCP, and thus avoid making the same mistakes that Rift did. In order to achieve this, Yarn was licensed under the [Creative Commons Zero License](https://creativecommons.org/share-your-work/public-domain/cc0/) (CC0), a public domain dedication. 33 | 34 | Additionally, in order to protect against claims of stealing from other projects, all names in Yarn needed to be original contributions. For this reason, Yarn needed to take a cleanroom approach, rejecting contributions that added names from other mappings projects, and banning discussions of names from non-CC0 projects in related community spaces. 35 | 36 | ### Issues With the Cleanroom 37 | 38 | While discussing how Quilt's approach to mappings should work, the Quilt Mappings Team has made the following observations: 39 | 40 | * Almost everyone that ended up contributing to Fabric and Yarn were either switching from other projects or had minor exposure to them, generally Spigot or Forge, so they had been exposed in great amounts to strictly licensed mappings. 41 | * Regardless of who contributed a name, the CC0's warranty and infringement disclaimers mean that Quilt would be fully responsible in the event of DMCA on our mappings. 42 | * Some Yarn contributors have been known to be working with other mappings projects, either in their own mods or directly, while remaining active Yarn contributors - even with video evidence, in some cases. Since Quilt does not have the time or resources to prove each name given by these contributors is unique and original, the option that would be most honest to our users is to declare that some names have uncertain origins, and may carry legal risk. 43 | * Some Yarn names are lifted directly from Mojmap through the use of string constants. Quilt does not have a license from Mojang to use these constants, so they would fall under the Minecraft EULA, which is stricter than the CC0 and infringes on Mojang's copyright. 44 | 45 | For these reasons, the Quilt Mappings Team has concluded that it's impossible to say with absolute certainty that all Yarn names are unique, and not inspired by (or copied from) other mappings projects. This breaks down the idea of the cleanroom that Yarn has tried to build, and is the main reason that the Quilt Mappings Team has decided to remove the cleanroom requirement. 46 | 47 | This does not break the CC0 license as mappings owned by other parties, Mojang or MCP for instance, are allowed to be part of the set. CC0 has a disclaimer that content might be originally licensed under a more restrictive license, such as ZLib or Mojang's license, and says to use at your own risk. 48 | 49 | The CC0 FAQ also supports this claim, and it has a whole section explaining similar situations: 50 | > **How can I be sure that I have all the rights I need to use the work?** 51 | > 52 | > CC0 contains a disclaimer of warranties just like our licenses, so there is no assurance whatsoever that the affirmer (the person who applied CC0 to the work) has all the necessary rights to grant permission to use the CC0’d work. The person applying CC0 to their work is not guaranteeing anything about it, including whether the person owns the copyright or has cleared any uses of third-party content that the work may be based on or incorporate. If you are in doubt, then we strongly recommend you not use the work until you have taken all the steps and precautions you feel you need to before doing so, which may include contacting the person who applied CC0 to the work and consulting legal counsel. 53 | 54 | CC0 only waves Quilt's rights to content, not someone else's like Mojang's. This was also an issue that Yarn faced, see https://fabricmc.net/2020/06/23/dmca.html, but should not be an issue for specific modders as Mojang or MCP have not made a practice of suing modders over the use of their names in code. 55 | 56 | It's also clear that Mojang feels that their mappings should be used in this way - or at least have no wish to prevent it - given that they haven't intervened in other projects that use it in a similar way. 57 | 58 | It's become abundantly clear that Yarn's cleanroom isn't very clean, and that it doesn't serve any real purpose in today's modding ecosystem. 59 | 60 | ### Changes to the Ecosystem 61 | 62 | As mentioned earlier, a lot has changed in the time since Yarn was conceived: 63 | 64 | * Most other modloader projects are using Mojmap, or something layered on top of it 65 | * MCP has been retroactively relicensed to the zlib license, and is no longer being maintained as an isolated mappings project 66 | * It's become clear that Microsoft has many other ways to kill off modloader projects, even though it doesn't have any discernable motivation to do so - and regardless of whether they'd be in the right to do so, it's unlikely that anyone would be able or willing to fund a court case in defense 67 | 68 | ### Expected Positive Outcomes 69 | 70 | The current rules needed to maintain the cleanroom have to be rather stringent in order to appear effective. We expect that dropping them could benefit the Quilt project in a few ways: 71 | 72 | * Improved cooperation between modding projects - as other modloaders use different mappings, contributors who work on more than just Quilt-related projects would be considered "tainted" under the current rules. Dropping the cleanroom could increase the number of contributors both coming from other projects to help on Quilt, and coming from Quilt to collaborate on more ambitious cross-loader initiatives. 73 | * Improved help in community spaces - allowing other mappings will allow developers coming from other mod loaders to have a more welcoming experience as they would not have to learn a new mapping set just to receive help. 74 | * Improved mappings - some code constructs can be currently difficult to name without knowing the developers' intent. This challenge has been heightened with the release of the fields behind Minecraft's inlined constants. Being able to cross-reference names with Mojang Mappings could improve the quality and coverage of Quilt's own mappings when it comes to said constructs. 75 | ### Conclusion 76 | 77 | In conclusion, the current approach to Yarn doesn't really make sense given the modern modding ecosystem. While this RFC has no direct bearing on upstream Yarn, the Quilt Project feels that this RFC is the best way to move forward with Quilt Mappings. 78 | 79 | ## Explanation 80 | 81 | Should this RFC be approved: 82 | 83 | * Quilt's fork of Yarn will be renamed to "Quilt Mappings" (QM) 84 | * All restrictions on referencing mappings projects (other than Quilt Mappings) within Quilt's community and development spaces will be lifted 85 | * A file named `ATTRIBUTION.md` will be created in the Quilt Mappings repository, which will properly attribute both the MCP project and Mojang for any names that may be inspired by or attributed to those projects, with the possibility of adding more as required 86 | * The Quilt Mappings project will provide additional attribution to other mappings projects and providers (including MCP and Mojang) as required, which may also include changes to Quilt's toolchain 87 | * The Quilt Mappings repository will have its current restrictions regarding mentions of other mappings projects lifted, and replaced with a requirement that contributors may only reference other mappings projects that are public domain, licensed under the CC0, or attributed in the `ATTRIBUTION.md` file 88 | * The other Quilt Mappings contribution requirements, such as quality of names or conventions and standards will not be changed by this RFC 89 | * This will not affect Quilt's other plans going forward, and everything else will continue as normal - including the planned move from intermediary to Hashed Mojmap. 90 | 91 | These changes are likely to happen in many steps, but it's expected that they will be made in quick succession. 92 | 93 | ## Drawbacks 94 | 95 | ### Community Confusion 96 | 97 | It's possible that giving and receiving support in Quilt community spaces may be complicated somewhat, as different people will be familiar with different types of mappings. 98 | 99 | However, this issue already exists with the cleanroom approach in a sense, as people that aren't used to Yarn currently already have to find a way to translate names from other mappings to Yarn in order to get support in Quilt community spaces. 100 | 101 | This could be mitigated by adding mappings translation commands to Cozy, the Quilt Discord bot. 102 | 103 | ### Fragmentation 104 | 105 | By removing restrictions on which mappings projects may be discussed in community and development spaces, it's likely that more projects will switch to Mojmap - as they're now free to do so and still request help in official Quilt spaces. It's possible that this could create a split in Quilt's developer community, where developers making use of one set of mappings may find it difficult to start contributing to projects that use others. 106 | 107 | This could be mitigated somewhat by providing a recommendation that new projects built exclusively for Quilt make use of Quilt Mappings, with projects that need to support multiple modloaders using Mojmap instead. 108 | 109 | ### Reduced Quality of Quilt Mappings Names 110 | 111 | Although unlikely, it's possible that contributors to the Quilt Mappings project may believe that Mojang's names are the best in all cases, and attempt to contribute those names directly to QM because they're what Mojang uses. These types of contributions would significantly lower the quality of the names included in the Quilt Mappings project. 112 | 113 | This can be mitigated by continuing the current comprehensive review process - reviewing names based upon their quality alone, and not using origin-based arguments as a measure of that quality. 114 | -------------------------------------------------------------------------------- /rfc/0061-sponsorships.md: -------------------------------------------------------------------------------- 1 | # Sponsorship Guidelines 2 | 3 | ## Summary 4 | 5 | This RFC outlines the procedure for applying for, accepting, running, and terminating sponsorships that the project obtains. 6 | 7 | ## Motivation 8 | 9 | As an open-source project, there are many opportunities for us to be provided with funds and/or free or discounted services, sometimes in exchange for advertisement or endorsement. Since we have access to limited funds, we should be taking advantage of this whenever we can, however, there are many sponsorships that we would not be able to accept in good conscience, either due to deceptive marketing, dishonest practices, or some other reason. Because of this, we need a clearly defined system that allows us to use and possibly endorse sponsored products in a way that is transparent, ethical, and in good faith. 10 | 11 | ## Explanation 12 | 13 | This RFC provides a set of procedures for applying for, accepting, and terminating sponsorships, as well as guidelines for determining if a sponsor is suitable, and measures to take to ensure we remain transparent with and trusted by the community. 14 | 15 | ### Glossary of Terms 16 | 17 | - Endorsed Sponsorship: A sponsorship agreement that requires an endorsement from us, such as a mention on our website, for example, Starchild Systems hosting and managing our forum. 18 | - Non-Endorsed Sponsorship: A sponsorship that does not require an endorsement from us, for example, our free 1Password Teams account. 19 | - Financial Sponsorship: Sponsorships that provide direct financial contributions to the project. 20 | - Non-Financial Sponsorship: Sponsorships that do not provide direct financial contributions to the project. They may provide something else, like tooling or server space. 21 | 22 | ### Sponsor Guidelines 23 | 24 | In order to provide a sponsorship to the project, sponsors should meet the following requirements. These are not hard requirements, as we understand that there is generally more nuance in the circumstances surrounding a given practice than can be expressed in a few bullet-points, and being too strict in our requirements could prevent us from accepting sponsorships we are otherwise comfortable with. It is more important (though still not required) that Endorsed Sponsors meet these guidelines, as people may discover and support them through us, and we don't want to be the cause of an unsound product or company receiving support that it does not deserve. 25 | 26 | Sponsors **should**: 27 | - Provide a high-quality product or service at a fair and competitive price. 28 | - Market their product or service in a way that is transparent and honest. 29 | 30 | Sponsors **should not**: 31 | - Use, promote or otherwise endorse technology that is clearly being used in a harmful or anti-consumer way. 32 | - Have a recent, reliably-sourced history of discriminating against minorities or endorsing those who do that has not been clearly and successfully addressed. 33 | - Have a recent, verified history of serious anti-consumer practices that have not been clearly and successfully addressed. 34 | - Have a recent history of employee mistreatment, that has not been clearly and successfully addressed 35 | - Conduct business in a way that is unsustainable or especially harmful to the environment. 36 | 37 | ### Measures taken to ensure transparency 38 | 39 | - We will maintain a list of all endorsed and non-endorsed sponsorships that the project holds, both past and present, on our website. 40 | - We will have a Sponsorship section on our forum, where our community can voice concerns about current and future sponsors, suggest sponsorships we might like to consider, and request information about certain sponsorships. 41 | - All proceeds from financial sponsorships must be paid directly into our [Open Collective account](https://opencollective.com/quiltmc) 42 | 43 | ### Validation Process for Endorsed Sponsorships 44 | 45 | If we plan to either apply for or accept an endorsed sponsorship that meets the Base Requirements, they must go through a process of validation, to help maintain trust with our community. 46 | 47 | The Outreach Team will create a post on the Sponsorship section of the forum, explaining our intention to endorse a given sponsor, and the broad terms of the sponsorship agreement. We can then discuss with members of the community the terms of the agreement, and whether they think it would be appropriate for us to apply for or accept the sponsorship. Based on their feedback, we can then decide whether to proceed with applying for or accepting the sponsorship, though if the sponsorship was offered to us by a sponsor, we should always discuss negative points with them before denying a sponsorship. 48 | 49 | ### Process for Applying for or Accepting a sponsorship 50 | 51 | If a sponsorship is suggested, either by a team member or community member, or offered to us by the sponsor themselves, the team(s) that it would affect will discuss if it would be useful to them, and if there are any preferable alternatives (for example, a development tool would be discussed by the development teams, a moderation tool would be discussed by the moderation team, etc.). In the case of financial sponsorships, the Admin Board should take on the role of the affected team, with input from the rest of the Quilt teams. If it is decided that the sponsorship would be beneficial to the project and its terms are acceptable, it will be briefly discussed internally to make sure no-one has any immediate concerns, and then we will proceed to the Validation Process, if applicable. 52 | 53 | If the Validation Process is successful, the project can then proceed to apply for or accept the sponsorship. Preferably, this should be the job of the Outreach Team (in accordance with their role of "managing relations with other platforms and communities outside of a moderation context"), however, it may be necessary for a member of the Admin Board to apply if the sponsor requires it. 54 | 55 | ### Sponsor Concerns 56 | 57 | If a member of the team or community has a concern about a sponsor, they can bring it up in internal channels (or by using Discord ModMail/Discourse Moderator PMs in the case of community members), where the team can discuss it. If the concern is not immediately deemed invalid or extremely clear-cut, and we have contact with the sponsor, then the Outreach Team (or sometimes the Admin Board) should attempt to reach out to them for clarification before making a decision. If the sponsor has a satisfactory explanation to quell the concern, we can inform the reporter, and make a post on the forum if the concern is widespread and the sponsor gives us permission. If they do not, we can terminate the sponsorship. 58 | 59 | ### Terminating a sponsorship 60 | 61 | At some point, it may become necessary to terminate a sponsorship agreement, either if concerns about the sponsor come to light, or if they are simply no longer needed. 62 | 63 | When we terminate a sponsorship, we will make a post on the forum acknowledging the termination, in order to keep the community informed. If we're terminating a sponsorship because we no longer need it, the post doesn't have to be long, but if it is due to a concern about a sponsor, we should include the concern and how we determined it to be valid. It may occasionally be that the details of a concern that resulted in the termination of the sponsorship may be too sensitive to post publically, but in this case we should still ensure that it is documented internally to ensure that we do not enter into a similar sponsorship in the future without ensuring that the concern has been addressed. 64 | 65 | ## Drawbacks 66 | 67 | This process could extend the already significant time that it would take to apply for or accept a sponsorship that would benefit the project. It also might mean that we're unable to accept a sponsorship that would significantly benefit the project if it does not pass verification, and this would be to the project's detriment. 68 | 69 | ## Rationale and Alternatives 70 | 71 | Quilt is not designed to be a financially-driven project, and it is common knowledge that introducing money into open-source without extreme care and caution can lead to corruption. Unfortunately, by necessity we have several costs which sponsors could offset, and have need of tools that would be inaccessible to us without a sponsorship (e.g, 1Password). As well as this, endorsing disreputable companies as part of a sponsorship may undermine the trust that the community has in us, and so we need formal procedures that involve the community as much as we can to help ensure this doesn't happen. That said, here are some alternatives: 72 | 73 | - We could not involve the community in the decision-making process. This would make it faster and possibly avoid drama in the short-term, however, not involving our community in such important decisions may undermine their trust in us and contradict Quilt's goal to be a caring, community-driven project. 74 | - We could have the sponsorship discussions on Discord, where there is higher traffic, especially if the forum channels are implemented. However, the forum is more open than Discord, and more reliable and permanent in the long term, since we control it. In addition, forums are more suited to long-form discussions, like those about sponsorships would likely be. The issue of the forum's low traffic compared to Discord could be offset by posting new forum posts to Discord via a webhook. 75 | - We could forgo the base guidelines and validation process, as it could be argued that people can tell the difference between a sponsorship and a full endorsement. However, the fact that sponsorships have value at all is evidence that this is not universally true. If we endorse a bad sponsor, we could be responsible for people discovering and supporting it, and endorsing unethical companies could give our critics more ammunition against us. 76 | - We could require non-endorsed sponsorships to undergo the validation process, but since we're not endorsing them and using a paid service for free, we're really just costing them money, and people won't discover and support them through our endorsement, since we're not endorsing them. 77 | - We could turn the base guidelines into hard requirements for Endorsed Sponsors, but they do not take into account the fact that some sponsors are more valuable to us than others (An AWS sponsorship would be more valuable than a Minecraft server host, for example), and that there is often more nuance in the policies and practices of a business then can be expressed in a few bullet points. Furthermore, since all sponsors are validated by the community, that should be sufficient to stop any sponsors we feel uncomfortable working with from being accepted/applied for. 78 | - We could post non-sensitive concerns about sponsors on the forum, and this would be a more open system that would allow the entire community to participate in the discussion. However, it runs the risk of people publically posting concerns that end up having no basis, and other people acting on those concerns, needlessly hurting the sponsor and possibly affecting our relationship with them. 79 | 80 | ## Prior Art 81 | 82 | Linus Media Group, the company behind the Linus Tech Tips and Techquickie YouTube channels (among others), have a [Sponsor Discussion section](https://linustechtips.com/forum/98-lmg-sponsor-discussion/) on their forum, where they ask their community for their opinions on potential sponsorships, to make sure they're only endorsing products and services which their audience holds in high regard, and recent examples of the success of this at the time of writing include blocking the sponsorship of [Ladder Life](https://linustechtips.com/topic/1429149-thoughts-on-ladder-life/) and [Geologie](https://linustechtips.com/topic/1424178-thoughts-on-geologie/), and approving sponsorships from XSplit. 83 | 84 | 85 | ## Unresolved Questions 86 | 87 | How will we internally document sensitive concerns? Who should have access to them? 88 | -------------------------------------------------------------------------------- /rfc/README.MD: -------------------------------------------------------------------------------- 1 | # RFCs 2 | This folder is for general RFCs that don't fit into the other folders. 3 | An RFC fits here if the following are true: 4 | - It is not in the scope of any other folders 5 | - It is not meant to be updated over time (For example, the RFC may be a high-level description of a major change in how Quilt is developed, such as Hashed Mojmap or CHASM, but will not be kept updated as the feature adapts from RFC to actual implementation). 6 | -------------------------------------------------------------------------------- /specification/0002-quilt.mod.json.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | This document acts as a Request for Comments (RFC) on the topic of how a Quilt mod's metadata should be formatted. Such changes are intended to provide added value for mod developers, library developers, and users alike. 3 | 4 | # Motivation 5 | Since the toolchain is being forked, now is the opportune moment to make large scale changes to many of the systems mod developers use. This RFC describes a more flexible and powerful format for the mod file that defines what a mods definition should look like. 6 | 7 | # Explanation 8 | Below is an outline of all defined keys and values. 9 | 10 | * [schema_version](#the-schema_version-field) — The schemaVersion to be used for reading this file 11 | * [quilt_loader](#the-quilt_loader-field) — Information related to loading the mod 12 | * [group](#the-group-field) — The Maven group id 13 | * [id](#the-id-field) — The mod id 14 | * [provides](#the-provides-field) — Alternative mods provided by this mod 15 | * [version](#the-version-field) — The mods version 16 | * [entrypoints](#the-entrypoints-field) — Collection of entrypoints 17 | * [plugins](#the-plugins-field) — Collection of plugins 18 | * [jars](#the-jars-field) — Array of nested JARs to be loaded 19 | * [language_adapters](#the-language_adapters-field) — Array of language adapters 20 | * [depends](#the-depends-field) — Collection of mod dependencies 21 | * [breaks](#the-breaks-field) — Collection of mods that this mod is incompatible with 22 | * [load_type](#the-load_type-field) — How eagerly to load this mod 23 | * [repositories](#the-repositories-field) — Array of maven repositories 24 | * [intermediate_mappings](#the-intermediate_mappings-field) — The intermediate mappings used 25 | * [metadata](#the-metadata-field) — Extra information about this mod and/or its authors 26 | * [name](#the-name-field) — Human-readable name of this mod 27 | * [description](#the-description-field) — Human-readable description of this mod 28 | * [contributors](#the-contributors-field) — Collection of contributors to this mod 29 | * [contact](#the-contact-field) — Collection of contact information 30 | * [license](#the-license-field) — One or more licenses this project is under 31 | * [icon](#the-icon-field) — The icon or icons associated with this project 32 | * [mixin](#the-mixin-field) — Path(s) to mixin config file(s) 33 | * [access_widener](#the-access_widener-field) — Path(s) to accesswidener file(s) 34 | * [minecraft](#the-minecraft-field) - Minecraft related options 35 | * [environment](#the-environment-field) — What game environments this mod applies to 36 | 37 | ## The `schema_version` field 38 | | Type | Required | 39 | |--------|----------| 40 | | Number | True | 41 | 42 | The quilt mod file schema version to be used for parsing this file. Currently, the only valid version is 1. 43 | 44 | ## The `quilt_loader` field 45 | | Type | Required | 46 | |--------|----------| 47 | | Object | True | 48 | 49 | Information necessary for the mod loading process. 50 | 51 | ### The `group` field 52 | | Type | Required | 53 | |--------|----------| 54 | | String | True | 55 | 56 | A unique identifier for the organization behind or developers of the mod. The group string must match the `^[a-zA-Z0-9-_.]+$` regular expression, and must not begin with the reserved namespace `loader.plugin.` It is recommended, but not required, to follow Maven's [guide to naming conventions](https://maven.apache.org/guides/mini/guide-naming-conventions.html). 57 | 58 | ### The `id` field 59 | | Type | Required | 60 | |--------|----------| 61 | | String | True | 62 | 63 | A unique identifier for the mod or library defined by this file, matching the `^[a-z][a-z0-9-_]{1,63}$` regular expression. Best practice is that mod ID's are in snake_case. 64 | 65 | ### The `provides` field 66 | | Type | Required | 67 | |-------|----------| 68 | | Array | False | 69 | 70 | An array of [ProvidesObject](#provides-objects)s describing other mods/APIs that this package provides. 71 | 72 | ### The `version` field 73 | | Type | Required | 74 | |--------|----------| 75 | | String | True | 76 | 77 | Must conform to the [Semantic Versioning 2.0.0 specification](https://semver.org/). In a development environment, the value `${version}` can be used as a placeholder by quilt-gradle to be replaced on building the resulting JAR. 78 | 79 | ### The `entrypoints` field 80 | | Type | Required | 81 | |--------|----------| 82 | | Object | False | 83 | 84 | A collection of `key: value` pairs, where each key is the type of the entrypoints specified and each values is either a single entrypoint or an array of entrypoints. An entrypoint is an object with the following keys: 85 | * adapter — Language adapter to use for this entrypoint. By default this is `default` and tells loader to parse using the JVM entrypoint notation. 86 | * value — Points to an implementation of the entrypoint. See below for the default JVM notation. 87 | 88 | If an entrypoint does not need to specify a language adapter other than the default language adapter, the entrypoint can be represented simply as the value string instead. 89 | 90 | #### JVM entrypoint notation 91 | 92 | When referring to a class, the [binary name] is used. An example of a binary name is `my.mod.MyClass$Inner`. 93 | 94 | One of the following `value` notations may be used in the JVM notation: 95 | 96 | * Implementation onto a class 97 | * The value must contain a fully qualified binary name to the class. 98 | * Implementing class must extend or implement the entrypoint interface. 99 | * Class must have a no-argument public constructor. 100 | * Example: `example.mod.MainModClass` 101 | * A field inside of a class. 102 | * The value must contain a fully qualified binary name to the class followed by `::` and a field name. 103 | * The field must be static. 104 | * The type of the field must be assignable from the field's class. 105 | * Example: `example.mod.MainModClass::THE_INSTANCE` 106 | * If there is ambiguity with a method's name, an exception will be thrown. 107 | * A method inside of a class. 108 | * The value must contain a fully qualified binary name to the class followed by `::` and a method name. 109 | * The method must be capable to implement the entrypoint type as a method reference. Generally this means classes which are functional interfaces. 110 | * Constructor requirement varies based on the method being static or instance level: 111 | * A static method does not require a public no-argument constructor. 112 | * An instance method requires a public no-argument constructor. 113 | * Example: `example.mod.MainModClass::init` 114 | * If there is ambiguity with a fields's name or other method, an exception will be thrown. 115 | 116 | #### Other notations 117 | 118 | Some language providers may extend the capabilities of the JVM language notation or provide additional notations. 119 | For notation rules for other language adapters, consult the capabilities of the language adapter. 120 | 121 | ### The `plugins` field 122 | | Type | Required | 123 | |--------|----------| 124 | | Array | False | 125 | 126 | An array of loader plugins. A plugin is an object with the following keys: 127 | * adapter — Language adapter to use for this plugin 128 | * value — Points to an implementation of the `LoaderPlugin` interface. Can be in either of the following forms: 129 | * `my.package.MyClass` — A class to be instantiated and used 130 | * `my.package.MyClass::thing` — A static field containing an instance of a `LoaderPlugin` 131 | 132 | If a plugin does not need to specify a language adapter other than the default language adapter, the plugin can be represented simply as the value string instead. 133 | 134 | ### The `jars` field 135 | | Type | Required | 136 | |--------|----------| 137 | | Array | False | 138 | 139 | A list of paths to nested JAR files to load, relative to the root directory inside of the mods JAR. 140 | 141 | ### The `language_adapters` field 142 | | Type | Required | 143 | |--------|----------| 144 | | Object | False | 145 | 146 | A collection of `key: value` pairs, where each key is the namespace of a language adapter and the value is an implementation of the `LanguageAdapter` interface. 147 | 148 | ### The `depends` field 149 | | Type | Required | 150 | |--------|----------| 151 | | Array | False | 152 | 153 | An array of [dependency object](#dependency-objects)s. Defines mods that this mod will not function without. 154 | 155 | ### The `breaks` field 156 | | Type | Required | 157 | |--------|----------| 158 | | Array | False | 159 | 160 | An array of [dependency object](#dependency-objects)s. Defines mods that this mod either breaks or is broken by. 161 | 162 | ### The `load_type` field 163 | | Type | Required | 164 | |---------|----------| 165 | | String | False | 166 | 167 | Influences whether or not a mod candidate should be loaded or not. May be any of these values: 168 | 169 | * "always" (default for mods directly in the mods folder) 170 | * "if_possible" 171 | * "if_required" (default for jar-in-jar mods) 172 | 173 | This doesn't affect mods directly placed in the mods folder. 174 | 175 | ##### Always 176 | 177 | If any versions of this mod are present, then one of them will be loaded. 178 | Due to how mod loading actually works if any of the different versions of this mod are present, and one of them has "load_type" set to "always", then all of them are treated as it being set to "always". 179 | 180 | ##### If Possible 181 | 182 | If this mod can be loaded, then it will - otherwise it will silently not be loaded. 183 | 184 | ##### If Required 185 | 186 | If this mod is in another mods "depends" field then it will be loaded, otherwise it will silently not be loaded. 187 | 188 | ### The `repositories` field 189 | | Type | Required | 190 | |--------|----------| 191 | | Array | False | 192 | 193 | A list of Maven repository URL strings where dependencies can be looked for in addition to Quilt's central repository. 194 | 195 | ### The `intermediate_mappings` field 196 | | Type | Required | Default | 197 | |--------|----------|------------------------| 198 | | String | False | `"org.quiltmc:hashed"` | 199 | 200 | The intermediate mappings used for this mod. The intermediate mappings string must be a valid maven coordinate and match the `^[a-zA-Z0-9-_.]+:[a-zA-Z0-9-_.]+$` regular expression. This field currently only officially supports `org.quiltmc:hashed` and `net.fabricmc:intermediary`. 201 | 202 | ### The `metadata` field 203 | | Type | Required | 204 | |--------|----------| 205 | | Object | False | 206 | 207 | Optional metadata that can be used by mods to display information about the mods installed. 208 | 209 | #### The `name` field 210 | | Type | Required | 211 | |--------|----------| 212 | | String | False | 213 | 214 | A human-readable name for this mod. 215 | 216 | #### The `description` field 217 | | Type | Required | 218 | |--------|----------| 219 | | Object | False | 220 | 221 | A human-readable description of this mod. This description should be plain text, with the exception of line breaks, which can be represented with the newline character `\n`. 222 | 223 | #### The `contributors` field 224 | | Type | Required | 225 | |--------|----------| 226 | | Object | False | 227 | 228 | A collection of `key: value` pairs denoting the persons or organizations that contributed to this project. The key should be the name of the person or organization, while the value can be either a string representing a single role or an array of strings each one representing a single role. 229 | 230 | A role can be any valid string. The "Owner" role is defined as being the person(s) or organization in charge of the project. 231 | 232 | #### The `contact` field 233 | | Type | Required | 234 | |--------|----------| 235 | | Object | False | 236 | 237 | A collection of `key: value` pairs denoting various contact information for the people behind this mod, with all values being strings. The following keys are officially defined, though mods can provide as many additional values as they wish: 238 | * email — Valid e-mail address for the organization/developers 239 | * homepage — Valid HTTP/HTTPS address for the project or the organization/developers behind it 240 | * issues — Valid HTTP/HTTPS address for the project issue tracker 241 | * sources — Valid HTTP/HTTPS address for a source code repository 242 | 243 | #### The `license` field 244 | | Type | Required | 245 | |---------------------|----------| 246 | | Array/String/Object | False | 247 | 248 | The license or array of licenses this project operates under. 249 | 250 | A license is defined as either an [SPDX identifier](https://spdx.org/licenses/) string or an object in the following form: 251 | ```json 252 | { 253 | "name": "Perfectly Awesome License v1.0", 254 | "id": "PAL-1.0", 255 | "url": "https://theperfectlyawesomelicense.com/", 256 | "description": "This license does things and stuff and says that you can do things and stuff too!" 257 | } 258 | ``` 259 | The `"description"` field is optional. 260 | 261 | #### The `icon` field 262 | | Type | Required | 263 | |---------------|----------| 264 | | Object/String | False | 265 | 266 | One or more paths to a square .PNG file. If an object is provided, the keys must be the resolution of the corresponding file. For example: 267 | ```json 268 | "icon": { 269 | "32": "path/to/icon32.png", 270 | "64": "path/to/icon64.png", 271 | "4096": "path/to/icon4096.png" 272 | } 273 | ``` 274 | 275 | ## The `mixin` field 276 | | Type | Required | 277 | |---------------------|----------| 278 | | Array/String/Object | False | 279 | 280 | A single or array of mixin configuration entries. 281 | 282 | An entry can either be an object or a string. 283 | The mixin configuration entry object has one required field `config` and an optional field `environment`. 284 | The `config` field is a path to the mixin config file relative to the root of the mod JAR. 285 | The `environment` field is the [environment](#the-environment-field) in which the config should be loaded. If no environment or `'*'` is set, the mixin config is loaded on both environments. 286 | 287 | Providing a string is the same as providing a mixin configuration entry with a config field and no environment field. 288 | 289 | Examples: 290 | ```json 291 | "mixin": { 292 | "config": "modid.mixins.json", 293 | "environment": "client" 294 | } 295 | ``` 296 | 297 | ```json 298 | "mixin": "modid.mixins.json" 299 | ``` 300 | 301 | ```json 302 | "mixin": [ 303 | { 304 | "config": "modid_client.mixins.json", 305 | "environment": "client" 306 | }, 307 | "modid.mixins.json" 308 | ] 309 | ``` 310 | 311 | ## The `access_widener` field 312 | | Type | Required | 313 | |--------------|----------| 314 | | Array/String | False | 315 | 316 | A single or array of paths to access widener files relative to the root of the mod JAR. 317 | 318 | ## The `minecraft` field 319 | | Type | Required | 320 | |--------|----------| 321 | | Object | False | 322 | 323 | Contains flags and options related to Minecraft specifically. 324 | 325 | ### The `environment` field 326 | | Type | Required | 327 | |--------|----------| 328 | | String | False | 329 | 330 | Defines the environment(s) that this mod should be loaded on. Valid values are: 331 | * `"*"` — All environments (default) 332 | * `"client"` — The physical client 333 | * `"dedicated_server"` — The dedicated server 334 | 335 | ## Custom Elements 336 | In addition to the defined elements above, mods and libraries will be able to add their own elements to the quilt mod file. Mods will be expected to define up to one top-level element corresponding to their mod id. The element can be of any type, so that mods can define either a single value, array of values, or a sub-object. 337 | 338 | ## Example 339 | An example quilt.mod.json: 340 | ```json 341 | { 342 | "schema_version": 1, 343 | "quilt_loader": { 344 | "group": "org.quiltmc", 345 | "id": "example_mod", 346 | "provides": [ 347 | { 348 | "id": "super_awesome_lib", 349 | "version": "1.0.0" 350 | }, 351 | "flamingo" 352 | ], 353 | "version": "1.0.0", 354 | "entrypoints": { 355 | "main": [ 356 | "org.quiltmc.examplemod.impl.ExampleMod", 357 | "org.quiltmc.examplemod.impl.ExampleModNetworking" 358 | ], 359 | // Since we only have a single client endpoint, no array is needed. 360 | "client": "org.quiltmc.examplemod.impl.client.ExampleModClient" 361 | }, 362 | "depends": [ 363 | "quilt_networking_api", 364 | "quilt_rendering_api", 365 | { 366 | "id": "modmenu", 367 | "environment": "client" 368 | } 369 | ], 370 | "breaks": [ 371 | { 372 | "id": "sodium", 373 | "reason": "Sodium does not implement the Quilt Rendering API.", 374 | "unless": "indium" 375 | }, 376 | { 377 | "id": "some_random_library", 378 | "versions": "1.23.456" 379 | }, 380 | { 381 | "id": "some_random_library", 382 | "reason": "Stable API required", 383 | "versions": "<1.0.0" 384 | }, 385 | { 386 | "id": "some_random_library", 387 | "reason": "Contain game-breaking bugs", 388 | "versions": [ 389 | "1.5.3", 390 | "1.2.7", 391 | "1.8.3" 392 | ] 393 | } 394 | ], 395 | "metadata": { 396 | "name": "Quilt Example Mod", 397 | "description": "An example mod for the Quilt ecosystem.", 398 | "contributors": { 399 | "Haven King": "Developer" 400 | }, 401 | "contact": { 402 | "homepage": "https://quiltmc.org/" 403 | }, 404 | "license": "CC0-1.0", 405 | "icon": "assets/modid/icon.png" 406 | } 407 | }, 408 | "mixin": [ 409 | "modid.mixins.json" 410 | ] 411 | } 412 | ``` 413 | 414 | ## Placeholders 415 | Strings with defined formats such as [the version field](#the-version-field) can instead supply a string matching the regex `^\$\{[a-zA-Z_$][a-zA-Z\d_$]*\}$` in a development environment to be replaced on build. The quilt-gradle plugin defines usage of the value `${version}` as a placeholder for the version declared in gradle.properties. 416 | 417 | ## Dependency Objects 418 | A dependency object defines what mods/plugins a given mod depends on or breaks. It can be represented as either an object containing at least [the `id` field](#the-id-field-1), a string mod identifier in the form of either `mavenGroup:modId` or `modId`, or an array of dependency objects. If an array of dependency objects is provided, the dependency matches if it matches ANY of the dependency objects for the "depends" and "unless" fields, and ALL for the "breaks" field. 419 | 420 | ### The `id` field 421 | | Type | Required | 422 | |--------|----------| 423 | | String | True | 424 | 425 | A mod identifier in the form of either `mavenGroup:modId` or `modId`. 426 | 427 | ### The `versions` field 428 | | Type | Required | Default | 429 | |---------------------|----------|---------| 430 | | Array/Object/String | False | `"*"` | 431 | 432 | A version specifier, or complex set of version specifiers that control what versions match this dependency object. 433 | 434 | It is an error to specify multiple constraints that conflict with each other (where no version would match the whole specifier). 435 | 436 | It is an error when the resulting version specifier matches every version, and isn't the single string `"*"`, or uses the deprecated array style of definition. 437 | 438 | #### String 439 | 440 | Should be a single [version specifier](#version-specifier) defining the versions this dependency applies to. 441 | 442 | #### Array (Deprecated) 443 | 444 | Should be an array of [version specifiers](#version-specifier) defining the versions this dependency applies to. The dependency matches if it matches ANY of the listed versions. 445 | 446 | This usage is discouraged as many mod developers wrongly assumed this was "ALL" rather than "ANY", leading to unfortunate situations where mods depend on [ ">=1.18.1", "<1.19.3" ], which actually matches _every_ version of Minecraft, rather than just the versions between 1.18.1 and 1.19.2. 447 | 448 | * Quilt Loader will emit a formatting warning when discovering mods that use this. 449 | * Quilt Loader will not emit errors if this is used. 450 | * Future schema versions will likely remove this array functionality. 451 | 452 | #### Object 453 | 454 | This must contain a single field, which must either be `any` or `all`. 455 | 456 | The field value must be an array, with more constraints. Each element of the array must either be a string [version specifier](#version-specifier), or an object which is interpreted in the same way as the [versions field](#the-versions-field) itself. 457 | 458 | ### The `reason` field 459 | | Type | Required | 460 | |--------------|----------| 461 | | String | False | 462 | 463 | A short, human-readable reason for the dependency object to exist. 464 | 465 | ### The `optional` field 466 | | Type | Required | Default | 467 | |---------|----------|---------| 468 | | Boolean | False | `false` | 469 | 470 | Dependencies marked as `optional` will only be checked if the mod/plugin specified by [the `id` field](#the-id-field-1) is present. 471 | 472 | ### The `unless` field 473 | | Type | Required | 474 | |------------------|----------| 475 | | DependencyObject | False | 476 | 477 | Describes situations where this dependency can be ignored. For example: 478 | ```json 479 | { 480 | "id": "sodium", 481 | "unless": "indium" 482 | } 483 | ``` 484 | 485 | Game providers and loader plugins can also add their own optional fields to the dependency object for extra context when resolving dependencies. The Minecraft game provider, for instance, might define an "environment" field that can be used like so: 486 | 487 | ```json 488 | { 489 | "id": "modmenu", 490 | "environment": "client" 491 | } 492 | ``` 493 | ## Provides Objects 494 | Defines the identifier and optionally version range of another mod that this package provides. It can be represented as either an object containing at least [the `id` field](#the-id-field-2), or a string mod identifier in the form of either `mavenGroup:modId` or `modId`. 495 | 496 | ### The `id` field 497 | | Type | Required | 498 | |--------|----------| 499 | | String | True | 500 | 501 | A mod identifier in the form of either `mavenGroup:modId` or `modId`. 502 | 503 | ### The `version` field 504 | | Type | Required | 505 | |--------|----------| 506 | | String | False | 507 | 508 | Should be a valid mod version. If omitted, then this defaults to the version of the providing mod. 509 | 510 | ## Version Specifier 511 | A version range specifier can make use of any of the following patterns: 512 | * `*` — Matches any version. Will fetch the latest version available if needed 513 | * `1.0.0` — Matches the most recent version greater than or equal to version 1.0.0 and less than 2.0.0 514 | * `=1.0.0` — Matches exactly version 1.0.0 and no other versions 515 | * `>=1.0.0` — Matches any version greater than or equal to 1.0.0 516 | * `>1.0.0` — Matches any version greater than version 1.0.0 517 | * `<=1.0.0` — Matches any version less than or equal to version 1.0.0 518 | * `<1.0.0` — Matches any version less than version 1.0.0 519 | * `1.0.x` — Matches any version with major version 1 and minor version 0. 520 | * `~1.0.0` — Matches the most recent version greater than or equal to version 1.0.0 and less than 1.1.0 521 | * `^1.0.0` — Matches the most recent version greater than or equal to version 1.0.0 and less than 2.0.0 522 | 523 | # Drawbacks 524 | The primary drawback to this proposed format is the break from convention established by the Fabric project. It may make it more difficult for modders to adjust to the new toolchain if they are having to make drastic changes to their mod files. 525 | 526 | # Rationale and Alternatives 527 | It makes sense to take advantage of the breaking divergence of the toolchain to make changes that are better for Quilt's future. We could stick more strictly to the fabric.mod.json specification, but we would lose a lot of the advantages that this iteration has. 528 | 529 | # Prior Art 530 | This specification builds upon the Fabric projects existing [fabric.mod.json v1 specification](https://fabricmc.net/wiki/documentation:fabric_mod_json_spec). 531 | 532 | The [contributors section](#the-contributors-field) is loosely based on that of [the Sponge project](https://www.spongepowered.org/)s plugin metadata specification. 533 | 534 | The structure for this specification is loosely based on the Rust project's [manifest format specification](https://doc.rust-lang.org/cargo/reference/manifest.html). 535 | 536 | # Unresolved Questions 537 | * How will the community (particularly the development community) react to these changes? 538 | * What changes will need to be made in Loader to facilitate this new structure? 539 | 540 | 541 | [binary name]: https://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html#jls-13.1 542 | -------------------------------------------------------------------------------- /specification/0041-hashed-mappings-specification.md: -------------------------------------------------------------------------------- 1 | # Hashed Mapping Specification 2 | 3 | ## Summary 4 | 5 | This document intends to revise and formalize the process for creating a 6 | hashed mapping as originally proposed in the hashed mojmap [RFC 19](https://github.com/QuiltMC/rfcs/blob/master/rfc/0019-hashed-mojmap.md). 7 | 8 | ## Motivation 9 | 10 | Hashed Mojmap is intended to replace intermediary as our runtime mappings. 11 | It provides some benefits over intermediary, most notably the reduced maintenance cost. 12 | 13 | One of the design goals of hashed was, that it is not built incrementally, 14 | but can always be created from an existing official mapping set without knowledge of earlier hashed versions. 15 | This also means that it should be possible for anyone to generate hashed mappings, 16 | even if they don't plan to use the mappings-hasher designed by Quilt. 17 | In order to allow this, a specification for the hashed mapping is needed. 18 | 19 | In order to specify our intended behaviour, this document describes the process to generate a hashed mapping. 20 | Anything not specified in this RFC is considered a bug in the generation of hashed mappings. 21 | 22 | ## Explanation 23 | 24 | Given an original mappings set and the corresponding classes, a new mapping set is created with the following properties: 25 | - All new mappings are a hash of the corresponding original mapping. 26 | - All new mappings are unique in the new mapping set where possible. 27 | - The new mappings must ensure that the resulting remapped jar can be verified and executed. 28 | - The new mapping set should be as resilient to changes in the original mapping set and corresponding classes as possible. 29 | 30 | In order to achieve this, the following operations are performed on the original mapping set: 31 | - Convert all class/method/field names into their corresponding "raw name". 32 | - Ensure methods in the same "override hierarchy" have the same raw name. (See "Method Name Sets".) 33 | - Hash all raw names using the same algorithm. 34 | - Mark all hashed class/method/field names with a corresponding prefix. 35 | - Prefix hashed class mappings with a default package. 36 | - Strip any mapping information that is unnecessary. 37 | 38 | ### Raw Names 39 | For classes, the raw name is their binary name with the package omitted where possible. 40 | The package of a class can be omitted if and only if the original simple class name (i.e. the original class name without the package) is unique in the original mapping set. 41 | 42 | For methods and fields, the raw name is the raw name of the owner class, followed by their original name and descriptor, unless the descriptor can be omitted. 43 | The descriptor of a method/field can be omitted if and only if the original method/field name is unique in its owner class. 44 | 45 | The exact format is: 46 | - Class: `` 47 | - Method: `m;.;` 48 | - Field: `f;.;` 49 | 50 | ### Method Name Sets 51 | All methods in a name set are required to have the same raw name. 52 | Method A and method B are in the same name set if and only if one of the following is true: 53 | - A overrides B. 54 | - B overrides A. 55 | - There exists a method C that is both in the same name set as A and in the same name set as B. 56 | 57 | > "A overrides B" means that the owner of B is a superclass or superinterface of the owner of A and that A "can override" B according to `JVMS 4.5.4`. 58 | 59 | The raw name each set uses is the lexicographically lowest raw name of all methods in the name set that don't override another method. 60 | 61 | ### Hash function 62 | The raw names are hashed using the SHA-256 hash algorithm. 63 | The resulting hash is converted into base-26 (a-z). 64 | The least significant 8 base-26 digits are then used as the hash, most significant digit first. 65 | 66 | ### Prefix 67 | The following prefixes are used: 68 | - Class: `C_` 69 | - Method: `m_` 70 | - Field: `f_` 71 | 72 | ### Default Package 73 | All hashed class names are prefixed with a default package. 74 | The default package for hashed mojmap is `net/minecraft/unmapped/`. 75 | 76 | ### Omitted mapping information 77 | The mapping of a hashed name is omitted if one of the following is true: 78 | - The corresponding mapping in the original mapping set is an identity mapping AND the original mapping is longer than one letter. 79 | - The method corresponding to the method mapping overrides another method in the mapping set. 80 | 81 | ## Example 82 | The following example is intended to illustrate the process described above, but is not to be viewed as specification. 83 | 84 | Note: In this example `ClassB` extends `ClassA` and implements `InterfaceA`. 85 | | Java Name | Raw Name | Hashed Name | 86 | | ------------------------------------- | ----------------------------- | ------------- | 87 | | `org.example.ClassA` | `ClassA` | `C_fshauzuk` | 88 | | `org.example.ClassA.InnerClass` | `ClassA$InnerClass` | `C_zldtvwcl` | 89 | | `org.example.ClassA.fieldA` | `f;ClassA.fieldA;` | `f_xskwwtwz` | 90 | | `org.example.ClassA.methodA()` | `m;ClassA.methodA;` | `m_onqxeppm` | 91 | | `org.example.ClassB` | `ClassB` | `C_irypywpy` | 92 | | `org.example.ClassB.InnerClass` | `ClassB$InnerClass` | `C_znuawieq` | 93 | | `org.example.ClassB.methodA()` | `m;ClassA.methodA;` | `m_onqxeppm` | 94 | | `org.example.ClassB.methodB()` | `m;InterfaceA.methodB;()V` | `m_reinsnrb` | 95 | | `org.example.InterfaceA` | `InterfaceA` | `C_wtvyrzif` | 96 | | `org.example.InterfaceA.methodA()` | `m;ClassA.methodA;` | `m_onqxeppm` | 97 | | `org.example.InterfaceA.methodB()` | `m;InterfaceA.methodB;()V` | `m_reinsnrb` | 98 | | `org.example.InterfaceA.methodB(int)` | `m;InterfaceA.methodB;(I)V` | `m_mkznfdir` | 99 | | `org.example.packageA.ClassC` | `org/example/packageA/ClassC` | `C_hehlvtlo` | 100 | | `org.example.packageB.ClassC` | `org/example/packageB/ClassC` | `C_rvxxwsev` | 101 | 102 | ## Drawbacks 103 | 104 | - This version of hashed is potentially still less stable than intermediary, although this has not been quantified. 105 | - An "ideal" intermediary would be perfectly stable. 106 | - Hashed base-26 names might be less readable than other name formats. 107 | - This is unfortunately hard to quantify. Base-10 hashing would be an alternative, although with longer hashes. 108 | - A specification of the hashed mappings might make the format inflexible. 109 | - Changes in hashed already come with great effects, so any such change should probably go through the RFC process anyway. 110 | 111 | ## Rationale and Alternatives 112 | 113 | - This version of hashed is most likely more stable than Mojmap. 114 | - Testing has shown that around 50% of class renames in Mojmap are only repackages, 115 | which are avoided thanks to package stripping. 116 | - Hashed mappings can be fully automated, saving us the work of matching intermediary manually. 117 | - We've already evaluated that a fully automated system can update hashed within less than 10 minutes of a new release. 118 | - When working with layered mappings (e. g. quilt mappings on top of hashed) it is preferable 119 | to be able to clearly distinguish between mapped and unmapped code. 120 | - Encountering Mojmap names when working with QM could be highly confusing. 121 | - Unique hashed names provide several benefits: 122 | - Easier deobfuscation of stacktraces and other errors (especially when using bots for manual translation). 123 | - Allow source remapping from hashed to any other mapping without needing context (no classpath or even full class files needed). 124 | - Un-hides fields. 125 | - Basically no leaking of mojmap. 126 | - Makes it easier to argue about mojmap license. 127 | - Would allow using it in "taint free" contexts if it ever comes to it (e.g. yarn) 128 | - Detection of unobfuscated names is now done by checking whether mappings are identity mappings. 129 | - Detection via annotations was attempted, but required too many special cases (constructors, enum values array, etc.) 130 | - Single character names in the original mapping have a chance of coinciding with the obfuscated names. 131 | - We decided to treat all single character identity mappings as obfuscated 132 | 133 | ## Prior Art 134 | 135 | The first attempt at hashed mappings was outlined in [RFC 19](https://github.com/QuiltMC/rfcs/blob/master/rfc/0019-hashed-mojmap.md). 136 | This was then implemented in the [mappings-hasher](https://github.com/QuiltMC/mappings-hasher). 137 | 138 | Later, an attempt was made to create a [simplified hasher](https://github.com/QuiltMC/mappings-hasher/tree/archive/simplified_hasher), 139 | by only hashing the mappings without information of the jar. 140 | However, this idea was scrapped due to the drawbacks of non-unique mapping names. 141 | 142 | ## Unresolved Questions 143 | 144 | - Some of our current tooling might not be fully capable of dealing with these new mappings. 145 | However, this is to be fixed in the corresponding tooling, rather than the hashed mappings. 146 | 147 | - While this simple format seems to work fine, no extensive testing has been done with the rest of the toolchain. 148 | Hashed Mojmap will remain on the snapshot maven until we are confident that the tooling works and this RFC is merged. 149 | -------------------------------------------------------------------------------- /specification/0081-active-user-beacon.md: -------------------------------------------------------------------------------- 1 | RFC 81 (Active User Beacon) has been removed by [RFC 84](https://github.com/QuiltMC/rfcs/pull/84) 2 | 3 | The original specification can be read here: https://github.com/QuiltMC/rfcs/commit/5b9b99cfd906d672f79e8e8007dfaa6f888d8c47 4 | -------------------------------------------------------------------------------- /specification/README.MD: -------------------------------------------------------------------------------- 1 | # Specifications 2 | This folder is for RFCs that define the specification of a file format, network handshake, etc. 3 | The RFCs in this folder are meant to be living documents that adapt over time as the specification needs to be changed. 4 | -------------------------------------------------------------------------------- /structure/0001-rfc-process.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | In many other open source projects and open standards, an RFC (or "Request For Comments") process is used to give all stakeholders a chance to voice their opinions and concerns on a particular change to some project or standard. This allows the community to have a voice, while still eventually forcing an actual decision. 3 | 4 | # Motivation 5 | The RFC process aims to facilitate thoughtful discussion in the decision-making process for the Quilt organization. This Rust-inspired RFC process encourages contributors to get changes approved by submitting a detailed RFC, which will accept criticism until the team in charge of the project motions for a final comment period, wherein the team states its intent to merge, close, or postpone the RFC, allowing for resolution of the RFC unless a substantial argument arises. 6 | 7 | This will allow us to put a time limit on unproductive discussion where necessary, so actual progress can still be made while giving the community a place to voice their opinions. 8 | 9 | # The Quilt RFC Process 10 | This document gives an outline of how the RFC process works and explains how contributors should submit their RFCs to the project. 11 | 12 | ## When you must submit an RFC 13 | The RFC process requires that any large top-level organizational changes should be preceded by a "Request For Comments" document just like this one, explaining the proposed change, the motivation behind it, potential drawbacks, and other considerations. These documents are then discussed and revised by the community for some period of time until a maintainer decides that enough discussion has happened and begins a final comment period, after which a final decision is made. 14 | 15 | Most smaller changes to Quilt projects (such as bugfixes) can be submitted via the normal GitHub pull request system, however some are substantial enough that we would prefer that members of the community are given some time to discuss the potential change and give their feedback. 16 | 17 | While this document describes when RFC's are required on an organizational level, individual organizational units, such as the Quilt Standard Libraries or Quilt Loader teams, may also require RFCs. 18 | 19 | ## Creating an RFC 20 | A proper RFC is a high quality, well thought out document describing in detail all the possible benefits, drawbacks, and other consequences of the suggested change. A low effort or low quality RFC is likely to be rejected quickly. 21 | 22 | Before beginning the process, it can be helpful to discuss your ideas with other community members on our [discord server](https://discord.quiltmc.org/) to get a feel for the community's opinion on the issue. 23 | 24 | Once you have a good idea of what you want to suggest, and how the community feels about it, you can begin writing your RFC. 25 | 26 | ## The Process 27 | When you are ready to submit an RFC, the process will work as follows: 28 | - Fork the RFC git repository 29 | - Copy `0000-template.md` to `0000-my-suggestion.md` (replace `my-suggestion` 30 | with a descriptive name for your RFC). Don't change the number yet; you will 31 | replace the `0000` with your pull request number from GitHub once you have 32 | submitted the PR. 33 | - Fill in the template. This should be done with care and effort. You are 34 | making a major suggestion for a change to the project – take it 35 | seriously. 36 | - Submit a pull request. An open pull request represents an RFC which is still 37 | in the commentary phase. You will receive comments and feedback from other 38 | community members. You should be prepared to revise your RFC in response to 39 | some of this feedback. 40 | - Now that you have an open pull request, rename your markdown file to replace 41 | the `0000` with your PR number. 42 | - Your PR will be labelled with the relevant project team's label. That team 43 | will be responsible for handling the RFC process from here on. 44 | - Build consensus among the community and incorporate feedback from others. 45 | RFCs with broad support are more likely to be accepted. 46 | - The team responsible for the RFC will discuss the RFC as much as possible in 47 | the pull request's comments. Discussion that occurs in other spaces should be 48 | summarized in the PR comments. 49 | - When the team responsible for the RFC decides that there has been enough discussion, a member of the team will issue a "motion for final comments". If the motion passes, it begins a 10 day period where the community has the last chance to give feedback on an RFC. 50 | + This step is taken when enough discussion has happened to make a final decision on the issue. It is designed to prevent RFCs from becoming stales. 51 | + A consensus among all community members *is not necessary* for an RFC to 52 | enter the final comment period. However, there should not be a strong 53 | consensus *against* the disposition given for the final comment period, and 54 | some argument supporting the decision should be clearly presented somewhere 55 | in prior discussion. 56 | + If discussion has gone on for a long time, the team member who motions for 57 | final comments should post a summary comment outlining all of the 58 | discussion that has occurred. 59 | + Before actually entering the final comment period, all members of the team 60 | must sign their approval. 61 | + When a team member motions for final comments, they also give a 62 | "disposition" which can be either accept, reject, or postpone. This 63 | determines what will happen to the RFC at the end of the final comment 64 | period, although the disposition may change during that period. 65 | - At the end of the final comment period, the RFC will be either accepted or 66 | rejected depending on its disposition at the close of the final comment 67 | period. 68 | + If an RFC is accepted, its PR will be merged into the main RFCs 69 | repository on GitHub and an issue (or issues) will be created on the 70 | relevant repositories to actually implement the changes. This does not 71 | necessarily mean that PRs implementing it will be automatically merged. 72 | All PRs are still subject to code quality standards and the like. 73 | + If an RFC is rejected, its PR will be closed and the suggested changes 74 | will not be implemented. 75 | + An RFC may also be "postponed". This means the RFC is effectively 76 | rejected at the moment because it does not fit into the project's 77 | near-term goals, but may be accepted at a later date. 78 | 79 | # Drawbacks 80 | - This RFC process will require constant moderation in order to ensure the 81 | quality of submitted RFCs. Low quality submissions and comments will need to 82 | be removed. 83 | - This process does not actually eliminate the bikeshedding problem, but merely 84 | puts a time limit on it. At the end of the final comment period, it's 85 | possible community members may still not be happy with the final state of the 86 | document. 87 | - If the team assigned to an RFC cannot come to a consensus on whether to enter 88 | the final comment period, an RFC could potentially end up stuck in limbo 89 | until the team can agree. 90 | - If an RFC is required for too many changes, it could slow down the 91 | development process. 92 | 93 | # Prior Art 94 | This document and the process described herein was inspired heavily by the Rust programming language's own [RFC process](https://github.com/rust-lang/rfcs). The Rust language project has been quite successful in its RFC-directed development process and overall governance structure, and a lot of this could potentially help solve some of the problems that the Fabric project experienced. 95 | 96 | 97 | # Unresolved Questions 98 | - How do we decide who is on the teams that will be responsible for reviewing 99 | RFCs? 100 | - How do we determine when enough discussion has happened for the final comment 101 | period to begin? 102 | -------------------------------------------------------------------------------- /structure/0006-governance.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | This document is intended to detail the governing structure of the Quilt project. 3 | 4 | # Motivation 5 | This document has been written with the explicit purpose of defining guidelines and expectations for project staff. 6 | It has been written with the idea of decentralizing power in mind, to help contribute to the goal of a truly open project. 7 | 8 | # Explanation 9 | 10 | ## Teams 11 | 12 | A team is a group of team members dedicated to solving a specific issue, 13 | maintaining a specific sub project, or overseeing a specific area. 14 | 15 | All teams exist as teams on GitHub and can be viewed on our website at https://quiltmc.org/about/teams/. 16 | 17 | ### Team Members 18 | 19 | A team member is a member of the organization assigned to a specific team on GitHub. 20 | A member of the organization may be assigned to multiple teams. 21 | A team must have at least one member. An individual part of at least one team (except a supporting team) is considered an 22 | organization member. 23 | 24 | ### Team Leads 25 | 26 | A team lead is a team member with the [Team Maintainer](https://docs.github.com/en/organizations/organizing-members-into-teams/assigning-the-team-maintainer-role-to-a-team-member#about-team-maintainers) 27 | role for the relevant team on GitHub. 28 | A member of the organization may be a team lead for multiple teams. 29 | Each team must have at least one team lead. 30 | A team lead may be nominated via general consensus of the team, or by an election, the process being detailed below. 31 | 32 | ### Team Responsibilities 33 | 34 | Team responsibilities will vary and be detailed on a team-by-team basis. 35 | In general, a team is responsible for performing the tasks outlined in the RFC that proposed its creation. 36 | 37 | Most teams will also maintain one or more repositories on GitHub. 38 | The team is responsible for reviewing pull requests and ensuring that they meet The Quilt Project's goals in quality and purpose. 39 | Once a team has decided that a pull request is suitable for merging, a team lead will be responsible for the actual merging. Team leads can also decide to allow some or all team members to perform merges. 40 | 41 | ### Creating a Team 42 | 43 | A new team can be created by passing an RFC defining that team. 44 | The initial team leads must be specified in the pull request adding the RFC and must approve the RFC before it is merged. 45 | Once the [RFC process](0001-rfc-process.md) is concluded and the RFC is merged, 46 | a new team with the specified leads will be created on GitHub by the Administrative Board. 47 | 48 | The RFC proposing the new team should contain the following major sections: 49 | 50 | - **Motivation**: 51 | - Why is this team needed? 52 | - What problems will this team solve? 53 | - What tasks will this team be responsible for? 54 | 55 | - **Explanation**: 56 | - What will this team *do*? 57 | - What new projects will be created that this team will be responsible for? 58 | - How will each of these projects benefit the Quilt organization/community? 59 | - What processes will this team follow for each of the different kinds of changes their projects may undergo? 60 | 61 | - **Drawbacks**: 62 | - Is there overlap of responsibilities? 63 | - Is there excessive granularity? 64 | 65 | - **Rationale and Alternatives**: 66 | - Is there already a team responsible for the described tasks? 67 | - If this RFC doesn't pass, which team would be responsible for the described tasks? 68 | 69 | - **Prior Art**: 70 | - Are there other organizations or projects with comparable tasks? 71 | 72 | ### Sub Teams 73 | 74 | Some teams may wish for more granular organization of their structure. 75 | In those cases, these teams may define sub teams in their corresponding RFC. 76 | 77 | Sub teams behave like regular teams, except they are not required to have a team lead. 78 | If the sub team doesn't have its own team lead, the parent team lead's acts as its team lead. 79 | In general, a sub team inherits its parent's structure according to their parent's team RFC. 80 | 81 | ### Supporting Teams 82 | 83 | A special type of teams called Supporting Teams can exist. They are here to provide support to the organization, through tasks 84 | such as triaging and tagging GitHub issues, quality assurance, writing regression tests, etc.. 85 | 86 | Members of Supporting Teams aren't considered organisation members. Supporting Teams do not require leads, and may not be or contain sub teams. 87 | 88 | Individuals can be added to a Supporting Team through informal consensus within the relevant teams, without the need for a proper vote to take place, 89 | as members of Supporting Teams don't have the sensitive access usually granted to regular team members. 90 | 91 | ## The Administrative Board 92 | 93 | The administrative board is a group of organization members responsible for tasks that are not assigned to another team. 94 | It is made up of at least three members to prevent deadlocks in the decision-making process. 95 | Members of the administrative board may be members of other teams. 96 | 97 | If it is decided that more administrative board members are required, either due to a current member stepping down, or due to it being decided through informal concensus that the admin board needs to be expanded, an election must take place. 98 | 99 | ### Admin Board Election Process 100 | 101 | Due to the fact that multiple candidates may be nominated for the admin position when a vote is held, the fact that there may be multiple spots to fill on the board, and the fact that the decision affects the entire organization, the standard voting procedure cannot be used. Instead, the following procedure will be employed: 102 | 103 | Before the vote begins, a group of people, henceforth referred to as the Election Oversight Board or EOB, must be selected to oversee the voting process. They will be responsible for receiving candidate nominations, concerns about nominated candidates from other organization members, and hosting the election. In normal circumstances, the EOB consists of the existing members of the admin board, but, if this is not possible for any reason, the EOB will instead consist of members with the Community Manager role in the Community Team. The initial EOB may add any members that they feel would be a valuable addition to the board, with a simple majority vote. 104 | 105 | The vote is conducted using [Single Transferrable Vote](https://en.wikipedia.org/wiki/Single_transferable_vote) (STV), or [Instant Runoff voting](https://en.wikipedia.org/wiki/Instant-runoff_voting) (IRV) in instances where there is only one space on the admin board to be filled, to ensure a minimum amount of "wasted votes". When using Single Transferrable vote, the [Droop Quota](https://en.wikipedia.org/wiki/Droop_quota) must be used to calculate the amount of votes required for a candidate to win a position on the admin board. 106 | 107 | If the number of candidates is inferior or equal to the number of seats to fill, a majority vote is held on each candidate to validate whether they are fit for the role or not. 108 | 109 | At the start of the voting process, each organization member may nominate themselves. Nominations must be submitted to the EOB within one week of the start of the process, after which time the vote is opened. 110 | 111 | After one week of preparation and nomination submission, nominations must close, the list of candidates must be published, and the vote must begin, lasting one week. The list of voters cannot change beyond that point, unless a voter is removed from the organization and poses serious threat to the vote integrity. The system used to conduct the vote must allow voters to change their votes, and enable voters to rank the candidates in order of preference, while also having the option to not rank any given candidate. All organization members are able to vote. During the vote, voters can contact the EOB about any concerns they have over the vote (for example, concerns about a candidate being elected, or concerns about the vote being influenced by an external force), to be dealt with as outlined in the paragraph below. 112 | 113 | If the EOB receives any concerns over a candidate, either internally or submitted by voter, they must decide if the concerns are worth investigating. If they are not, no further action is taken. If they are, the team must investigate, and, if significant results are found, must publish the results to the voters, so that they can factor them into their decision. The EOB cannot prevent any candidate from running, this is to ensure that they don't have direct control over who can be elected. If, however, the vote is due to end before the EOB can complete their investigation, they may delay the end of the vote by up to 30 additional days. 114 | 115 | After the voting period concludes, the EOB may take up to three days to count the votes. In the event of a tie, another vote will be held by the current members of the Administrative Board including only the tied candidates through their chosen process. The EOB may privately inform the candidates before publishing the results to the organization members and subsequently the community at large. 116 | 117 | ## Processes 118 | 119 | To streamline working with teams, some standard processes need to be defined. 120 | The following processes apply to all teams unless that team's RFC specifies a different process. 121 | 122 | ### Voting 123 | 124 | Unless specified otherwise, the following process is used for voting: 125 | 126 | A vote in a team may be called at any time by a team lead for that team or for one of its parent teams. 127 | A vote can also be initiated as required by another process, such as adding or removing a team member. 128 | 129 | When a vote is called within a team, all members of that team and its parent teams are eligible to vote. 130 | All polls should include a positive and negative option, as well as the option to abstain. 131 | Voting members that abstain are excluded from percentages and tallies. 132 | Voting members not casting a vote within the allotted time frame are counted as abstained. 133 | 134 | After one week, the majority wins. The vote may also be called early if all eligible members 135 | casted their vote. 136 | 137 | ### Introduction of Staff 138 | 139 | Any community member is eligible to be added to a team by a majority vote of all eligible organization members. 140 | The vote is started by request from an eligible organization member. A community member wishing to join a team may 141 | kindly ask an eligible organization member to request a vote. 142 | The following members are eligible: 143 | - All members of the relevant team 144 | - All members of all the sub teams of the relevant team 145 | - All members of all the parent teams of the relevant team 146 | 147 | During the vote, especially if the community member isn't already part of any team, the rest of the organization is 148 | consulted for opinions. 149 | 150 | ### Removal of Staff 151 | 152 | Any team member or administrative board member may be removed by a majority vote of all eligible organization members. 153 | The following members are eligible: 154 | - All members of the relevant team 155 | - All members of all the sub teams of the relevant team 156 | - All members of all the parent teams of the relevant team 157 | - When the team in question is the Admin Board: All members of all teams 158 | 159 | ### Dismissing a Team 160 | 161 | When a team is no longer able to manage itself, any member of the organization may, 162 | with proper justification, start a vote to remove all members of the team in question. 163 | All organization members are eligiable to vote in this scenario. 164 | 165 | If the majority votes in favor, all current team members are removed and the Administrative Board will designate one 166 | or more new team leads who will be in charge of building the new team. 167 | 168 | # Drawbacks 169 | 170 | In the present day with most accounts and digital spaces being controlled primarily by one person, 171 | the idea of an "administrative board" has some downsides. 172 | A member of the board who is asked to step down may simply refuse to relinquish any resources they control. 173 | For this reason, personal character needs to be a high priority when electing members to the board, 174 | so that such a situation can be avoided. This can also be avoided by keeping the roles of the administrative board 175 | purely as steering and oversight and by delegating ownership to other relevant teams, such as the Infrastructure Team. 176 | 177 | It's important to consider the possibility that self-managed teams may become corrupted over time. 178 | To handle this scenario, we would need to use the dismissing process to dissolve the entire team. 179 | -------------------------------------------------------------------------------- /structure/0007-community-team.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | This document exists to describe the formation of a team that handles Quilt's community management tasks. It makes 4 | reference to **the Quilt community**, which may be defined as all official Quilt community spaces, including (but not 5 | limited to): 6 | 7 | * The QuiltMC GitHub organisation and repositories 8 | * The official Quilt Discord server 9 | * The official Quilt wiki 10 | 11 | **Note:** Unordered lists in this document have been alphabetized to emphasise the fact that, in most cases, entries 12 | in those lists are of equal importance. 13 | 14 | 15 | # Motivation 16 | 17 | Community management is an extremely important task, especially so for community-driven projects like Quilt. 18 | Maintaining a healthy community should always be a top priority, and a team should be formed to handle Quilt's 19 | community aspects as best it can. 20 | 21 | While most of the work the community team will do will not be directly relevant to Quilt's development efforts, 22 | its members must be prepared to deal with issues in development-related spaces that fall within the team's scope. 23 | 24 | ## Advantages and Benefits 25 | 26 | A community-driven project exists to serve its community's needs. The only way this is an achievable goal is to 27 | maintain a healthy, safe and involved community - with dedicated community spaces, and a dedicated management team. 28 | 29 | It should be understood that an active, healthy community has many benefits - not all of which are easy to enumerate 30 | in a document, or which directly concern the project in an obvious way. That said, the following benefits should be 31 | fairly observable from an active, healthy community: 32 | 33 | * A higher chance of obtaining sponsorships that allow the project to grow beyond its technical bounds 34 | * A larger pool of feedback to work with, as well as more opportunities to work with the community on solutions to 35 | issues 36 | * A larger pool of potential contributors, for development projects and otherwise 37 | * Improved project recognition and reputation within modding spaces, as well as within the wider development- and 38 | game-related spaces worldwide 39 | * More opportunities for collaboration with the rest of the modding community 40 | * More opportunities to improve the modding ecosystem as a whole 41 | * More opportunities to support the members of our community in ways that are meaningful to them 42 | 43 | 44 | # Explanation 45 | 46 | The Community Team will be in charge of maintaining the Quilt community spaces, as detailed in the summary. It will 47 | be responsible for drafting up, accepting comments on and implementing community policies, interacting with and 48 | protecting the community and its members, and resolving conflicts and enforcing the community policies. Community Team 49 | members also play a large role when it comes to community engagement, and team members should be prepared to plan 50 | events and generally engage with the community when possible. 51 | 52 | ## Keyholders 53 | 54 | While Quilt is a community project with concerns split across different teams, Discord (and some other platforms) is 55 | designed with the core idea of a single community leader or owner in mind. For that reason, platforms that cannot be 56 | run explicitly under team leadership alone must be "owned" by a keyholder. 57 | 58 | A keyholder is a democratically elected member of the community that otherwise has no direct involvement or stake 59 | in the management of the community. By electing an otherwise unrelated party to be a keyholder, it's hoped that the 60 | Quilt community spaces can avoid the issue of a community leader gone rogue - it should prevent an abuse of power from 61 | giving someone total control over any community space, at least as far as is possible. 62 | 63 | After they've been elected, a keyholder does not need to be otherwise active in the community. All that's required of 64 | them is that they're easily contactable (within reason), and that they're prepared to act in the event that something 65 | happens that they will need to take care of. 66 | 67 | Keyholder candidates should: 68 | 69 | * Be able to show that they have no conflicting interests or personal wish to be in power 70 | * Be known to a majority of the Community Team 71 | * Have a clean, positive reputation in the Quilt community and wider modding community 72 | * Have some accreditation or other guarantee of reputation in the wider modding community 73 | * Regarding Discord specifically, they should be prepared to act as a liaison with the Discord team and to represent 74 | the Quilt community officially when interacting with them, including in the event of a partnership or working 75 | relationship with Discord 76 | * Understand what's involved with keyholding, and be ready to step in when needed 77 | 78 | Keyholders are not members of the Community Team, and they are not required to be obvious in the communities they 79 | keyhold for - but they are free to make themselves known if they wish. They're also welcome to oversee the community 80 | team in their actions and processes, and provide opinions and feedback if they wish. 81 | 82 | ## Basic Responsibilities 83 | 84 | All members of the Community Team have the following responsibilities: 85 | 86 | * To represent the Quilt project in an honest and respectful manner, and serve as an example of good behaviour in 87 | community spaces 88 | * To participate in the processes that shape the Community Team, including voting on new team members and structural 89 | changes to community spaces (unless they're a Trainee Community Moderator - see below) 90 | * To engage with the community authentically, being present and visible in the community when able and appropriate 91 | * To be supportive of other Community Team members, providing insight, advice and support when able and appropriate 92 | * To help with the planning and running of community events and projects, when able and appropriate 93 | 94 | All team roles are additive - they add additional responsibilities on top of this basic set. 95 | 96 | ## Team Roles 97 | 98 | Community Team members may have specific roles, which define additional responsibilities (and additional tools to meet 99 | those responsibilities) on top of their basic responsibilities, as defined above. While the roles are intended to be 100 | fairly balanced regarding their responsibilities, there is still likely to be some overlap - for example, Community 101 | Managers also have the *ability* to moderate, if they're required to. 102 | 103 | The role structure is intended to be flat, rather than an explicit hierarchy. Roles represent tasks and 104 | responsibilities, rather than seniority. Roles may be assigned based on a number of criteria, including: 105 | 106 | * Previous experience 107 | * Staffing shortfalls or situational needs 108 | * Suitability for the role 109 | * Types of work the team member is offering to handle 110 | 111 | ### Community Managers 112 | 113 | Community managers are responsible for day-to-day administrative tasks in Quilt community spaces, and take an active 114 | role in the Community Team candidacy process. They're in charge of mobilizing and supporting the rest of the community 115 | team, maintaining community spaces, and keeping everything running smoothly. Responsibilities include: 116 | 117 | * Actioning changes to the structure of community spaces, or to community policies 118 | * Aiding in conflict resolution and decision-making, especially when it comes to difficult moderation decisions 119 | * Engaging with the community when they have questions, reports or issues, and working with them to address their 120 | concerns 121 | * Facilitating the Community Team candidacy process by helping other team members to set up polls, and conducting 122 | interviews 123 | * Maintaining informational channels, and writing and posting community-oriented announcements 124 | * Managing any bots or other community-relevant automation tools 125 | * Organising, training and supporting the moderation team, and acting as supplemental moderators as required 126 | * Supporting the rest of the Community Team in their work, providing them with the tools and changes to community 127 | spaces that they need 128 | 129 | Community managers must be appointed democratically, following the process outlined later in this document. If 130 | required, the keyholders will handle handing out the permissions required for community managers to work in Quilt 131 | community spaces. 132 | 133 | ### Community Moderators 134 | 135 | Community Moderators are responsible for maintaining the safety and welfare of the members of the Quilt community by 136 | enforcing the community policies, aiding in conflict resolution and dealing with problematic users and behaviours. 137 | Responsibilities include: 138 | 139 | * Aiding in conflict resolution between community members, and de-escalating heated situations 140 | * Applying infractions for problematic behaviour or removing problematic users - in accordance with the community 141 | policies 142 | * Collaborating with other Community Team members to ensure the smooth running of the community, and to ensure that due 143 | process is followed - in accordance with the community policies 144 | * Engaging in active, honest participation in the Quilt community 145 | * Engaging in the Community Team's democratic processes 146 | * Helping members to find the correct community space for their query, and ensuring that other members don't prevent 147 | them from getting the support they need 148 | * Keeping up to date on social issues (especially those that affect minority groups), and applying that knowledge to 149 | keep community members safe 150 | 151 | Community Moderators must be appointed after a training period of no less than two weeks, graduating from their position 152 | of Trainee Community Moderator after a review of their performance by the rest of the Community Team. 153 | 154 | ### Trainee Community Moderators 155 | 156 | Trainee Community Moderators are new moderators that have been appointed as part of the process for electing team 157 | members. They have a similar set of responsibilities to Community Moderators, and are "in training" - with oversight 158 | and support provided by the rest of the Community Team. 159 | 160 | The intention of this position is to provide new moderators with a buffer period, where they can feel more comfortable 161 | seeking help and support from the rest of the Community Team. They're also publicly differentiated from the rest of 162 | the moderation team, to ensure that community members understand that they're in-training and may make mistakes. 163 | Trainee Community Moderators are expected to lean on the rest of the team, and to incorporate feedback given to them. 164 | There is no requirement that they handle situations they're unsure about, or to make difficult decisions - these are 165 | responsibilities assigned to Community Moderators and Community Managers. 166 | 167 | Trainee Community Moderators should be excluded from the voting process until they graduate. 168 | 169 | Trainee Community Moderators must spend at least two weeks in this position before they can be promoted to Community 170 | Moderator, pending a review of their performance and discussion by the rest of the Community Team. Trainee Community 171 | Moderators must be appointed democratically, following the process outlined later on in this document. 172 | 173 | ## Process: Voting on Changes 174 | 175 | As Quilt is a community-run project and seeks to avoid the problems that come with single or small groups of people with 176 | the very last, final say on everything, the Community Team implements a democratic approach for much of its processes. 177 | This is detailed in this section - all other processes that involve votes should follow this process, unless otherwise 178 | specified. 179 | 180 | ### Voting Process 181 | 182 | 1. The Community Team needs to discuss the subject matter of the vote beforehand, and discern whether a vote should 183 | take place to begin with - if it's decided that a vote will surely fail, then no vote is required and the motion 184 | can be dismissed immediately. 185 | 2. A poll is created in an internal channel that's designated for that purpose, either by posting a simple message or 186 | via a bot designed to facilitate polling. This poll should provide as much detail as possible, either directly in 187 | the poll message or by providing links and references - but it must be clear and not misleading, and the core idea 188 | must be present in the message instead of in the references. 189 | 3. Members of the Community Team may vote on the poll using the provided reactions. All polls should include a positive 190 | and negative option, and an option to explicitly abstain. 191 | 4. Voting members are not required to explicitly explain their votes - major problems with the proposal should be 192 | worked out before the vote even begins, to avoid putting particular community members on the spot. 193 | 194 | Polls must include a closing date of no less than one day and no longer than one week, regardless of the proposal put 195 | forward. At the time of posting, polls must also list the names of all eligible, eligible but inactive, and ineligible 196 | voters, determined as described below. This list cannot change while the poll is still open, except in the case of an 197 | inactive Community Team member (defined below) returning from inactivity. 198 | 199 | ### Closing Votes 200 | 201 | Voting ends when any of the following conditions have been reached: 202 | 203 | * The poll's closing date has been reached 204 | * All eligible voters have casted a vote 205 | * The special closing conditions specified as part of the specific process that this vote is part of have been met, if any 206 | 207 | ### Interpreting the Vote 208 | 209 | If any active voting members of the Community Team don't vote on the poll (unintentionally or otherwise), their vote 210 | **must be counted as an abstention.** If a member is inactive (as defined below), they will not be counted as a 211 | positive vote, negative vote, or abstention, and will not be counted in any tally for voting. 212 | 213 | When taking into consideration plural systems, one system is treated as one voting bloc, regardless of individual 214 | members, Discord accounts, or other factors. This is to ensure that a large system is not able to overpower the votes 215 | of other Community Team members. If multiple votes are tallied on one poll originating from one system, all of the 216 | system's votes will be removed and they will be asked to vote again. In the case that all of these multiple votes are 217 | for the same option, all but one of the votes may be removed instead. 218 | 219 | The Community Team must then tally the final vote counts, and interpret them as follows. 220 | 221 | #### Passing conditions 222 | 223 | The vote has passed if all the following conditions are met: 224 | 225 | * **At least 50%** of the eligible voters (including those that abstained) voted _positively_ 226 | * **70% of all votes cast** (not including abstentions) were _positive_ 227 | * The special passing conditions specified as part of the specific process that this vote is part of have been met, if 228 | any 229 | 230 | #### Other situations 231 | 232 | Due to the mathematical nature of the conditions defined previously, a vote cannot end in a tie. Special conditions must 233 | account for ties. 234 | 235 | ### Determining voting eligibility 236 | 237 | #### Community Team 238 | 239 | All Community Team members are eligible to vote in polls, assuming they have been a member of the Community Team for 240 | at least two weeks and are not a Trainee Community Moderator. Trainees, as well as Community Team members who have not 241 | held their role for at least two weeks, are not voting members and should not be considered for internal votes. This is 242 | to ensure that all voters have had some time to get familiar with the community and how it's run, but non-voting 243 | members of the Community Team are always welcome to express their opinions and provide insight if they wish to. 244 | 245 | Additionally, any Community Team member who has not interacted in any Quilt community space for more than two weeks, 246 | internal or public, is considered inactive. Inactive members are not counted as a positive vote, negative vote, or 247 | abstention, and will not be included in the tally for voting. These members are still eligible to vote in polls, but by 248 | voting, they are no longer considered inactive. 249 | 250 | #### Admin Board Members 251 | 252 | Unless they're also a voting member of the Community Team, members of the Quilt Admin Board do not vote on internal 253 | polls by default. 254 | 255 | ## Process: Changing Community Policies 256 | 257 | While the policies themselves are out of scope for an RFC of this type, it's worth detailing the process the team 258 | should follow when working on those policies. In most cases, the following steps should be taken when creating (or 259 | amending) the community policies: 260 | 261 | 1. Discuss the changes with the community, if possible - in many cases, changes to community policy will be driven by 262 | feedback from the community's members, and interested community members should be included in the process 263 | 1. Discuss the changes internally (amongst team members) at first, to get an idea of what changes should be made 264 | and how they should be written 265 | 1. Work together to draft up the new/changed policy, accepting feedback from each other until the team members are 266 | largely happy with the changes - a full consensus is not required, but this process should continue until there 267 | are no major complaints 268 | 1. Publicise the draft, for the purpose of collecting feedback from the community and answering any questions the 269 | community members may have - this should be an active process that allows the community members to provide ideas 270 | and feedback for the community team to consider and utilize to update the publicised draft 271 | 1. After enough time has passed (usually a week) and enough feedback has been collected, finish implementing the 272 | changes proposed by the community as appropriate, and integrate the changes - thus amending the working copy of 273 | the community policies and applying the policy changes to the Quilt community going forward 274 | 275 | In some situations, smaller or more urgent changes to community policies must be made. Generally, this happens when a 276 | loophole is found, or an important omission is made - in these cases, a faster turnover is more appropriate: 277 | 278 | 1. Changes like this are often made due to community feedback - if that is the case, communicate directly with 279 | concerned community members and bring their feedback directly to the community team for consideration 280 | 1. Discuss the change internally (amongst team members) and write up a draft, as detailed in the previous step - this 281 | should be a relatively quick process, as this approach is only appropriate for small or urgent changes 282 | 1. Once the community team is happy with the draft, take one of the following approaches: 283 | * For urgent changes, it's sometimes appropriate to implement the changes immediately with no feedback period 284 | * For other small changes, a shorter feedback period (usually a day) is usually appropriate 285 | 286 | The approach taken is up to the discretion of the community team, but the latter approach should never be taken for 287 | large or wide-reaching changes to community policy, and no change may be implemented without internal discussion. 288 | 289 | In some cases, a more democratic process is appropriate - for example, asking community members to vote on an approach 290 | to a given change or issue. An approach like this is acceptable if the community team reaches a consensus on the 291 | process to be followed for it, as long as it keeps the community involved with the decision-making process. 292 | 293 | **Remember:** Ultimately, the community team exists to serve the community, rather than the interests of its members. 294 | Policy changes and additions should be created with the needs of the community and project in mind. Transparency and 295 | accountability are important values to enshrine to ensure that this is always the case. 296 | 297 | ## Process: Changing the Structure of Community Spaces 298 | 299 | From time to time, it may be necessary to change the structure of one of the community spaces - for example, the 300 | channel layout on the official Discord server, or the organisation of categories on the wiki. As our spaces exist 301 | to serve the community that makes use of them, these changes should always be made while involving the community in 302 | the process: 303 | 304 | 1. Once the need for change has been identified, inform the community of that need - explain why the change needs to 305 | happen and, if possible, propose one or more possible approaches 306 | 1. Once the need for change has been adequately brought to the attention of the community, give the community members 307 | time to provide feedback if they wish to - set a time limit based on the urgency of this change, but no more than 308 | a week and no less than a day 309 | 1. After the feedback period has ended, collect the feedback provided by the community, discuss it internally, and 310 | work towards a decision - a full consensus is not required, but this process should continue until there are no 311 | major complaints, and in some cases it may be appropriate to return to the community feedback phase before it's 312 | possible to move ahead 313 | 1. Once the team has finished discussing, implement the change and, if multiple approaches were suggested by the 314 | community members, inform the community on why this approach was ultimately decided upon 315 | 316 | ## Process: Electing Team Members 317 | 318 | As our primary communication space is the official Discord server, Community Team member appointments should be 319 | processed on Discord. Quilt's Community Team members are elected using a democratic internal process: 320 | 321 | 1. Members of Quilt community spaces may apply to join the community by contacting the Community Team directly. The 322 | preferred contact method for this is by making use of the ModMail system on Discord. 323 | 324 | * Alternatively, candidates may be put forward by other members of the Community Team, after some internal 325 | discussion. This may be a result of observations made by the Community Team, suggestions from community members, 326 | or otherwise - but the Community Team should always discuss before putting forward a candidate, and they should 327 | ensure that the candidate is actually interested in the position they're being put forward for. 328 | * Plural systems may apply collectively or individually. Due to Discord's limitations and as a result of system or 329 | individual preference, multiple accounts may end up being given Community Team roles from a single application. 330 | If a Discord account is shared between multiple system members, duties do not necessarily need to be carried out 331 | by all members. 332 | 1. Candidates must be interviewed by a Community Manager before the election process can continue. All voting members 333 | of the Community Team should be given access to the interview space, and other voting members of the Community Team 334 | are welcome to give their opinions on the content of the interview, or present their own questions after the 335 | Community Manager giving the interview opens the floor to them. 336 | 1. After an interview has taken place, a vote should be proposed, following the voting process outlined earlier in this 337 | document. This poll should last for exactly three days. 338 | 339 | The poll must include a link to the relevant interview. It should also include the specific position 340 | they're applying for. 341 | 1. Once the vote has closed, the candidate should be contacted by a community manager and given the result, which will 342 | decide whether their application was successful. 343 | 344 | * If the vote (and thus application) has failed, the candidate should be given feedback on their interview and 345 | any actionable concerns should be provided. Candidates with failed applications should not be excluded from 346 | applying again, but their next application should be at least a month after their previous one. 347 | 348 | * If the vote (and thus application) has passed, the Community Manager overseeing the application must provide the 349 | applicant with any documentation they need, ensure they're ready to join the Community Team now, and provide them 350 | with any roles and access that their new position requires. The Community Manager should also help the new 351 | team member to settle into their position, support and train them as necessary, introduce them to the 352 | development teams, announce their appointment to the community, and provide information on the structure of the 353 | internal communications channels. 354 | 355 | **Remember:** If the candidate is applying for a moderation-related role, they must always go through a training 356 | period as a Trainee Community Moderator. This is required for all Community Moderator and Community Manager positions, 357 | but is not required for positions without enforcement duties, such as event organisers. 358 | 359 | ### Points to Consider 360 | 361 | Voters (and those that are considering putting forward a candidate) should consider the following points when forming 362 | their opinion: 363 | 364 | * Does the candidate actually want to join the Community Team? 365 | * Does the candidate have a good understanding of the Quilt community policies? 366 | * Does the candidate have any known problematic behaviour outside the Quilt community? 367 | * How active is the candidate in the Quilt community? 368 | * How does the candidate choose to interact with other community members? How do they interact with the Community Team 369 | in comparison? 370 | * How does the community perceive the candidate? Do they mesh well with the rest of the community? 371 | * How has the candidate contributed to the Quilt community and project so far? 372 | * How well does the candidate fit into the Quilt community's culture? 373 | * What is the candidate's infraction history? Have they been infracted for anything serious? 374 | * Would any community members be uncomfortable if the candidate were to be elected? If so, why? 375 | 376 | Of course, there are likely to be additional considerations to keep in mind - voters should always bring up anything 377 | that concerns them about an applicant, and criticisms are not limited to the above list. 378 | 379 | ## Process: Changing/Adding Roles 380 | 381 | Each Community Team member has a specific set of responsibilities and tasks to keep in mind. These are assigned based 382 | on the role they currently occupy, but there's no reason for any Community Team member to be unable to move between 383 | roles later on if they wish, or take on additional responsibility if they're able. 384 | 385 | Any Community Team member wishing to change their role or take on another role must go through the election process 386 | for that role again. A special ModMail thread must be created - which they must not be able to access from the internal 387 | interface - and the interview process should continue as normal from there. 388 | 389 | Voting should be handled as detailed in the election process above, but the Community Team member in question should not 390 | be counted in the voting tallies or percentage of voters. If the Community Team is applying for a moderation-related 391 | role - and they haven't gone through the Trainee Community Moderator process - they must always go through a training 392 | period as a Trainee Community Moderator. 393 | 394 | Community Team members switching roles or taking on additional roles must not be treated preferentially to any other 395 | types of candidates. It's important, therefore, that the rest of the community team holds its members accountable 396 | during this process. 397 | 398 | ## Process: Removing Team Members 399 | 400 | Eligible voters are decided in alignment with 401 | [RFC 6: Governmental Structure](/structure/0006-governance.md#removal-of-staff) (anyone above or below), but a 402 | counterargument is not required or expected before voting or removal of staff permissions. Instead the call to action, 403 | discussion, and voting can occur in a private channel/dm visible to eligible voters, and if it succeeds the removed 404 | staff can submit a counterargument asking the decision be overturned after the fact. If there are concerns about 405 | damage to the community, project, or team, a Community Manager or the Key Holder may temporarily revoke staff 406 | permissions during or before a vote. In the latter case either a vote needs to be initiated or permissions restored 407 | within a week at the most. 408 | 409 | --- 410 | 411 | Community work is something that can change significantly over time, especially as the topics and behaviours that our 412 | modern society deems appropriate change. Community policies, processes and approaches will need to change in order to 413 | keep up to date with this - all members of the community team should be prepared to learn as they go. 414 | -------------------------------------------------------------------------------- /structure/0018-technical-teams.md: -------------------------------------------------------------------------------- 1 | # This Document is Deprecated 2 | 3 | [Technical Leads](#technical-leads) have been removed in favor of [Team Leads](0006-governance.md#team-leads). 4 | 5 | [Team Responsibilities](#team-responsibilities) have been generalized for all teams in [Team Responsibilities](0006-governance.md#team-responsibilities). 6 | 7 | [Technical Teams](#technical-teams) is outdated, but *all* teams can be found at https://quiltmc.org/about/teams/. 8 | 9 |
10 |
11 | Original RFC Content 12 |
13 | 14 | # Technical Team Structure 15 | 16 | ## Summary 17 | 18 | This RFC describes the structure and processes that technical teams of the 19 | Quilt project will follow. It does not detail members of each team nor does 20 | it restrict them from committing to additional policies in the future. 21 | 22 | ## Motivation 23 | 24 | Laying out a clean, formal specification for how people will interact with 25 | and decide on changes will help technical processes run more smoothly, from 26 | creating entirely new projects to making small revisions to existing ones. 27 | 28 | ## Explanation 29 | 30 | ### Technical Leads 31 | Technical leads are the highest technical authority in the Quilt Project. 32 | They are not aligned to any particular technical team, but instead act as 33 | guides, steering the other teams in a direction that's beneficial to Quilt 34 | as a whole. While the administrative board exists to oversee and facilitate 35 | policy changes throughout the project, technical leads exist to oversee and 36 | facilitate larger technical decisions. 37 | 38 | ### Team Responsibilities 39 | Technical teams are typically aligned to a specific project or set of 40 | projects. They are responsible for reviewing pull requests and ensuring that 41 | they meet the Quilt projects goals in quality and purpose. Once a team has 42 | decided that a pull request is suitable for merging, a technical lead will be 43 | responsible for the actual merging. 44 | 45 | ### Technical Teams 46 | The following is a list of top-level technical teams. 47 | 48 | | Team | Repositories | Notes 49 | |-|-|-| 50 | | Quilt Loader | [Quilt Loader](https://github.com/QuiltMC/quilt-loader)
[Quilt Installer](https://github.com/QuiltMC/quilt-installer)
[Sat4j](https://github.com/QuiltMC/quilt-loader-sat4j)
[Access Widener](https://github.com/QuiltMC/access-widener)
[Mixin](https://github.com/QuiltMC/Mixin)
[Quilt JSON5](https://github.com/QuiltMC/quilt-json5) 51 | | Quilt Standard Libraries | [Quilt Standard Libraries](https://github.com/QuiltMC/quilt-standard-libraries)TBD| Will contain additional teams for each library 52 | | Quilt Kotlin Team |TBD| Responsible for the Quilt Kotlin Libraries 53 | | Infrastructure | [Quilt Meta](https://github.com/QuiltMC/quilt-meta) 54 | | Mappings | [Yarn](https://github.com/QuiltMC/yarn)
[Intermediary](https://github.com/QuiltMC/intermediary)
[Matcher](https://github.com/QuiltMC/matcher)
[Matcher MC](https://github.com/QuiltMC/matcher-mc)
[Enigma](https://github.com/QuiltMC/yarn)
[Lorenz Tiny](https://github.com/QuiltMC/lorenz-tiny)
[Stitch](https://github.com/QuiltMC/stitch)
[Tiny Mappings Parser](https://github.com/QuiltMC/tiny-mappings-parser)
[Tiny Remapper](https://github.com/QuiltMC/tiny-remapper) 55 | | Build Tools | [Quilt Loom](https://github.com/QuiltMC/quilt-loom)
[Gradle Convention Plugins](https://github.com/QuiltMC/gradle-convention-plugins)
[Sponge Mixin Compile Extensions](https://github.com/QuiltMC/sponge-mixin-compile-extensions)
[Dev Launch Injector](https://github.com/QuiltMC/dev-launch-injector)| This team will also be responsible for developing a replacement for Quilt Loom when it becomes possible to do so 56 | | Decompilers | [Quiltflower](https://github.com/QuiltMC/quiltflower)
[CFR](https://github.com/QuiltMC/cfr)
[Procyon](https://github.com/QuiltMC/procyon) 57 | | ASMR | [ASMR Processor Prototype](https://github.com/QuiltMC/asmr-processor-prototype) | 58 | 59 | ## Drawbacks 60 | 61 | An overcomplicated leadership structure may lead to further stagnation in the development process, rather than have the intended effects of easing it. This approach is a two-way door, however, and can always be reversed if it proves unsuccessful. 62 | 63 | 64 | ## Rationale and Alternatives 65 | 66 | Many companies today follow the idea of separation of concerns. By putting people in charge of a relatively smaller number of tasks and projects, they will be able to better focus on such tasks to get things done. The alternative approach would be for a small number of people to "hold the keys" over all technical projects. Fabric currently does this, and it leads to a generally very long and arduous process for getting contributions accepted. 67 | 68 | 69 | ## Expected Response 70 | 71 | It is expected that with more refined teams being dedicated to individual projects, community members outside of those teams will also be more willing to contribute to individual projects since there will be a direct point of contact for each individual initative. 72 | 73 |
74 | -------------------------------------------------------------------------------- /structure/0039-pr-policy.md: -------------------------------------------------------------------------------- 1 | # Quilt PR Policy 2 | # Summary and Scope 3 | This RFC defines a system for merging Pull Requests (PR)s into Quilt projects. It applies to any repositories which opt-in to this system by adding a section (given below) to their CONTRIBUTING file. This document is meant to be a guideline, not a strict definition; projects may make amendments to this process (e.g. allowing it to be bypassed for typo fixes or setting restrictions on who's approvals count towards a PR) in their respective CONTRIBUTING files. 4 | 5 | This RFC does not seek to require projects to use this process, but we encourage all projects expecting many pull requests to do so. 6 | 7 | # Motivation 8 | This RFC intends to make the process of creating, reviewing, and merging PRs easier for both Quilt teams and potential contributors. 9 | 10 | The goals for the PR process are: 11 | - **Democratic** -- Features are added through consensus of the team, and not through a benevolent dictator for life (BDFL) who has total control over the project. 12 | - **Quick** -- Tools should be in place to allow the team to shut down bikeshedding and say good enough on features if needed. However, this doesn't mean that pull requests should be easily forced through. 13 | - **Hands-off** -- Every team member shouldn't have to approve every PR. The team as a whole has a responsibility to ensure PRs are reviewed in a timely manner, but no person should have a responsibility to view every change. 14 | 15 | It is **not a goal** of this PR to be fool-proof from bad actors within the Quilt technical teams abusing the system. Being on any team in Quilt requires trust, and bad actors should be removed instead of worked around. 16 | 17 | # Explanation 18 | ## Vocab 19 | - **Required Approvals**: The total number of approvals needed by the team assigned to a PR, or that team's superiors. 20 | - An approval is defined as an approving review using the GitHub review feature 21 | - **Minimum Team Approvals**: The amount of approvals that must come directly from the assigned team. When multiple teams are assigned to a PR, this number applies to each team. 22 | - This prevents PRs from getting merged by Technical Leads/etc without any oversight by the responsible team 23 | ## Acceptance Criteria 24 | A Pull Request is considered to have been approved when all of the following are true: 25 | - The Pull Request has the needed amount of Required Approvals and Minimum Team Reviews 26 | - The Pull Request has no changes requested reviews by any members of the team 27 | - Nobody in the team has an outstanding review requested on the Pull Request using the system on Github 28 | - This includes someone requesting the review of themselves or another person 29 | - All other criteria defined in the team's CONTRIBUTING file have been met. 30 | 31 | ## Final Comment Period (FCP) 32 | - Eligable to begin immediately after the Acceptance Criteria are met. 33 | - Formally begins when labeled and a comment is posted with the end date of the FCP. 34 | - Lasts a certain amount of days, depending on the category the PR was assigned to. 35 | - May be ended or restarted at any time by a team member or the PR author if they have legitimate and substantiated concerns. 36 | 37 | ## Other information 38 | Team members may dismiss their own reviews. 39 | 40 | Admins and technical leads may dismiss outstanding and requested reviews at their discretion, but should only do so if the team member cannot be contacted within a reasonable time-frame and must leave a comment on the PR with their justification. Reviews should *not* be dismissed simply because the majority (or that specific admin/technical lead) disagrees with one person or feels their concerns are invalid. Instead, a formal vote to merge a PR should be used. 41 | 42 | ## Template for CONTRIBUTING.MD 43 | ```markdown 44 | ### Pull Request Process 45 | To get a pull request merged into << PROJECT >>, it must get a certain number of approvals from the maintainers, and then it will enter a Final Comment Period. If the pull request passes the final comment period without opposition, the PR will be merged. Otherwise, the PR will return to being in review. 46 | 47 | The exact number of reviews needed, and the length of the Final Comment Period, varies depending on the scope and complexity of the pull request. The numbers for each category are listed below. 48 | 49 | #### << CATEGORY ONE >> 50 | **Required Approvals**: X 51 | - At least Y of these must come directly from the << TEAM >> team and not its superiors. 52 | 53 | **Final Comment Period**: X days 54 | 55 | << Continue for each category >> 56 | 57 | This is only a summary of the process. The exact rules are defined in [RFC 39](https://github.com/QuiltMC/rfcs/blob/master/structure/0039-pr-policy.md) 58 | ``` 59 | ## Conflicts 60 | If the team cannot agree on whether to merge a PR or deny it, there are steps they can take to avoid decision paralysis. This should be a rare process--teams are encouraged to resolve these disagreements through talking the details out, but sometimes members of the team may have fundamental disagreements over the details of a PR. 61 | 62 | In the event the disagreement is over API structure, the PR may, at the team's option, be closed and an RFC be created that defines the feature. 63 | 64 | In the event the disagreement is over implementation details, or would otherwise not benefit from being forced through the long RFC process, the voting method defined in RFC 6 can be used. Once a vote is requested by a team member, the PR will immediately enter a Final Comment Period lasting two weeks that cannot be ended by any team member. The two-week FCP can be used for team members to further discuss the PR, and for the author to make changes to the PR as needed. At the end of this period, the team will vote on if the PR should be left open, merged, or closed. 65 | # Drawbacks 66 | - Implementing a defined policy adds a layer of bureaucracy to getting PRs merged, which may be confusing. 67 | - There may be situations that this policy does not define, which could cause conflict or confusion within the teams. 68 | - Not having one person who has to review every PR could also lead to death by staleness, where a PR is never merged because nobody can be bothered to review it. 69 | - Final comment periods create a limbo where consensus on a PR has been reached but it still must wait to be merged. 70 | 71 | # Rationale and Alternatives 72 | We could do nothing and keep the current guessing game on when enough discussion has happened for a merge, but this could lead to PRs being rejected too quickly or merged too quickly. The latter is especially problematic because most of Quilt's projects are stable for long periods of time. 73 | 74 | We could assign a "benevolent dictator" for each project, similar to how many other projects are run. However, we would need to find a perfect person who is willing to devote all of their time to just one or a couple Quilt projects that everyone universally loves, and it would violate the Quilt philosophy of a democratic, team managed system. 75 | # Prior Art 76 | The policy defined here is a reaction to the issues observed with two of the other main modloaders, Forge and Fabric. Both Forge and Fabric use the BDFL model with success. However, both Forge and Fabric struggle with all the drawbacks of such a system. These include having no way to resolve disagreements with project leaders, requiring a very small amount of people (usually one or two) to view every single code change, and the staleness of PRs that get overlooked by those dictators. 77 | 78 | -------------------------------------------------------------------------------- /structure/0048-outreach-team.md: -------------------------------------------------------------------------------- 1 | # Outreach Team 2 | 3 | This document has been made according to the process outlined in [RFC 4 | 0006][RFC6]. 5 | 6 | ## Summary 7 | 8 | The Outreach Team is a subteam of the Community Team in charge of outreach 9 | and communications within and outside the Quilt Project. This team is also 10 | responsible for working with the development teams to communicate the 11 | current status of development progress with the community and with any 12 | partners. In essence, it may be thought of as a "public relations 13 | department" of sorts. 14 | 15 | ## Motivation 16 | 17 | This team is needed because developers would rather focus on development than 18 | on public relations, status updates, announcements, or team to-do lists. 19 | Historically, this has been managed by the Community Team as a whole. 20 | However, communications don't fall within the realm of the current Quilt 21 | community team, and thus this should have its own separate subteam. 22 | 23 | ## Explanation 24 | 25 | The Outreach Team will be responsible for all communications outside of and 26 | within the Quilt Project. This is difficult to define without providing 27 | specific examples, which include: 28 | 29 | - writing and publishing blog posts and announcements 30 | - managing the official QuiltMC social media accounts, with the exception 31 | of forums and chatrooms 32 | - managing relations with other platforms and communities outside of a 33 | moderation context 34 | - writing and publishing general status updates on the progress and 35 | development of Quilt 36 | - assisting in management of public development boards and to-do lists, 37 | including GitHub project boards 38 | - managing the content of the website, not including the functionality 39 | - leading and creating agendas/minutes for developer meetings, alongside the 40 | events team 41 | 42 | ## Drawbacks 43 | 44 | This team in and of itself may still be too broad, depending on how it is 45 | approached. It may be split up into several subteams, including a blog team 46 | or a social media team. 47 | 48 | Relations with external communities may already be covered by the 49 | responsibilities of Community Managers and the community collaboration 50 | program. However, the community collaboration program is supposed to be in 51 | more of a moderation and community safety context, whereas the outreach 52 | team would not be handling this. 53 | 54 | ## Rationale and Alternatives 55 | 56 | Most of the responsibilities outlined for the Outreach Team are already done 57 | by the Community Team. The scope of that team is too wide, however, and 58 | these responsibilities do not necessarily fall within the its intended scope. 59 | 60 | Similarly to the separation of community and developer teams, separation of 61 | concerns in the form of a outreach team is a necessity because this is 62 | currently an underdeveloped area. Without a separate team for it, 63 | communications and outreach are always going to be an issue within the Quilt 64 | Project. 65 | 66 | ## Prior Art 67 | 68 | The concept of a [public relations][PR] department in a company or organization 69 | is a rather common one. The Outreach Team is intended to fill this role. 70 | 71 | [PR]: https://en.wikipedia.org/wiki/Public_relations 72 | [RFC6]: /structure/0006-governance.md#teams 73 | -------------------------------------------------------------------------------- /structure/0054-quilt-kotlin-team.md: -------------------------------------------------------------------------------- 1 | ## Summary 2 | 3 | The Quilt Kotlin Team will be responsible for developing and maintaining the 4 | Quilt Kotlin Libraries (Henceforth QKL). QKL is set of libraries, built off of 5 | QSL, intended for use in the Kotlin programming language. 6 | 7 | 8 | ## Motivation 9 | 10 | Giving developers an official way to use Kotlin on Quilt, as well as providing 11 | wrappers for QSL and the Minecraft codebase for easier use in Kotlin. 12 | 13 | 14 | ## Explanation 15 | 16 | The Quilt Kotlin Team will be responsible for reviewing pull requests, 17 | designating new modules, developing, and maintaining QKL. It falls under RFC 18 | 0018 (Technical Teams), and will follow the same standards defined in the RFC 19 | 20 | 21 | ## Drawbacks 22 | 23 | ### Versioning 24 | 25 | Versioning could be a hurdle, as QSL, Quilted FAPI, and Loader all use 26 | different versions, and having a fourth could be confusing for the end user. 27 | 28 | 29 | ## Rationale and Alternatives 30 | 31 | ### Subdivision of QSL 32 | 33 | QKL shouldn't be a subdivision of QSL, as QSL is based on Java, it'd be 34 | difficult for maintainers who don't know Kotlin to be able to maintain QKL. 35 | Having QKL as a subdivision of QSL would mean that changes in the respective 36 | QSL modules would have to be copied to the QKL module before merging. This is a 37 | bad idea, because it forces everyone to know Kotlin to be able to contribute. 38 | 39 | 40 | ### Kotlin CHASM frontend 41 | 42 | Once CHASM is added to loader, QKT can start work on a CHASM frontend for 43 | Kotlin, which is one of the main reasons for this RFC; A CHASM frontend is more 44 | than would normally be in a language adapter, which means QKL will need more 45 | special treatment. 46 | 47 | 48 | ### But Kotlin has Java interop? 49 | 50 | Kotlin's interoperability with Java is just that, interoperability. There are 51 | some concepts that work well in Java, but not Kotlin, and vice versa. Extension 52 | functions and DSLs don't exist in Java, and with this we'd provide 53 | quintessential ones for modding in Kotlin. 54 | 55 | 56 | ### Non-QSL/Minecraft libraries 57 | 58 | Non-QSL/Minecraft (Third Party) libraries won't need wrappers for Kotlin, as 59 | they are not the responsibility of Quilt or QKT. Wrapping Third Party libraries 60 | would also cause some sort of favoritism to be seen in the project, and we 61 | don't want to show favoritism for Third Party projects 62 | 63 | 64 | ## Prior Art 65 | 66 | Fabric Language Kotlin is a library for using Kotlin on the Fabirc platform. 67 | It only provides the Kotlin stdlib, and Kotlinx libraries, while QKL will also 68 | provide wrappers for QSL and the Minecraft codebase -------------------------------------------------------------------------------- /structure/0068-qsl-teams.md: -------------------------------------------------------------------------------- 1 | # QSL Teams 2 | ## Summary 3 | This RFC establishes and defines the structure, roles, and responsibilities of the QSL teams. 4 | 5 | 6 | ## Explanation 7 | The QSL Team is made up of three subteams, QSL Core, QSL Triage, and Quilted Fabric API. One cannot only be a member of the "QSL Team", they must also be a member of at least one subteam. 8 | 9 | New subteams can be created by the QSL Core team by amending this RFC. 10 | 11 | ### QSL Core 12 | #### Responsibilities 13 | The QSL Core team is made up of the main maintainers of QSL. They have the final say on the direction of the project, and have admin access to all QSL repositories and end-user distribution points (i.e. Modrinth, CurseForge) of QSL, QFAPI, and any other QSL team projects. 14 | #### Joining the team 15 | The QSL Core team can add new members to itself by unanimous consent of all active members of the Core team. 16 | 17 | ### Quilted Fabric API 18 | #### Responsibilities 19 | The Quilted Fabric API team is responsible for the maintenance of the QFAPI project. They operate under the advice and consent of the Core team, but have full admin access to the QFAPI repository and its end-user distribution points. 20 | #### Joining the team 21 | New members can join the QFAPI team by unanimous consent of all active members of both the Quilted Fabric API and QSL Core teams. 22 | 23 | ### QSL Triage 24 | #### Responsibilities 25 | The QSL Triage team provides triage, reviews, and testing for QSL. Members of this team are not given permission to push directly to the main QSL branches, but are given enough permission to carry out their repsonsibilities. 26 | #### Joining the team 27 | New members can join the QSL Triage team by unanimous consent of all active members of the QSL Core team. The Core team should check with the QSL Triage team before accepting new members. 28 | 29 | ## Rationale 30 | (note: this section might not include rationale for later updates; see the original version of this RFC for context) 31 | This RFC mostly defines the unspoken status quo that already occurs between the QSL teams. The major difference is the removal of library-specific subteams. This change was made for the following reasons: 32 | 1. **Efficiency**: There simply weren't enough interested members to require subteam reviews on each PR. Either teams would be unfilled (defaulting to the status quo this PR defines), or be stuck waiting on one specific person to review the PR. We didn't see any benefit from this system over the downside of slowing down PRs. Additionally, we found that QSL subteams did not end up taking the responsibility of each porting their own library; it was simply first-come, first-serve, or often done all at once by a QSL Core member. 33 | 2. **Interest**: Because of the efficiency problem, joining a QSL subteam involves accepting a lot of responsibility. Filtering everything out to the top level reduces the amount of perceived pressure put on new maintainers of QSL; they can pick and choose which PRs they want to adopt over every part of QSL 34 | -------------------------------------------------------------------------------- /structure/README.MD: -------------------------------------------------------------------------------- 1 | # Structure 2 | This folder is for RFCs that define the governance structure of Quilt, or how Quilt is run. 3 | These RFCs are meant to be living documents and should be updated as the structure and governance of Quilt changes. 4 | --------------------------------------------------------------------------------