Basically, I suspect you're that one guy who I read that one post from on Optional Realities BitterFlashback!
Ah, no, I haven't posted on other RPI-related forums (yet), excluding the GDB for Arm.
Now back to your original questions!
There's no good way to produce a MUD without staff. If you make everything democratic you wind up with the majority or a large clique (or just people who are always around to vote) dominating everyone else. The (hopefully benevolent) oligarchy/dictatorship has to be there to keep people from devouring each other like the savages
you all they are.
... but, that said, I put a ton of thought into the subject of limiting staff as much as possible though, and there's plenty you can do there. I'm going to lump everything you said into describing two large mistakes I've seen in MUD game design.
The first mistake with MUDs is very little ever gets integrated directly into it. You're either trying to do everything for the MUD in the MUD or you're doing the MUD work in the MUD but the approval in some totally external system (EMail, request tool, etc). If you make your MUD's website interact with the MUD, either by running both systems off a database or having someone write CGI files that can trigger executables on the server to interact with your flatfiles, you can have all of the advantages of a web-based UI without also having to manually take the input from it and manually insert that into you MUD.
To give an example, say you have a player who wants to create a room. This player's current character is a low-ranked noble in House Somesuch and they want to make a virtual room in the estate actual. They log in to the website with a login tied to their player account. They select to make a room for their existing character (as opposed to just suggesting a public room they would like to see). They then select that the room is supposed to replace the virtual/stock room for their character with a custom one.
The database settings for House SomeSuch say that a low-ranked noble bedroom cannot exceed more than 10 units x 10 units x 10 units and that the total value of all immovable fixtures cannot exceed 15000 coins. Furthermore, the bed has to be at least 2000 coins, the dresser at least 500, and you must have both of these things for appearances' sake. You also have general rules triggered by this, where the value of a specific item puts it into a "quality" category, and that category requires the description to fall between a certain number of characters. So if someone makes a 750 coin dresser, the dresser is now viewed as "opulent" quality and requires a minimum 350 char description with a 500 char maximum. If you'd gone with 500, the dresser would be "high quality" and the description would be between 200 and 300 chars. This would make it so the cheaper something is, the less descriptive it is, which would subconsciously reinforce the immediate impression of value you get when you first see something.
All of that complicated bullshit I just mentioned would be handled by the UI, based on values you set one time when you originally created this stuff. If a player enters something wrong, the UI tells them, rather than a staffer referring to a rule book. All of the objective rules are handled by an uncaring machine that never gets bored of doing it. Once the player is actually done making the things for their room, and the room is objectively acceptable to the game, they submit it through the website's UI. It goes into the same database the MUD runs off of, where it awaits approval.
Now comes the subjective part, since a computer doesn't know what good writing is. You, as a staffer in the game, can actually walk into the unapproved room like a character would, and decide if it's right for the game. In
your website/MUD UI, you can also apply settings that a player would not have access to. These would be things such as where the room
actually is, if the lock is defective, if the door impairs eavesdropping, etc. The moment you approve it the room goes from being inaccessible in the game to accessible. If you reject it, you can put in the problems with the room, and the system will let the player know so they can modify and resubmit.
You could do the same for building NPCs, objects, and anything else. Give the player a limited access version of the same UIs that you use, that all run off the same database the MUD uses.
The second mistake, which only applies to RPIs, is the idea of rewarding good RP. This takes a few forms, but they can be mostly summed up as "manual rewards" and "automatic rewards".
For manual rewards, players are given karma, stat boosts, or whatever based on being judged to be good. If your game is popular or if you want to keep your staff small, you do not have the time to watch people and decide if they're good. You also create scenarios where the subjectivity of judgments or the unavailability of judges causes players not being given rewards to feel unvalued. They may see favoritism where there may not be any, feel maliciously ignored, or assume the standards are just ridiculous. ArmageddonMUD is a perfect example of this. The karma system is completely nuts; I shouldn't have to go into this.
With things like coded leadership/authority, requiring manual approval makes sense, because you can create scenarios where you're just monitoring people who want something that there's a limited quantity of. This limits how many people you have to monitor at a time to something you can manage. You're also able to create minor leadership roles that don't have as much risk in letting an untested player run them while you observe. The same could be said for what are supposed to be extremely rare coded abilities. For everything else, manual reward is just going to piss people off.
For automatic rewards, you tend to have stuff like RPP (role playing points) used to purchase skill/stat points that accrue while you're socializing or emoting or whatever. This creates a system that can be easily gamed, resulting in stuff that doesn't make sense like always-on tavern-sitters having higher combat skills than casual player's solo hunters. For the advantage of eliminating the aforementioned problems with manual rewards you literally incentivize avoiding risks.
The best solution I've been able to come up with is a system of three parts based around avoiding punishment rather than attaining reward.
1) When you go to create a character, you will have points to spend on a character's stats, skills, and resources that are based on punishments you've gotten over time and how recent/severe they were. Time, in this case, is based on time spent playing the game. Spendable points are capped by how high you've actually gotten those skills, stats, and resources in-game. This gives people an incentive to take risks (caps based on achievement) without incentivizing suiciding a character (you don't recover spent points) or infrequently logging in (no reward for how long you've had an account because time is measured by time in-game).
2) The system relies more on players silently flagging other players' behavior as rule-breaking, at which point a staffer goes and reviews the report. The system will also automatically flag things like people using the OOC command or other things that they're supposed to limit. Staff can observe the game, flagging things manually as they come up, but mostly rely on processing complaints. This does give off-peak players an advantage in avoiding being reported by other players, but may be balanced out by the detriments of having fewer people to play with.
3) Regardless of the outcome of the staffer's review, the complaint, decision, and justification
will become public. IC-sensitive stuff can remain hidden in the report until it is no longer sensitive. There is no point in punishing someone if people don't know that it happened or why it happened. There's also no point in allowing people to report problems if you're not going to make it clear why you think they're
fucked in the head overreacting or just not seeing the big picture.
I have no plans to have sponsored leadership roles or sponsored power characters so this system does not deal with them. If I added the former, I would make it so players could create their own leadership roles, and only flag someone as having access to coded roles if they were successful at making their own uncoded ones. At that point I'd have something to review. Same goes for special powers; I'd have abusable powers people could achieve on their own, and only give them access to special ones when they've demonstrated they're not already misusing the ones they already earned themselves.
