[MUD-Dev] Motivating people

[Jon A. Lambert]

> From: Greg Munt <greg at uni-corn.demon.co.uk>
> Subject: [MUD-Dev]  Motivating people

What follows is some generalizations and could be way off base
since knowledge of your situation is limited. 

> 
> Am I expecting too much?
>

I am confused on one point.  Is the list server the primary exchange 
point for those developing your mud as well as this other mud you have
severed ties with?  If so, this would seem to be very counter-productive
and the political strife would continue to be a source of problems.
It might be better to run your own development list.  In addition 
Hubai's (John G.) suggestion seems rather good.  Another problem may
be that if your player base and/or staff consists of former players and
staff on the ex-mud, they may not share the same vision as you do.
"The enemy of my enemy is not necessarily my friend" or something like
that.  I think you have written some insights that this might be the 
case.

One thing you could do that may be helpful.  Prepare a detailed vision
statement (mission statement, if you like) on both your vision of the
server's capabilities and the game/mud theme.  (Warning: see the movie
"Jerry Mcguire" for worst case side-effects *grin*)
Make it a very visible item and primarily YOUR vision.  

I happen to believe design by committee is a very difficult task and made 
even more difficult using specification by committee.  This vision/mission
statement serves as general specifications or scope.  I also believe
in benevolent dictatorship at least when it comes to software projects.
Note I said "benevolent", which means you give the appearance of being 
open minded and understanding while effectively killing or postponing 
ideas which conflict with your vision.  Sometimes you may even like these
ideas and they may form the nucleus of your first batch of enhancements.

Motivation - sigh...a biggie...(much personal opinion here)

This is for many of us, a volunteer enterprise.  There are many things 
you can't do since you don't have access to the kinds of rewards and
punishments that turn a mildy-interested party into a willing volunteer.
Now you do state that you feel somewhat ill-at-ease offering in-mud
promotions, wiz positions and the like as a form.  I think this is good
gut feeling on your part.  I don't think these rewards are at all 
appropriate.  Part of the problem is that once you hand out any positions
at all you create an expectation of this for all involved.  Production
of code/building then becomes a non-issue.  You also create a political 
hierarchy within your own mud before it even gets online.  I do not know 
the number of people involved in your project, but I wouldn't think it
too difficult to have all report to you.

My own project is constructed along the lines that all report directly to 
me.  All are equal, some are of course have proven to be more equal than 
others, but the illusion of equality must remain.  When the server goes 
public the positions will be filled.  No promises have been made.  This 
requires trust on the part of those involved.  Trust is never immediate,
though it is built by your actions and words. 

Projects tend to languish even when there is high-interest because the 
goals are too vague or too far away.  I would suggest once (or if you 
already have a specification) decompose it into very small chunks that 
can be accomplished in a relatively short period of time.  Once you
have a handle on these, post the specs to your list and ask for volunteers.
If you get solid bites on these, let them go to town after they give you
an estimate of how long it will take them.  Make it a very public affair 
by posting whose working on what.  And being the benevolent one you are,
much fanfare and kudos will accompany completion of said work.  If these
be coders make sure they get their names in the comments too.  Point 
questions about interfaces or use of this code to the authors.  Another
words if Bob asks about adding flobs into Joe's frambulator code, tell
Bob to talk to Joe about it.  Follow up with both of them and make
a decision, giving especial deference to Joe.  This gives people a
sense of ownership of their code/building areas, etc.  Gradually you
will be able to spot those productive people while establishing a
framework of trust and a stake in the mud.  

Now about those unproductive people.  Perhaps some of these can be 
productive but they are a bit cautious and gun-shy.  They aren't likely 
to volunteer for anything you post.  Perhaps they just don't know where 
to start or haven't been interested in anything to date.  Perhaps they
want to code but are quite unsure of their skills.  The best thing to do 
is to ask them outright, Fred what the hell do you want to work on?  
If they waffle, have a very trivial task handy.  Have them edit a thematic
manuscript, some help files, flesh out a skeleton specification or some 
other documentation.  Give them a long line of rope, if in the end you
can't get a single line of text from them, flush em.

Anyway I hope some of this is helpful.  I would bet some of it is
very obvious and some may cause one to react strongly against.  But 
take it on it's face value, my two cents. ;)

JL