User:AttemptToCallNil/Problematic arguments

When I have problems talking with people, being heard, getting my point across, I observe. I learn when I have these problems and when I don't, and I try to find out what causes these problems. Sometimes I'm unaware of some fact. Sometimes language doesn't let us reach perfect clarity. Sometimes the other party uses some cliché that harms constructive discussion.

Many patterns in communication are likely to cause problems. However, that doesn't mean they're rare; in fact, they're very common. Wikipedia has a list of fallacies and a list of arguments to avoid in discussions, but I feel like I can show just how these communication patterns harm productive discussion and wiki building.

Making the other party question their actions
Let's say you think someone else is doing something wrong, and you want them to change. You should say what you want, but if the other party can't implement your suggestion, you won't get what you want. If your feedback has a chance to result in improvement, it's called actionable. If your feedback can't result in improvement, it's inactionable.

Of the many kinds of inactionable feedback, I'll talk about two here:
 * 1) when you tell others to question the necessity of their actions, but they can't assess whether their actions are necessary;
 * 2) when you tell others to question the validity of their actions, but they can't assess whether their actions are valid.

By giving such suggestions, you make their target depend on others for evaluation of their actions. Note that this is also used as a psychological manipulation technique: make an opponent doubt themselves so much they let you "readjust" their behavior as you see fit. So if you don't want to be mistaken for a bad-faith party, you should tell people not just to check their actions, but how to do it.

Now how this all applies to wikis? It's known complexity in templates and modules is bad. It's known wikitext templates aren't as readable as Lua modules, but modules need an extra skill to understand and change. But there is no guidance on:
 * how to reduce the cognitive complexity of your templates and modules;
 * when to choose wikitext or Lua if both can work for a template.


 * Your wiki is full of overcomplicated templates. Most of them aren't really needed. -- (talk)
 * Could you please point out some templates you think we should replace? --I never  (talk?)
 * the thread never receives another comment

(Says nothing about how to answer that question.)
 * There's one question you need to ask yourself when you're writing modules or large wikitext templates. The question is, "does the wiki really need this complex thing?" --Never be certain (maybe talk)

(Here the question is hidden. "Are you sure your contribution is flawless?" Also note 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 )


 * 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)

Not really itself
"Wikitext templates are preferable to modules – after all, most wiki editors aren't programmers". "Why would I write Lua modules instead of wikitext templates? I am not a programmer".

The minimal definition of "programmer" is "one who writes programs". So even if you never wrote any program except for school assignments, the minimal definition will make you a "programmer" the moment your first module starts working in wiki pages.

But the minimal definition makes the two statements above invalid. They don't mention the option that a person can become a "programmer" through their own will, even if just for wiki editing. Sure, part of the problem is probably that wikitext doesn't look like programming (while being worse in many ways that Lua), and there is some psychological barrier to doing something that looks like programming.

If there is such a barrier, however, you should not encourage it (like in the first statement), but instead seek to help people overcome it. New editors of all kinds are essential for wikis, especially given how the very way of wikis is too collaborative to survive in the real world by itself for much longer.

However, it's possible there is also a second problem involved. People aren't always using minimal definitions. Sometimes definitions are, through ancient misconceptions or politically motivated psychological manipulation, encumbered with additional requirements beyond the minimal ones.

And if the definition of "programmer" is no longer minimal, when can a person be called a "true" programmer? Do they need to:
 * get a relevant diploma from an educational institution?
 * start their first full-time job as a programmer?
 * have worked as a programmer for no less than 5 years?
 * have a programmer's mindset? (What does that mean even?)
 * know C? Enough to have written a program in C? A program no shorter than 1000 lines of code? Not counting comments? Empty and whitespace-only lines? Standard library header s?
 * meet several or all of the above criteria?

And should a person fail to meet all of the additional requirements, whoever tries to call them a programmer may be told, "You're not really a programmer if you're not [additional requirements]".

"You are not really a wiki admin if you don't make 50 edits on the wiki every day." "You are not really a Minecrafter if you don't hate Terraria, Starbound, and the Buzzy Bees update." "You are not really human if you're not yet 18 years old." Good luck talking to people when a large part of your statements is dismissed like that. Oh, and others say it's only your fault.

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.

Justifying significant difficulty by that some difficulty is unavoidable
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)

We're (not) like Wikipedia
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.

"It just works"
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"
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.

Legal, therefore not an issue
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)

"This is subjective"
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.

We need rules, so we need THESE rules
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)

This thing is important! (So that one isn't.)
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)