Staff Ethics

The following ethics document is an edited version of Amberyl's Wizard Lecture. Many thanks to her for setting the ground rules that have made many MUSH admin structures pleasant places to live within.

Administrators on a MUSH have a considerable amount of power. With that power comes the responsibility to use it wisely, for the actions of an administrator reflect not only on himself, but on the MUSH as a whole. Because an admin is in a position of power, he should attempt to set a positive example in all dealings, whether in-character or out-of-character. Common sense will usually suggest a decent solution to a given problem; there are, however, some situations where the ethical and "correct" thing to do is not immediately obvious.

Please note that because of the Architect structure here at Los Angeles: A House Divided, you should not assume that because this document discusses some power, that all Architects have the ability to do this. Architects have the powers that they need to perform their jobs. See +news Policies/Architects.

Players are frequently paranoid about privacy. This is one "right" that Architects should _always_ attempt to respect; thus, this lecture begins with a discussion of the DARK flag. When you are DARK in a room, players who do a 'look' cannot see you, and you do not appear on the WHO list, but a @sweep of the room _does_ show that you are listening and connected.
Therefore, there is a chance that you will be noticed, and, if you are "illegally" in the room DARK, it is almost certain that the players in the room will be quite upset.

Given the setting, it is possible for players to be invisible in in-character areas on the MUSH, so players cannot expect their in-character conversations to be private from invisible characters unless they have taken in-character precautions. However, they can expect to have privacy in in-character areas, and to have in-character defenses against invisiblilty - so the following notes still apply to Architects.

The reason why players don't like DARK Architects wandering around should be obvious — they're afraid of private conversations being snooped on. Therefore, whenever you go _anyplace_ DARK, the first thing you should type upon entering the room is a "hello" or similar announcement of your presence. Make this a habit! If you do it regularly, even when the players in the room know you'll be entering DARK, there's less of a chance you will forget at some crucial moment. If you plan to be DARK, and wandering around, for an extended period of time, in order to arbitrate an RPG conflict or similar event, the players involved should, if possible, know of your presence, and if a private conversation begins, it is your ethical responsibility to inform the players of your presence immediately, or leave, _even if_ this lets players know that they are being judged. Your personal responsibility to promote privacy overrides any RPG mechanics.

Architects may go DARK in order to observe players whom are suspected of trying to harm the game, either by harming the database or crashing the server. They may also go DARK to observe the actions of a player harassing other players. In the latter case, the wizard should indicate his presence to the players in the room who are not "under suspicion".

I cannot emphasize enough how important it is to obey the protocols for using the DARK flag. This is one of the greatest sources of player distrust in staff, because it is so _easy_ to abuse. Players should be able to have private conversations without doing a @sweep all the time. While privacy on a MUSH is never, ever, guaranteed, you should do your best to contribute towards it.

The second of the frequently-abused Architect powers is @teleport. There are a number of rules that should be observed when @teleporting. First of all, never teleport a player without warning him first. If possible, the player should page you with an acknowledgement before you do the actual @tel. This prevents, for example, an untimely @teleport wrecking someone's set of a @desc on a room. No one enjoys suddenly being yanked to another room, and it doesn't hurt you to page the player first.

Never teleport to a room with players without asking the permission of the players there first. The exception to this are public hangouts. A room which is merely JUMP_OK is not necessarily a public hangout; use some judgment when determining whether or not rooms are public. Unless the room is clearly public, ask first; it doesn't hurt you to be polite.

If permission is not likely to be granted, then notify all players in the room (@remit works well for this) that you are going to be coming in, before entering the room. You should wait a moment between the time of the announcement and the teleport; this should prevent you from hearing something that you shouldn't.

Never make assumptions about whether or not it's okay to teleport into a situation. For example, just because a player is paging you for help with coding some complex object _doesn't_ mean that he wants you to teleport into his room and help him out. Always _ask_.

Don't abuse "examine" or the power to see private information like sites. Architects can examine anything, to check for theme consistency, etc - but should never share or show any object, or part of an object, that is not theirs to another player, without getting the permission of the owner. Also, don't steal code. "Stealing code" includes @decompiling/logging/cloning without permission, even if you're just using the code for your own personal edification or enjoyment. If it's that important to you, ask permission.

Sitenames should never be given out. If a player is Unfindable, you shouldn't give out his location. Some people MUSH to escape people they know in Real Life; some players carry vendettas cross-MUSH. Other people simply prefer not to let others know where they are, VR or RL. You should respect this desire.

You should generally avoid modifying other people's objects, even if you're fixing code problems or typos. The only exception to this is publicly owned building owned by a staff-played builder character (the core landscape for the MUSH, the downtown area, etc.) If you encounter an object which is inefficiently programmed or looping, and thus slowing down the game for everyone else, simply set it HALT and mail the owner; don't fix the problem.

Also, don't @destroy anything of anyone else's unless they explicitly ask you to. If it's an item which is illegal in some way, send the owner a warning, and give him a certain period of time (a few days, usually, depending on how often the player logs in) in which to get rid of it. If it's not gone by the end of the period, then you can destruct it. If the illegal item is sitting in a public place, you should feel free to teleport it back to its owner.^

Never, ever, @force a player, unless it is _absolutely_ necessary. For the same reasons, don't use @trigger and similar commands to make a player do something against his will. Also, don't change the attributes on a player; for example, it is generally considered unethical to change a player's description to something humiliating.

If you need to change an attribute on a player, make sure you copy the old attribute to a backup attribute on the player, so that they can recover it later, if need be.

Architects with the WIZARD bit can pile huge numbers of things on the queue, and make use of computationally expensive commands like @find and @search with impunity. If you need to do something that will severely lag the game, do it when there aren't many players on. Also, note that very large @dolists cause the MUSH process size to grow, and should be avoided whenever possible.

Avoid annoying players with shouts. @wall cannot be blocked, and, therefore you should make sure that everything you shout is informative and necessary.

Shouting to announce a @shutdown in five minutes is acceptable; shouting to announce game problems is acceptable. Shouting to announce that you've had a bad day and shouldn't be paged should probably be avoided. First of all, it makes you sound like a twit; second, it accomplishes nothing useful and implies, "stay out of my way or something bad will happen to you." If you really want to avoid player pages, go DARK and set a pagelock. Players shouldn't be afraid of you on a "professional" level, and you should try to avoid actions which cause players to fear you.

Never MUSH while intoxicated or otherwise not fully in control of your actions. Know when to log off or back out of a situation. If you feel like you're about to explode, get up, walk around for a bit, get a drink of water, and come back when you feel like you're ready to cope rationally with the situation. If possible, call in another administrator to handle the situation. Never, ever, perform Architect actions out of anger; it is likely that you will regret them later.

An Architects ability to deal with players is usually the final test of his skills. Troublemaking players are quick to find administrators who are easily provoked, and frequently enjoy pushing all the buttons they can. When you page a player, no matter how annoyed you might be, you should try to remain calm and polite. Don't swear at players, or behave in a manner that would allow the player to focus a discussion away from his wrongdoing to a mistake _you_ made.

Players who are spamming or exhibiting behavior detrimental to the server or database should be @booted; if it's a one-time-deal character like "You_Suck", a @destroy is also in order. Other players should receive warnings before any direct action is taken.

If a player is being obnoxious or breaking MUSH rules, page them and politely let them know that their behavior is unacceptable. If the player is not idle and does not respond to your page within a few minutes, repeat your page. If the player simply ignores you, or refuses to change his behavior, page with a stronger warning, but continue to remain polite. If this doesn't work, tell them, "If you don't stop that, I'm going to @boot you.

This will normally at least open a dialogue between yourself and the player in question. If the player isn't willing to discuss it, and continues the obnoxious behavior, @boot them. If they come back and continue to be annoying, then @newpassword them. You should NOT @destroy a player who isn't a one-shot annoyance. @destroy is not reversible, but a player can be re-@newpassworded should he decide to come back and play by the rules.

When talking to a player, you should attempt to remain calm and polite, no matter how much the player is trying to provoke you. Ignore personal insults, obscenities, and the like, if some useful discussion is occurring. If the player is just continuing to be annoying, end the discussion and simply tell them, "Do this again and I'll @boot you." You're not required to be a saint or martyr.

Whenever you enter a major conflict with a player, you should log the situation, if possible. You should send the other Architects, via email, a summary of the situation, and, if necessary, the log. This will prevent the player from accusing you of saying or doing things that you did not, and will give you a "record" of the player's behavior, in case the player claims that he didn't do what you claimed he did. The SUSPECT flag and @comment attribute are also good for letting other Architects know about suspicious players.

These guidelines aren't here to make the task of administrating more difficult for you. They exist to provide some basic guidelines of ethical behavior; in general, if you follow these guidelines, players will find it quite difficult to accuse you of abusing your powers. They thus work for _your_ protection, as well as the players'. Players frequently take mistakes personally and seriously, and may decide, "because X did this, all other Architects probably do, too." Players who are paranoid tend to be more difficult to deal with; thus, for the sake of your sanity and that of everyone else who has to deal with that player, try to avoid giving them a reason to be paranoid. If you consistently have personal problems with a player, you should also avoid dealing with that player; have someone else handle the situation instead.

In all things, use common sense, and try to remain calm and impartial. When all else fails, log off.

[ Based on a lecture first given on TinyKrynn, 2/92, by Amberyl. ]

White Wolf © White Wolf
Original Work is licensed under a CC Attribution-Noncommercial-No Derivative Works 3.0 US License.