So, you want Doc to accept your proposal, eh? Typical.

OK. First of all, let's acknowledge that Doc's decisions are arbitrary, capricious, and definitely not final. On a given day Doc may well reject a proposal e'd accept on another day, for no reason other than whim. Can't do much about that.

Still, there are things you can do to improve (or worsen) your proposal's chances. Here are some (and if you check this page again in the future, you may find more). In no particular order:

1. Combine your changes. At present the rules allow a proposal to contain multiple changes to the rules. I think that's a perfectly good way to operate. Otherwise, implementing a single idea might require numerous proposals, with the possibility of nonsensical results if some were accepted and others rejected. Instead, numerous brief and closely-related changes to numerous rules can and should be tied up into a single package.

2. Don't combine your changes. On the other hand, it's bad form to have multiple unrelated changes in a single proposal. In fact, such a proposal might annoy Doc into rejecting it even though all parts are acceptable. And if one part is unacceptable, Doc will have to reject the whole thing -- even if e loves the rest of it.

   So you should include as many changes as are needed in one proposal, but no more. More or less.

   (Another consideration is direct costs and benefits. Depending on how the ruleset has been evolving lately, there may be a reward in DocNomic for getting a proposal accepted. That would tend to reinforce breaking changes among several proposals. On the other hand, there may be a penalty for submitting multiple proposals in rapid succession. That tends to reinforce combining changes into one proposal. And so on.)

3. Spelling counts. So do grammar and punctuation. While Doc would have to be having a really bad day to reject a proposal on grounds of incorrect use of the apostrophe, e does admit to being somewhat anal about these things, and gross spelling, grammar, or punctuation errors just might push a marginal proposal over the line.

4. Say what you're doing. If you're proposing a new rule, say so. Like this:

   Enact a new rule with the following text:
   
   "All players are to be decaptated each Monday."

   Not like this:

   "All players are to be decaptated each Monday."

   which doesn't make it clear whether you're proposing a new rule, an amendment to an existing rule, or a direct change to the gamestate (which is at present illegal, see below.)

5. Don't amend the gamestate. This is not just a good idea, it's the law. At present, a proposal must consist of one or more new rules, amendments to existing rules, or repeals of existing rules. It may not include a direct change to the gamestate.

   There's a well-known workaround to this, namely the self-repealing clause:

   Enact a new rule with the following text:
   
   "When this rule is enacted, all players have their point total set to -3,774,891. This rule then repeals itself."

   That works. But Doc considers it somewhat ugly. Use it only when you have to, and keep in mind:

   1. Self-repealing clauses should generally be used only as part of a broader proposal to initialize gamestate data for that proposal. It's bad form to make a proposal that is entirely self-repealing, except to fix up a once-only problem (and if that's the case, usually it's even better to talk Doc into fixing it by proclamation).

   2. Often there's a better way to do it. For example, instead of

      Players may own Avocadoes. When this rule is enacted, each Player receives 489 Avocadoes; this sentence then deletes itself. When a new Player joins the game, e receives 489 Avocadoes.

      it's more elegant to do this:

      Players may own Avocadoes. If at any time a Player has no Avocadoes, and has never had any Avocadoes, e receives 489 Avocadoes.

6. Be kind to your Doc. Many Nomics go defunct because a central figure loses interest. You can't prevent that, but you can reduce its likelihood by asking yourself, "If I were Doc, would I want to administer this rule?" Trust me: Doc is asking emself the same question. A proposed new rule to the effect of "Every thirty-ninth message from any player whose last name contains a prime number of letters must contain twenty-three instances of the letter 'e'" is very likely to get rejected... because everyone probably will regret it if it passes.

7. Who's gonna make me? There's another problem with the above proposed new rule. What happens if someone whose last name contains a prime number of letters sends a thirty-ninth message which does not contain twenty-three instances of the letter 'e'? They've violated a Rule, but that Rule contains no provisions for dealing with such violations. As it stands, the result probably would be a message from Doc saying, "You just violated a rule. So what." So: make sure that if you impose a requirement, it's clear what happens if someone fails to meet that requirement.

Last modified: Wed Jun 12 15:49:31 EDT 2002