Rewrite rule 5, address issues with mixed-media section #10
Conversation
gdude2002
added
documentation
What case-by-case basis exactly? Yes - the client ideally needs to be transparent, but does it need to be transparent to servers who hide their own plugins and brand as well? |
|
Yes. Servers may have good reasons to hide their brand. Clients don't. |
|
The main reason I can think of for clients hiding parts of their identity as part of an acceptable goal is for tools like viafabric, which act as a compatibility layer between the server and client, whichever has the mod installed. Overall though, the main reason one would do this is to hide cheat/utility mods from the server. On the other hand, it could be argued that a server hiding its brand and other info from the client may be important for the sake of security. |
|
@gdude2002 given that hacked clients are not allowed by these rules, hiding your brand shouldn't be that much of a concern right? Those clients aren't allowed anyways. |
|
Problematic mods often exist in isolation as well, and I don't think clarifying this directly is problematic - do you feel that it is? |
|
No I don't, hence my question: What case-by-case basis exactly? |
|
I believe I already answered that question? |
|
Yes. |
|
Alright then |
|
Though I do wonder why exactly my message, was downvoted twice. |
|
Presumably, because those people disagree. Wouldn't read too much into it - heck, one of those people already responded here. |
|
Alright 👍 |
src/_community/rules.md
Outdated
| Microsoft, Discord and any other community platforms we use | ||
| * Projects must not hide their functionality, and should be upfront with what they do - however, projects with | ||
| unfinished documentation or benign "Easter eggs" do not violate this rule | ||
| * Projects must not give players an objective advantage over other players in a multiplayer setting, unless they |
There was a problem hiding this comment.
This wording dictates what mods should be - ç'est ne comme il se pas doit. Also, the beginning and the end/subpoints list kinda diverge in meaning. I would rewrite the beginning focusing on cheats specifically rather than this deterministic catch-all
There was a problem hiding this comment.
It's intent I believe is to avoid pay to win mods
There was a problem hiding this comment.
Aside from the last sub-point (which is down there for a more sensible layout), the list of sub-points has been sorted alphabetically.
I have no idea what your review comment is supposed to mean, honestly - what's your specific criticism?
There was a problem hiding this comment.
The rule itself is about cheats. But the first sentence is too catch-all and by its wording deterministic, i.e. tries to rule the contents of mods, which is unacceptable IMO
There was a problem hiding this comment.
I can't think of anything controversial or unacceptable about regulating the content of mods that are allowed to be shared within our community spaces - perhaps you're conflating this with a general acceptable use policy for the project itself?
We can't really dictate how people use the toolchain, nor what types of mods people write with it - but there's no reason we can't define a set of criteria that we require mods to meet, should they be promoted in our community spaces.
There was a problem hiding this comment.
The fact that it's resolved doesn't mean it's irrelevant
The resolution both pointed out the lack of a perfect solution, and a myriad of possible approaches. You may disagree with those approaches, but that doesn't really relate to your specific point.
That's not true. We all know what an insult means, but when Russian govt used the term in the law it led to police spamming pointless "insult" lawsuits to scare people. This is a far-fetched, but eloquent example that widely accepted definitions aren't enough to make a solid rule
I agree, this is a far-fetched example. That said, as a long-time community manager, it wouldn't be in our best interests to approach the community with bad-faith takes. We're also not necessarily a group of people with some kind of grudge against "utility"/cheat mods.
No, my solution is simply different from yours and you disagree with it. You can and should build an exhausting list of everything. That's how good law (rule) works. You can always expand or edit the list
Exhaustive lists open up loopholes for people to try to abuse. Catch-all statements mean you can address issues as they crop up. It's a simple concept, really - the fact that cheat mod developers are now using "utility mod" to describe their projects is a perfect example of people trying to do this.
Additionally, it's unreasonable to expect us to update the policy every time the cheat-mod community comes up with a new term or a new tool. We have more important things to be doing here.
It's worth pointing out that this rule was worded in a way that would allow "utility"/cheat mods to exist in our community, provided those tools made good-faith attempts to cooperate with server administration teams. This is a different approach to some other communities, which ban all mods that provide any advantage, aside from a small list of categories that they like personally.
There was a problem hiding this comment.
I understand the rules update sentiment. Considering that, there's only one thing left in my point: the opt-in/opt-out detail. If my previous wording is unacceptable to moderation team, then i suggest this wording:
Projects must not give players an objective advantage over other players in a multiplayer setting,
unless they provide mechanisms for servers to disable their features, preferably opt-in over opt-out.
Such features include, but are not limited to:
- <...>
There was a problem hiding this comment.
I'm not personally comfortable with opt-out being the "norm" for the stuff we had listed - stating "preferably opt-in" is essentially pointless, as developers can easily just pick opt-out every time.
While it is more difficult for vanilla servers to provide a comprehensive opt-in system, requiring this at least provides some extra security - allowing everything to be opt-out instead means that vanilla servers have no recourse unless they've done the specific research they need to do to opt-out before the tools are used on the server.
There was a problem hiding this comment.
I get your point, but I won't change mine. You can consider this resolved, though I would prefer a few more people to see this discussion
There was a problem hiding this comment.
Alright, I won't mark this resolved for the time being - people are free to weigh in on this until the deadline.
|
What about mods such as JS scripting APIs? Should a |
APIs aren't user-facing and don't operate without some external interaction of some kind, so I don't see how they're problematic when it comes to this |
|
I'm talking about mods where users are the ones who write the scripts |
I don't think that'd be a problem, but users shouldn't be allowed to share scripts that otherwise break the rules |
|
Here's a new render as of the latest push. |
|
I think that mods that seedcrack should be specifically named in the rules. They are a kind of hacks but many people don't see it that way. But it is a hack and can really mess up servers |
|
i agree |
| developed or promoted **in all Quilt community spaces** must meet the following criteria: | ||
|
|
||
| * Projects must not be malicious - which includes (but is not limited to) malware, mods that include backdoors, mods | ||
| that modify Quilt in an attempt to hide themselves from servers they connect to, or mods that harass specific people |
There was a problem hiding this comment.
Can see a problem here - what about mods that kick people without a certain permission at spefic times?
There was a problem hiding this comment.
I wouldn't consider that harassment - this rule is about mods that, for example, hardcode UUIDs to kick from all servers for a grudge, or that provide a back-door that allows the developer to shut down a server.
The example given is here for brevity - security mods are fine.
|
if we aren't allowed to discuss cheats, then we won't be able to discuss cheats in good faith after this rule is passed. |
|
meaning stuff like this pull request will be an instant ban, and anyone opposing the rule that discusses cheats will be banned. |
Which paragraph mentions it? Scanning through some of the potential keywords I am not able to find any phrases and even after reading that a bit more carefully I cannot see that getting mentioned |
You're not allowed to promote cheats. Your interpretation isn't part of the rules, although I do think that a group suddenly joining the Discord server just to "chat" about a cheat client would probably be reasonably assumed to be a promotion. Either way, we're not banning discussion outright, that'd be silly. |
It would've saved us a lot of time if you had said that at the beginning! Promote is a very vague term, I personally was worried about discussion being banned (although if that was deemed necessary to abide by Discord's TOS I'd understand) |
|
The specific thing they don't like is:
...which is vague as heck, but I think academic discussions are okay. |
You don't have to support it, but you should acknowledge that there are situations where spoofing is useful. I could easily see an inexperienced server admin telling users to spoof their modlist rather than fixing their own server configuration. |
|
There is a technical term for those sorts of admins, ahem, "fucking idiots". Especially given that no mods are blocked by default, so they'd have to explicitly block them. We don't need to cater for them. We won't be encouraging spoofing because the much, much, much more common usecase is to get around an intentional block on a mod. |
And this blocking would be done by the use of some mod like Walled Garden, right? Not a Quilt embedded feature? If so, then I don't see the point of continuing this discussion, but if it's embedded in Quilt, I'd want to have a discussion about that, though this doesn't seem like the right place for it. |
|
I don't think the current plan is to include this in any official quilt mod, correct. You would have to use 3rd party software to block mods, and probably different software for different platforms (e.g. on a Spigot server you would have to use a Spigot plugin). |
I don't think this is a good approach I believe some kind of handshake should be included in the Quilt client and then a server can do whatever it wants to do with it. As a server owner its hard to force everyone fabric (Quilt) because some players also want to play vanilla. A handshake (modlist being send to server) is the only real way to protect your server against mods that you don't want on your server. |
|
Did you actually read what I said? The Quilt client sends the mod list, but there are no officially supported server-side mods to do anything with that list. |
That is exactly what was proposed. |
My bad misread it. What you are saying would be the perfect solution! |
|
I am just sending this so I can say I sent message #200 in this PR |
| #### 5) Keep all projects legal, legitimate & appropriate | ||
|
|
||
| While anyone may make use of the Quilt toolchain in accordance with the licenses applied to each project, all projects | ||
| developed or promoted **in all Quilt community spaces** must meet the following criteria: |
There was a problem hiding this comment.
I know that someone said to emphasize this bit, and I agree with that, but perhaps say "in all official Quilt community spaces" to make it clear that some unofficial Quilt community space wouldn't be subject to these rules. I know that it's pretty obvious but some people, namely me, are dense and might not get that.
There was a problem hiding this comment.
Well, there are two things here.
- It doesn't really make sense for people to assume these rules will be applied outside the places the community team watches over
- Unofficial communities run by Quilt team members (like the IRC channel) and potentially other Quilt-related communities are welcome to make use of the same policies, so specifying "official" here would likely result in the same rules-lawyering you're implying, haha
For those reasons, I don't think this is a pointful change
Well, I presume it will be just as easy to spoof the modlist as to implement checks against it on the server. Either way, I would appreciate if people who develop software that uses the modlist handshake to kick players, to make it really hard to screw up the config. |
I can already think of a nice UX for it, but I likely wouldn't be the one writing such a tool anyway |
|
Thanks for participating in this, everyone - I think we ended up with a much better setup than what came before. |
This pull request represents a significant rewrite of a portion of our ruleset.
Rendered view, with changes highlighted
The section that states, "Do not change your avatar, nickname, username or custom/rich status to try to protest a moderation action," has been changed to the following:
Rule 5, "Keep all projects legal & appropriate", has been completely rewritten as bullet points, which now include malicious and misleading mods, and a policy regarding cheat mods and how they may be made acceptable
This pull request exists as a way for the community to provide feedback and ask questions before the policy changes are implemented. If you'd like to provide feedback or discuss this PR, feel free to do so via a review or by leaving comments below. If you'd rather discuss things in real-time (or you don't have a GitHub account), feel free to chat in
#discord-metaon the community server instead.This pull request will conclude on Thursday the 29th of April, at 1PM IST (UTC+1). At that point, the pull request will be locked and, assuming there are no serious concerns that are left unresolved, the pull request will be merged and the policy changes will be implemented.