User:AttemptToCallNil/Problematic arguments

This page lists arguments that I consider inappropriate, yet recall seeing in conversations. This is in addition to typical logical fallacies and a substantial portion of Wikipedia's "Arguments to avoid" pages (though see below).

Are you sure this is necessary?
Shortcut: What will you achieve when you ask people to question their own actions without telling them of any specific issues? Yes, it may result in nothing but that they find a couple issues and fix them. Or not a couple, but a lot.

Or it may result in that they start doubting their own actions so much that their view slowly and subtly shifts to the opposite one. And instead of finding a balance between the two extremes, they start doing a lot of damage by irrationally rejecting themselves. Also, great job probably making them need assistance from a mental health specialist - and not getting any assistance because these "specialists" are actually taught to aggravate such problems instead of resolving them.

Actually, in some cases, it's the latter result that is the intent of the doubt-inducer. It may be difficult, if not impossible, to distinguish between: 1) a well-meaning proponent of a less common point of view, and 2) a bad-faith actor who wishes to convert others to their point of view.

Your point will be heard much more clearly if you not just ask another "are you sure this can't be made better", but inform them of a specific, actionable issue they should be able to address.

Very problematic example:
 * Your wiki has too many overcomplicated templates. Most of them aren't really needed. -- (talk)
 * Do you have any specific suggestions? --I never  (talk?)
 * the thread never receives another comment

Problematic examples: (Says nothing about how to answer that question.)
 * In general, when you're looking at something more complex than a wikitext template a couple of lines long, you should ask yourself, "Is this really needed?" --Never be certain (maybe talk)

(A slightly different form of this issue where the question is asked implicitly. Also makes apparent how this issue relates to demands of perfection.)
 * Only submit changes when you're absolutely sure they don't contain a single mistake. --Perfection is achievable ( talk )

Non-problematic example:
 * You have a lot of modules and complicated templates on your wiki, have you tried taking a look through them and checking whether you need all of them? For example, this one template is implemented as a module, yet if you removed this one functionality you actually never even use, you would be able to replace the module with just a couple wikitext parser function calls. --Linter (talk)

Change is hard!
Shortcut: Yes, change needs to be adjusted to. Yes, adjusting to change can be difficult. No, difficult change is still something to avoid.

When someone says they find the change too hard, they may mean they think it would have been better to avoid the change at all, or perform it in another, less difficult way. Correct, some change needs to happen, and is inevitably very difficult. Just referring to a general principle isn't helpful.

Future and imminent change is even worse when it is known to be massive, yet its specifics are unknown. Here's a slightly modified quote of a message I posted on the Fandom/Gamepedia Discord some time ago:

Change is less scary when you know you can adapt to it and use it to make your life better. However, if you suspect that some change may make you less necessary or not necessary at all, it is not just scary. It goes well beyond that.

It is the difference between evolution of a job that makes it a more pleasant experience, and evolution of a job that replaces a part of workers with machines. If that job was one of the most major parts of your life, and you are in a situation where there will be nothing to replace it, you, as the entire person, become an acceptable sacrifice to this merciless implementation of progress.

And from the perspective of so many people, there is nothing wrong with that.

Using "change is hard" to justify any hardship is similar to an even worse issue. It happens often that "you can't have both". That doesn't mean such sacrifices are anything other than bad. That doesn't remotely justify demanding another party to choose something they will be artificially denied because "they can't have both".

Problematic examples: A thought-terminating non-answer. So many people seem incapable of anything more.
 * Why did you have to make this new rule? Now hundreds of users will have to rewrite their user pages to conform to the new structure. --Struct By Lightning (talk)
 * What did you expect? Change is hard. --BrownianMotion (talk)

Purely artificial choice of what to sacrifice. It is absolutely possible both to keep a permissive signature policy and enforce some accessibility standards for the more reader-facing parts of the wiki.
 * Well, you can't have both: either we force everyone to use standard signatures with no changes, enforced by progressive blocks on each use, or we repeal the accessibility standards for articles and templates. --There Are Two Chairs (talk)

Less problematic example:
 * Why did you have to make this new rule? Now hundreds of users will have to rewrite their user pages to conform to the new structure. --Struct By Lightning (talk)
 * The only real change this new rule actually introduced is a ban on highly controversial statements on user pages. Almost all currently existing user pages are already compliant. --TakeItElsewhere (talk)

It just works!
Shortcut: Many people, when discussing problems, propose solutions that they know to work. These people may even suggest others don't try to use complex logic to derive a satisfactory solution; a good solution is stated to be already available.

Except nothing "just works". First, "it works" needs to be defined. And it will probably turn out there are multiple definitions of "it works", not all of them reconcilable. Second, even assuming a definition of "it works" is chosen, there is a mechanism that makes things "work". Trying to understand this mechanism is important for making better solutions. Perhaps it can be made to work better? Perhaps it works, but causes an undesired side effect that can be reduced or eliminated? Perhaps it doesn't even work, but only gives an illusion that it does? Perhaps it actually deals great harm to what it's stated to help, and what actually helps is resistance to this solution, which most people believe is the source of the damage caused by the solution itself?

It is most useful to define specific goals and regularly perform in-depth analysis of used tools to ensure that the tools serve the goals optimally. What is it some people are trying to accomplish by telling others that they shouldn't seek better understanding of what they want and how they achieve it?

Problematic example:
 * What are you all arguing about? It's obvious Solution X is what you all really want, any experienced person knows that it works! --I am very experienced (talk)

Non-problematic example:
 * I think Solution X works for both of you: it solves Problem A by [explanation], and it bypasses Problem B entirely through [explanation]. --One who catches both hares (talk)

That's just the way it is!
Shortcut: When some party imposes its will on another, no matter who or what these parties are, they are humans or human constructs. They are not forces of nature, they are not deities (all of which are most likely human fabrication anyway). The party in control has its own interests, at best orthogonal and at worst diametrically opposed to those of the parties they control. The party in control, like any finite system, is fallible, and will not use optimal strategies to reach its own interests.

There are many phrases that don't have a proper structure and are only used to interfere with constructive discussion and suppress unwanted opposing opinions. Such phrases are known as thought-terminating clichés. They carry no meaning beyond telling others "Stop thinking in ways we don't want you to!" - while making this statement indirect and therefore deniable. Because of this, there will be only a few people who can see that the one saying it is acting in bad faith. The majority won't recognize the issue, and because of that they will be used by the totalitarian entity to crush dissent.

"That is what it is" is one such thought-terminating cliché. Those willing to use it are some of the most destructive people around - and unfortunately, it's likely some of them are well-meaning, but beyond the line of Gray's law.

Problematic examples: (Note that the second part of the CM's statement introduces a false dilemma.)
 * This article loads so long on my internet connection because of all those ads and five megabytes of tracking cookies! --Sincerely, a concerned citizen (talk)
 * I'm sorry, that's just the way it is. Would you prefer we removed all these ads and tracking, only to become unable to pay our bills in a couple months? --Wallace Breen [Community Manager] (talk)

(1. See also . 2. The admin's username also violates the 3-digit rule; this is an intentional part of the example.)
 * Why would your rules tell people they're not allowed to use more than 3 digits in their usernames? That harms nothing, as you can see by that I've been a successful admin on the Russian Terraria Wiki for over 6 years. --Fahrenheit0451 (talk)
 * The rules are what they are. If you don't agree with them, stop using the wiki. --Best Admin of 2017 (talk)

Thought-terminating clichés are often accompanied by other problematic statements.

We need to have rules! (The ones we have now.)
Shortcut: I am a strong proponent of the "Ignore all rules" principle. No, I am also a very strong opponent of ignoring rules randomly. When you do something that may breach, or will breach, policy, there most definitely should be an extensive explanation as to why the breach actually helps serve the greater purpose behind the rules.

Of course, a perfect policy never needs to be broken to make an improvement. But perfect things most likely do not exist. Though it doesn't mean we should just say "meh, it won't be perfect, so why bother improving?" Rather the inverse, when we can make it clearer for everyone that some improvement is welcome, we should.

But it is not possible to think of a better version of a rule without some goal more fundamental than that rule. When someone tries to avoid setting such a more fundamental goal, we may end up with the kind of argument that is the reason why I wrote this section.

When a point of policy is being questioned, it is not meaningful to use that same point of policy to dismiss the concern.

Problematic examples: (Also potentially cyclic reasoning, if not reiteration, if upon inspection it turns out the meanings of "not allowed to do Q" and "should not do Q", as used in the second user's response, are identical.)
 * Rule N states we aren't allowed to do X, Y, and Z. But actually, what's the problem with Z? I've seen it done a couple of times in the last month, and from the looks of it, no one really thinks these actions weren't appropriate. --Descriptivist (talk)
 * Oppose: Rule N states we aren't allowed to do Z, therefore we shouldn't do Z. --Prescriptivist (talk)

(Just asking for this follow-up: "And it is prohibited because?.." Though people willing to make such an argument are unlikely to constructively address concerns about policy; they would rather suppress the questioning person with threats if not outright admin action.)
 * Rule N states we aren't allowed to do X. But what's the harm in doing X? It helps us avoid this problem: [description]. --Problem avoider (talk)
 * X is harmful because it is prohibited. --Order-Chaos binarist (talk)

(A variant that implicitly makes the improper statement "we need some rules, therefore we need these rules".)
 * Do we even need to have Rule N? The problem it's intended to minimize seems to be no longer relevant. --Modernist (talk)
 * Oppose, we need rules. --Ordnung muss sein (talk)

We have no obligation to do this!
Shortcut: When reading this section, you should keep in mind that I use the term "expectation" to refer to a sort of informal obligation.

Imagine a society where using obscene slang in public places is illegal. In this society, people have an obligation not to use such words in public places. Now imagine a society where there is no legal prohibition for obscene slang in public places, but it is still considered very rude by most people. In this other society, people no longer have an obligation not to use strong language, but from another perspective, people have an expectation that, when they're in a public place, other people: 1) will not use obscene slang; 2) expect other people to have expectations [1] and [2]. In this second society, using strong language on a street and dismissing a person who complains with "the law doesn't say I am not allowed to say this" would be considered very inappropriate.

Yes, there are many things you have no contractual, legal, or other formal obligation to do (or not do). However, in many cases, other people still expect that you do something are not required to. Using lack of a formal requirement as a first-resort response to a person stating their expectations is very disrespectful and doesn't contribute to community health.

Problematic examples:
 * Hey, could you please help me with [thing]? --I Need Help (talk)
 * I have no obligation to help you. --Give me freedom... or else (talk)


 * Hey, could you please explain your revert on [this page]? You left your summary empty. --I am undone (talk)
 * While I understand your confusion, ultimately I am not required to explain my actions to you. --Mysterious Stranger (talk)

Less problematic example: (note: I would have written it, not necessarily in these exact words, like "staff have their own lives and cannot be expected to perform noncritical tasks on weekends")
 * Any staff around? I need help with [thing] ASAP! --Now or Never! (talk)
 * You should realize it's Sunday, and staff have no obligation to respond to non-critical issues today. Yours can wait until their working hours. --Staff are people too (talk)

Not everyone is a (occupation name)!
Shortcut: When can a person be called a programmer? Is it when they start officially working as a programmer? Is it when they get their diploma from an educational institution? Is it when they write a program or a module no shorter than one thousand lines of code? Is it if they have worked in the industry for 5 years? Is it if they have a programmer's mindset? (What's a "programmer's mindset" even?)

Have you ever heard statements like "X is not really a Y if they're not Z"? Like "you're not really a programmer if you don't have a diploma"? It's very difficult to communicate with people who make statements like these.

See also the Wikipedia article on the "no true Scotsman" fallacy.

There is also the form when a term is redefined to refer to a subset of its original meaning, which may make it difficult to express that original meaning. Problems arise when a neutral term X is primarily used to refer to some Y that is also Z, where the term X is also the only neutral term to refer to some Y (regardless of whether it is Z or not). I am not aware of a more formally recognized name for this phenomenon, unfortunately. As such, I'll refer to it as "Z-constraining", with the condition Z being called a "Z-constraint".

Consider the first case, with the term "programmer" as listed above. Given 5 people who assert one of these Z-constraints each (so person 1 asserts the "officially working" constraint, person 2 asserts the "diploma" constraint, etc.), it is possible to reconcile them by providing a new definition with a Z-constraint that is the combination of all their Z-constraints. So under the new definition, "programmer" means "programmer[0] who has a relevant diploma, no less than 5 years of official employment experience in the industry, has written at least one program or module 1 kLoC or longer, and has the mindset of a programmer". ("Term[0]" is used to the original meaning, one without Z-constraints.)

Under this approach, the term "programmer" starts to refer to an increasingly small subset of "programmer[0]" that may eventually end up empty. Anyone who programs and does not meet the increasingly unachievable Z-constraint for "programmer" is likely to receive negative reinforcement through being called "not really a programmer" or other degrading terms. As such, my conclusion is that maintaining ever-growing Z-constraints is not acceptable.

Consider another case, with cats (but it's a really nasty case, so watch out). Imagine that in some culture, "cat" means "cat[0] of [some specific breed]". Cats of other breeds would be labeled "not really a cat" or even "defective cat" - and historically, there were periods where such cats could be subjected to legal or legally mandated violence - sometimes even along with their caretakers. Add that there are still radical groups that at best subvert efforts to eliminate this destructive practice. Now add several more cultures, each with their own choice of which breed makes a "cat[0]" a "cat".

Unlike with the "programmer" case, it is not possible to maintain a growing Z-constraint as individual Z-constraints of any two parties are completely irreconcilable. Traditionally, people were expected, if not required, to adopt the Z-constraint(s) of their ancestors and dehumanize everyone else. This, however, makes the world a battleground of parties uncompromisingly insisting on systemic violence and vehemently disagreeing on its specifics. I can't say this is remotely a world that's good to live in... and this leaves me with the last option I could think of: to abandon Z-constraints entirely.

Once again, I don't know whether there's a conventional name for this, but this approach of abandoning Z-constraints? I call it the approach of minimal definitions. Under this approach, a "programmer" is a "person who writes computer programs" - regardless of any specifics.

Why did I write any of the above, and how is it relevant in the scope of wikis? In several discussions regarding wikitext and modules, I recall seeing "not everyone is a programmer" as an argument for avoiding modules whenever at all possible. Using the approach of minimal definitions, however, the only way someone would become a programmer is by starting programming. The underlying argument is that some people are unwilling to learn programming, while wikitext-based templating, though very close to programming, looks just like the (overbloated) text formatting facility it is.

But that is subjective!
Shortcut: Why should there not be a system for appealing blocks by local admins? Because "bad block" and "bad admin" are subjective. Why is it better to just have admins determine every aspect of the wiki with little to no community input? Because wikis are not democracies, and community well-being is subjective.

Some people would have you think in these terms and none other. Though would these same people still voice their objections when staff stated they will revise the policies on appealing blocks by community admins?

If "bad block" and "bad admin" are subjective, then so are "good block" and "good admin". The hidden statement is the presumption that an admin's action against an ordinary community member is acceptable. To the point that some people say it is unacceptable to have a system that may override this presumption by checking admin actions and potentially judging some admin actions to be inappropriate.

Would the people who use this presumption also oppose tools that staff impose on admins to control or restrict their actions? There is no evidence to suggest they will. And if so, then the real problem become visible.

It's that so many people believe wrong can only be done by a person "below" to a person "above", much less (if at all) the inverse. On a related note, know what I think is a major reason older generations complain of declining morality? I think one major reason is that they liked to hold others "below" them accountable and punish them as they will, while not being held accountable themselves. And the fact they can now face severe penalties for wronging those "below" them – by their own standard of what's "wrong" – is not something they consider acceptable. In other words, elimination of a double standard is very much not favored by the party that liked the double standard and enforced it.

A poor approach to the problem of subjectivity is instruction creep. Yes, "excessive text color use" is subjective. Requiring people not to have more than exactly 100 colored characters in an article is not any better as the boundary is arbitrary. And there's very likely to happen a new and unforeseen use for text color overrides that needs more than 100 characters in an article without being excessive.

This thing is important! (So that one isn't.)
Shortcut: Often making one thing better makes another worse. Sometimes the improvement is significant, and the loss is small; other times it's the inverse. When someone proposes a change, they most likely believe it's an improvement. If there's a valid point not in favor of the improvement, the proponent may know of it and deem it insignificant, or not know of it.

An improvement remains an improvement at least in part even if it has negative side effects. At times people criticize proposals without even addressing the validity of the proponent's points. You should make sure that your criticism reads like you're adding new information to the discussion, and not throwing other information away without even mentioning it.

Problematic example:
 * Should we let our admins assign the "autopatrol" group to editors? We have only one bureaucrat, and he's not very active; we tend to make one to three editors autopatrolled each month, so it isn't that an infrequent task. --‼️‼️‼️‼️‼️‼️‼️‼️ (talk)
 * Never. Other wikis don't do this, and consistency across the network is important. --

Less problematic example: Note that the original factor is acknowledged (so performance isn't just "important", but "also important"). Also note that the significance of the factors for this specific case is evaluated.
 * I think we should rewrite this 12-line function with these three lines of code. It's much shorter and therefore more readable. --Longcat (talk)
 * They are, but I just tested, and your code performs 20 times slower. This module is one of the most commonly used ones on the wiki, and we can't afford slowing it down this much. Readability is important, but so is performance. --Small improvement, much damage (talk)

We're (not) like Wikipedia!
Shortcut: Minecraft Wiki is a wiki based on a rather modern version of the MediaWiki engine and maintained by a community of editors with the goal of creating a maximally complete and accurate information repository on some topic. In these ways, it's like Wikipedia.

Minecraft Wiki has a couple hundred active editors as opposed to Wikipedia's over 100,000 active editors. Minecraft Wiki has a few thousand articles and not a few million articles. Minecraft Wiki is hosted by a much smaller, for-profit company. Minecraft Wiki's topic is Minecraft and not real life. In these ways, it's not like Wikipedia.

With a large number of similarities and differences, just because something is used on Wikipedia (see note below) doesn't mean it will work great on Minecraft Wiki. Nor does it mean it will work poorly. A deeper inspection of the subject is warranted.

Problematic example: (That may go at length without addressing the actual issue...)
 * Let's make an arbitration committee, like on Wikipedia! --I <3 WP (talk)
 * Oppose, we're not Wikipedia. --I >:( WP (talk)

Non-problematic example:
 * Let's make an arbitration committee, like on Wikipedia! --I <3 WP (talk)
 * Oppose. We're a much smaller wiki, perhaps a hundred to a thousand times smaller. We do not need a dedicated structure to conflict resolution, as this is effectively our (much smaller) administration team. In addition, there is the wiki manager who is rather involved with wiki matters. --I <3 MCW (talk)

Extra note: there are things that Wikipedia does that aren't optimal for their own purpose. In particular, some technical solutions employed by the Wikipedia community have been said to be worse than those available (and regularly used) on Fandom.