The Happy Happy Joy Joy guide to MUSH Administration.

This is a guide to successful administration.  To achive perfect harmony with
the players of your mush, you need to consider carefully this guide.  I think
once you have accomplished this, you will find all the answers you need.

#1.  The player is always right.
	This is taken from the very well known service guide 'The Customer is
	Always Right'.  As people who play on mushes, are indeed, clients 
	(or customers) to the work you have done, it is very proper that they 
	be treated like royalty, and as such, given special treatment 
	regardless of their actions.

#2.  Staff need to serve
	Staff, no matter what they are doing, must, at all times, be around to
	help the player.  If you can not achieve responsiveness of at least 60
	seconds or less, you are not a good administrator and need to step 
	down immediately.  You should also provide your email and, within 
	reason, your immediate contact phone number, so that you are available
	to help the needs of the player at all times of the day.  Failure to 
	do so should be terms for immediate dismissal from the game.

#3.  No one is at fault except you.
	When a player has a problem on your mush, you must fix this issue by 
	any method possible.  As it is very unlikely the fault lies with the 
	player, the fault must lie with the mush itself.  Thus, you need to 
	modify the rules of the game and very likely rebuild/redescribe an 
	area so that the player who has an issue is comfortable and appreciates
	the mush and the effort put in properly.  Once you are finished fixing
	the problem to the player's specific needs, make sure to praise the 
	player for bringing up the problem and alerting you of the issue as 
	more than likely, you still are learning the ropes to good 

#4   Lag is a 4 letter word
	Lag always happens.  It's unfortunate when it does, but it will cause 
	players to disconnect at the worst possible times.  Most of the times 
	this will seem to happen is during intense role play, especially when 
	the demise or other invariable evil situation will happen to the 
	character.  If the character happens to disconnect during such a time,
	please be patient with the player as the router and network is 
	obviously at fault.  wait patiently for the reconnect, and if the 
	player doesn't reconnect for the rest of that evening, dismiss the 
	roll play and/or push it off for another time.  Or just continue with
	the role play and when the player connects, re-include them where he
	left off.  And be kind and considerite to the player as having such 
	terrible connectivity is obviously a huge headache and the player is 
	bound to be very unreasonable and upset.  You probably will want to 
	reverse any evil or killing that was assigned for that player and 
	assign it to someone else at this point.

#5  When in doubt, the player is right.
	The player is always more intune with a situation then you are.  They
	also will seldome lie about a situation, especially when it benefits
	them.  You should always, and I mean always, take what they say at
	face value.  When a player has an issue or finds that someone is
	cheating, always fix the problem democratically.  Talk to all parties
	involved, and explain to the accused party how cheating is not a good
	way to solve anything, and that further cheating will mean further
	lectures.  That will most definately get your point across to them.
	Again, we must never look to annoy a person, even one who could be
	at fault, as all players have a right to be on your game.

#6  Always answer threats with honey and turn the other cheek.
	It's natural that players will not like how things are run.  And
	if after you've done everything to make the player comfortable, they
	still try to break the rules and cheat, steal, and twink, calmly
	explain to them that what they are doing is not right.  That should
	be more than sufficient to correct their behavior.  If they repeat
	the problem, take them aside and continue to discuss their behavior.
	Ask them how the rules can be rewritten in such a manner that they
	will understand them better, and rewrite them as the player mentions.
	If then, later, they break the rules, they obviously are still 
	confused on the rules of the mush, and need to be talked to again
	to try to figure out what is keeping the player from the fun of
	the mush and seems to confuse them about the rules.  With enough
	such discussions, the player will remain happy and in time will
	understand the rules and be yet another great addition to your game.

#7  There is no such thing as someone who isn't right for the game.
	When a player doesn't seem to 'fit in' it will need to be fixed.
	This may entitle rewriting the rules, the game, or asking other
	players to change how they act around this player so they no longer
	feel threatened, controlled, or uncomfortable.  If the problem can
	not be resolved, invite the player as a staff of your mush and give
	them 'charge' of the situation so they can fix the problem.  They
	obviously know more about this issue than you or your staff do so
	having them onboard as staff to deal with the situation is a wonderful
	solution to the problem and makes everyone happy.

#8  The codebase you use doesn't matter.
	There are a lot of code bases out there, and they all are basically 
	the same.  Every single one has the same issues with stability, 
	security, and the same basic code.  It doesn't matter which one you 
	get, so just listen to what people want most.  If the game happens to
	crash or corrupt itself, then to appease the players when you bring 
	up from a previous database, reward everyone with large amounts of 
	experience and skills so that they actually gain more than they have 
	lost.  That way, if the server crashes again, you are bound to keep 
	the players as this will make them aware that sticking around 
	actually gives them something, and again, keeps them happy.

#9  If you haven't heard it, it's not true.
	There will be, undoubtedly, a great number of times you will have
	players come in and say that the codebase you're running is bad, to
	upgrade to codebase 'X' or that your master room or starting room
	is problematic.  Don't worry about these things.  You know that
	problems will exist, and that it's highly doubtful that it will ever
	be fixed, so what you're using is good enough.  If people break
	the code online, you just bring them aside, calmly tell them that 
	what they are doing is wrong, and let them on their way.  In time,
	they'll learn what they are doing isn't correct.

#10 Never have a heavy hand in punishment.
	@nuke, @toad, and sitelocking should never be done.  The only time
	a player would ever do anything so horrible to deserve this is
	if they were not being listened to or had a major problem with the
	game that they felt they were being ignored on.  Envite these players
	onto your game, with a full staff meeting.  Talk to them openly
	and resolve the issue by incorporating anything they are asking for
	into your game.  After all, adding players who are so obviously
	in tune with what is wrong will greatly inspire the players and give
	your mush an even larger following.  You may even have one of these
	players as your new staff as they can help with the running of the

#11 Invite people for staff who can do the job.
	It doesn't matter if you don't know them, don't like them, or
	if you're giving them bits just because they're friends.  Whatever
	the reasoning, the more bits the merrier.  Having more staff can
	get the job done twice as quickly.  For anyone who says you take
	a risk by having so many bitted people, they obviously do not
	know what they are talking about.  Just refer to #9 above and
	ignore them.  They're just jealous anyway.

#12 You don't need coders to do a good job.
	Coders are useful tools, but otherwise serve no purpose.  You really
	don't even need a good coder.  And any coder will do.  You don't
	need to know any code yourself, nor do you need to know how to
	build.  All you need to know is that you want to set up a mush,
	and get people to help you do it.  Why worry about the details?

#13 They say they're a good coder, so they must be.
	People don't usually lie about their coding expertice.  And all 
	of the code they do is original or borrowed with expressed
	permission from the author.  Anyone who can code something
	with lots of colors and a good interface is all you really need.

#14 Bigger is better
	When you build your mush, you need to get as many players as you can.
	If this means allowing each player 20 alts and having them log in
	them all at once, even if they're unable to play them all at once,
	so much the better.  This makes your WHO list look bigger and thus,
	will bring in more players because it shows just how popular you are!
	All those people who say quality over quantity obviously don't have
	the experience that you do.

#15 The mush is your playground.
	Yes, you are the ghod/ghoddess.  You have full right to do what you
	want, therefore, you can monitor everything, play with everyone,
	and not have to worry about anything because of it.  Always remember,
	there is no right or wrong, there is only power.  Enjoy your mindgames!

#16 Consent is expected in role play
	Absolutely!  Consent should be handled by the player and not be
	predefined.  If anything happens that the player dosn't want to happen
	to their player, why just pull the consent flag and say you don't approve.
	A player will never use it to their advantage so that they can survive
	or avoid any negative experience with their player.  Of course not, right?
	After all, as long as everyone is happy, it all works out!  And as long
	as people see others get away with stuff, it should make them happy, right?
	Right?  RIGHT?!?  Well, if they don't agree, look at #9.

If you follow these guidelines, you'll get exactly what you are looking for.
You will definately have people know you and your mush by name.
Your dream of an utopia will come to a fruitation.  Pretty easy, no?

---------------------------- Disclaimer --------------------------------------
We can not be held accountable for any use of these guidelines, actions,
methods, or intentions of people who have read/used/maintained them.
Any resemblence between these guidelines and stupid-ass administrators are
strictly coincidental. Any destruction to muds by using these guidelines 
are totally hypothetical.  Any person dumb enough to believe these 
guidelines should be shot, quartered, and mauled by roaming lions. 
You have been warned.

This sarcasm brought to you by S.C.H. Muck & Brown.  The McNose people.

What, you want to know some real guidelines?  Ok:

#1  Mushing is a privilage, not a right.  You pay nothing to be on them.
#2  If you don't like the game, and have a problem, see rule #1.

A private note:  All of the above rules actually exist on mushes.  They
were literally pulled, some word for word, from mushes.  Fear them.