[RFC] Allow Mojang Mappings development in a dedicated channel

[Technici4n]

Proposal

Given the current popularity of mojmap (Mojang Mappings) for Fabric modding, I don't think it's fair to exclude it entirely from the server. I suggest that we introduce one new channel: mod-dev-mojmap. Thanks to discord's onboarding feature, we can make it hidden by default, and users will have to opt-in. It's hard to estimate how much traffic it would get, so I suggest that we start with one channel for now, and possibly extend it in the future. Would like to hear everyone's thoughts.

Background

My goal is to give developers who are using mojmap a channel where they can get help, I am not suggesting that Fabric API switch from yarn to mojmap or yarn be abandoned in any way.

I will also stress that we cannot allow mentions of mojmap in all channels as it would threaten the yarn cleanroom.

And now, a few reasons to use either set of mappings, for background - there are valid arguments for both:

Reasons to use mojmap

• Full coverage of methods and fields at all times, even snapshots.
• Arguably stabler mappings because they cannot be changed by the community.
• Multiplatform mod development: Forge and ForgeGradle only support mojmap.
• Arguably better names because they reflect Mojang's intent. (Can also be a drawback: names can be misleading).
• Other personal preferences.

Reasons to use yarn

• Arguably better names because they reflect what the code is doing. (Can also be a drawback: names can be misleading).
• Constant unpicking.
• Names can be changed/improved by the community.
• Legal concerns regarding the use of non-free mappings.
• Contributing to mappings, especially for new snapshots, can be fun.
• Other personal preferences.

Note: While mojmap doesn't include method and parameter names, parchment exists to provide that on top of mojmap. Hence I have not included this as an advantage for yarn.

[Shnupbups]

Other reasons to use Yarn include parameters and javadocs :)

It's worth noting that both myself and apple are avid yarn contributors while also being Fabric discord moderators, and to properly maintain the cleanroom would have to avoid this channel, potentially leading to a lack of moderation in it compared to other channels... could this be an issue?

[Technici4n]

Other reasons to use Yarn include parameters and javadocs :)

There is parchment for that, so that's not an advantage in favor of either. ;) However, unpick is only available for yarn at the moment. I'll edit the post.

It's worth noting that both myself and apple are avid yarn contributors while also being Fabric discord moderators, and to properly maintain the cleanroom would have to avoid this channel, potentially leading to a lack of moderation in it compared to other channels... could this be an issue?

This is possible in theory. However the development channels usually require less moderation, and I think we also can't really know whether this is an issue in practice without trying it.

[TheCurle]

If you make the decision to move away from Yarn, then it may be worth pulling out the constant unpicking system into some other tools - we could make use of that system also.

Food for thought, perhaps.

[Technici4n]

The goal is not to move away from yarn for the time being, rather reflect that a lot of modders using Fabric are using mojmap. But we have/want to maintain the cleanroom, so yarn should remain the default choice, and mojmap should remain separate.

However I think that the constant unpicking system could be used by Forge/Parchment too, possibly with a separate unpick database. Here is an example from Fabric's database: https://github.com/FabricMC/yarn/blob/23w17a/unpick-definitions/set_block_state_flags.unpick. The system is already quite detached: https://github.com/FabricMC/unpick, but I am not sure how much glue is required to add it to a gradle plugin.

(By "database" I mean the data used to perform the unpicking).

[TheCurle]

Ah, I didn't mean to imply that you'd be removing Yarn entirely - allowing a different mappings set in the toolchain would mean that certain workspaces would have this unpicking and others wouldn't, determined entirely by the mappings set used. This may be confusing to people in support channels when referring to sections of code that now refer to integer constants.

Unpicking, at its most basic level, isn't a function of the mappings set, but rather a system used in the creation of such.

Pulling that out to be generic and available to every mappings provider, is what I was talking about.

Perhaps it would be easier to discuss this more in-depth on the Discord.

[Juuxel]

allowing a different mappings set in the toolchain would mean that certain workspaces would have this unpicking and others wouldn't, determined entirely by the mappings set used

This is already true since all tooling allows for different mapping sets. Mojang mappings don't have Unpick definitions when used by modders.

[zml2008]

I'm glad you all are finally joining the world of the sensible :) I do agree though, it would be nice to work on getting a set of unpick definitions into ideally Parchment or perhaps an associated project for us to all use

[Juuxel]

Yeah, it'd be nice to have unpicking available for everyone. Also note that Yarn's unpick definitions can't be reused fully even if they're modified to use Mojang names – some of them reference Yarn's compile-only constant holder classes.

[zml2008]

If it makes sense, couldn't some of those constant holder classes also be added to Parchment with different naming?

[Juuxel]

They're free to use under CC0 and are just lists of fields, so that would be both allowed and very simple. See for example LlamaVariants. (The other classes are similar)

[TheCurle]

Perhaps it would be worthwhile to have a separate issue or discussion for the matter of unpicking. This isn't quite relevant to the topic of the issue at hand, and I don't wish to clog up relevant discussion too much.

[modmuss50]

Personally I am less concerned about keeping yarn a pure "cleanroom". Yarn was originally developed as a clean room to protect against MCP's strict ARR license at the time. However I think its impossible to be a cleanroom from mojang's own names, and not worth the effort (If mojang wanted to stop us, they could have done years ago in 100 other ways).

We already use mojang's own names that are also plastered all over the codebase in strings, records and what not. (Technically not under the license of the mappings, but close enough)

Im not suggesting we start accepting PRs that are 1-1 copy pastes of mojmap, nor accept PRs that are only possible with mojmap (unmapable constants). I do think we can be less strict about it, and not worry if names are inspired or accidentally copied from Mojmap.

Thus I propose we allow the talk of Mojmap in the discord/github (expect yarn github). Yarn contributors wont need to be fearful of reading conversations (It's highly likely yarn will already have a name for it anyway).

Unpick is something we can easily solve 👍

[NebelNidas]

Allowing Mojmap names on Fabricord but requiring them to be put behind a spoiler would also be an acceptable solution IMO

[SHsuperCM]

My opinion on the matter is that like how the fabric discord communicates in english as a common language, we have to have only one mapping in nornal discussions.

The only exception I could see this working in is if we had a mod-dev-other-mappings channel where people would have to state their mapping before seeking assistance.

This would keep the other channels in yarn as well as allow for users of different mappings(not just mojmaps) to ask for help on the discord.

It should also be considered that the main advantage(at least in my opinion) of yarn is that it is spoken by the people who provide help in most dev channels on the discord and for that reason it should be encouraged.

[ZeroNoRyouki]

From what I see in #mod-devX, the people that use mojmaps in their questions don't even know that they are doing it most of the time or they don't know that rule 8 exists (and let's skip the ones that don't even look at the channel list to begin with). The majority of them will still ask in #mod-devX and be told to move to the new channel, so a major waste of time.

There is no enforced yarn cleanroom, and rule 8 don't stop a contributor to come up with a mojmap name on its own, it actually make the situation worse because if the goal of rule 8 was to protect yarn, then discovering that "ABC" is a mojmap name would let the contributor do a better job at NOT using mojmaps names in yarn. And an automated tool that rejects mojmaps names from contributions will solve the problem once and for all.

So, just drop rule 8

[apple502j]

Note: this is my own opinion and not moderator's opinion.

Dropping rule 8 is a good suggestion. Here's why:

• Since over 90% of methods/fields (and probably over 99% of the stuff that appears in the dev channels reguarly) are mapped, I doubt there would be a contamination problem.
• It's also questionable whether the copyright problem actually exists. The Supreme Court did not answer whether names and packages of Java methods or classes can be copyrighted in Google case, however the fair use argument is strong. Also, I participate from Japan, where API cannot be copyrighted at all.
• Rule 8 is also originally designed for MCP (which I heard regularly enforced the license). MCP is discontinued, relaxed its policy, and rarely comes up in our chat. Like, did someone write a MCP name this year?
• The two active moderators - me and Shnup - also happen to be the top two Yarn contributors in recent months. Enforcing rule 8 would not be a good idea for them.
• I don't look at #mod-dev very often.
• Other mod loaders never received a cease and desist - even though some literally use Mojmap or name things based on Mojmap.
• Our moderator resource should be spent on combating transphobia and generally rude behavior, not some technical violation that is not proven to actually cause harm.

[Technici4n]

Copy-pasting Player's message:

The rules were updated to allow using proprietary mappings outside influencing yarn development (don't use them to argue around yarn naming)