shareresp.html

<html>
<head>
  <title>The MUCK Manual: Admin: Sharing Responsibility</title>
</head>
<body bgcolor="#FFFFFF">

  <center>
  <a href="staff.html">prev</a>|
  <a href="toc.html">toc</a>|
  <a href="privacy.html">next</a>
  </center>

  <table>
  <tr>
  <td width="20%">&nbsp;</tc>
  <td>
  <!--  BODY CONTENT HERE --> 

<p><b>5.2.3  Sharing Responsibility</b></p>

<p>Most <code>MUCK</code> administrators find it necessary or at least
helpful to recruit a staff, to share responsibilities for building,
programming, technical maintenance, player relations, and so forth, with
a team of people with aptitude for a specific area of
responsibility.</p>

<p>Use whatever pigeon holes and job desciptions you like. The following are common:</p>

<ul>
    <li><p>Site Administration: This wizard is responsible for
    maintaining Net access. Sometimes the site admin is only marginally
    involved in the <code>MUCK's</code> day-to-day affairs, acting
    essentially as a landlord.  Even in this situation, there are
    reasons for making the site admin a wizard: for example, he can log
    onto the <code>MUCK</code> and do a clean <code>@shutdown</code> if
    it's necessary to shutdown the server for maintenance or other RL
    reasons. The site admin may also be responsible for server-side
    chores such as keeping back-ups, updating news and info files, and
    answering email addressed to the <code>MUCK</code> staff.</p>
      
    <li><p>Programming: This wizard sets and unsets Mucker bits, based
    on players' programming expertise, trustworthiness, and committment
    to the world. She also reviews programs to be ported, checking
    security and efficiency considerations. She may also be responsible
    for creating and maintaining a listing of publically available
    programs.</p>
     
    <li><p>Player Relations: This wizard arbitrates grievances between
    players and charges of <code>AUP</code> violations. He is empowered
    to act as appropriate in such situations, using disciplinary tools
    such as recording warnings and charges in a log kept on the
    character, temporary <code>@newpasswording,</code>
    <code>@toading,</code> and site banning.</p>
      
    <li><p>New Characters: This wizard <code>@pcreates</code> new
    characters. She needs a way to read emailed character requests, and
    she needs information about any players, sites, and addresses that
    have been the source of player-relations problems. For a small
    staff, it makes sense to combine this job and that of Player
    Relations.</p>
      
    <li><p>Building: This wizard is, in the <code>MUCK's</code> early
    days, charged with building the world, or coordinating the efforts
    of a team of builders. Once the world is built, the Building wizard
    will have the most complete understanding of how everything is set
    up, and is the best person to decide matters such as planning or
    incorporating new areas. Often, the Building wizard also determines
    policy on quota issues.</p>
</ul>
      
<p>The exact form of your organizational set up isn't crucial, but it is
important that the staff has a good understanding of who's responsible
for what, when it's OK to do something that affects another staffer's
area, and that God or the core administrators keep a sense of
proportion. Silly, unproductive `turf wars' are a common reason for
staffs failing to gel as a team, and worlds burdened with squabbling
wizards seldom thrive. Some guidelines...</p>

<ul>
    <li><p>God should refrain from micromanagement. If you've given a
    wizard authority to handle Player Relations, let him handle it.</p>
      
    <li><p>Good communication solves most problems before they become
    problems.  Set up a global page alias for wizards and staff. All
    staff should page mail each other when they do something that
    affects the <code>MUCK</code> as a whole, or affects others' areas
    of responsibility.</p>
      
    <li><p>If instant action isn't required (and it seldom is) let the
    wizard who's responsible for an area handle that area. The Builder
    wizard may think that JoeHacker's actions obviously call for
    toading, and she may be right, but it's better for her to simply
    <code>@newpassword</code> JoeHacker, and let the Player Relations
    wiz handle the actual toading. Not only is it his job, but he may
    have worked out a procedure for <code>@chowning</code> the
    character's objects, notifying the player, and so forth.</p>
      
    <li><p>And the flipside of the same coin... If you and the players
    frequently find that something needed just doesn't get done because
    a key wizard is unavailable (the Programming wiz hasn't logged in in
    three weeks, say), then something is amiss with staff organization. 
    God should step in, handle the immediate situation, and consider making
    changes to the staff roster.</p>
</ul>      

  <center>
  <a href="staff.html">prev</a>|
  <a href="toc.html">toc</a>|
  <a href="#top">top</a>|
  <a href="privacy.html">next</a>
  </center>

  </td>
  <td width="20%">&nbsp;</tc>
  </table>
</body>
</html>