The Fabric Feature Procedure
So you want a feature to enter Fabric? Well then - here's a brief guide on how to best propose a feature in a way which won't get lost in noise and give some measurable results.
We don't tend to ban people just for having ideas, no matter how outlandish. However, “no” can mean “no”, and unconstructive responses to constructive arguments can get on our nerves after some time. We are generally unpaid volunteers who dedicate a lot of free time to the tiring job of social interaction - please don't make our work harder than it already is.
We're here to help each other learn, after all. Don't hesitate to talk to us at any point!
Fabric isn't easy to get your content into, as we uphold standards of quality and are very paranoid about making a bad precedent. You will be scrutinized again, and again, and again; you will be asked questions about more-or-less every line in your pull request (even the imports!). Don't believe us?
When should I aim for Fabric?
There are many projects in the Fabric toolchain, and all of them welcome different types of content (when in doubt, ask us in chat!):
Projects like Enigma, Stitch and tiny-remapper have a well-defined scope - they're tools dedicated for specific purposes.
Projects like Matcher, Procyon, Fernflower, etc. are forks of existing upstreams - try getting your changes accepted there first.
Language shims, such as fabric-language-kotlin and fabric-language-scala, are always welcome! Standardizing on them is generally a good idea for everyone involved.
fabric-loader is the mod loader. Features added to it generally revolve around the scope of mod loading - configuration, versioning, code modification mechanisms, security, the scope of supported environments, etc. - and never impose a dependency on specific game version code.
is the API
module. Features added to it can be put into one of two categories:
Hooks, which expose ways to utilize functionality hardcoded, package-private or otherwise not exposed in vanilla code,
and Interop, which adds mechanisms to improve mod interoperation (within the scope of vanilla constructs - so no things like custom power systems, etc).
In any case, fabric features are encouraged to follow the “majority rule”. As we wish to track versions quickly, we are not keen on maintaining features only necessary by a small fraction of mods as part of mainline. We are somewhat more lenient with regards to patches which cannot co-exist - that is, a hook or patch which can only be applied by one mod at the same time.
However, if your idea doesn't fit on the above list, fear not! There are other ways to share your standard with the world:
Make sure it's worth it
In short: Ask someone more knowledgeable in chat if the idea is even worth pursuing for Fabric. This can be skipped, of course - if you don't mind wasting a bit extra time in exchange for wider insights.
Open an issue
Yes. Open an issue. Like, on the relevant GitHub project. We do often miss chat messages, etc. - while they're fine for initial surveying and discussion, they're not fine for keeping a track record.
Wait for input
(cue all developers arguing for 100 comments on the meaning of a 5-line patch)
Just wait until a clear direction/design is decided upon.
Create a pull request
Now that you know what to do, put it into code! (Of course, the issue creator and the pull request developer do not have to be the same person. If you're lucky, one of the devs might even do the ground work for you!)
Wait for more input
(have you met Player yet?)
Rejoice. Your feature is now a part of the Fabric hype train.