antonio . dolcetta on Wed, 22 Nov 2006 10:13:14 -0700 (MST)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [s-d] [s-b] Proposal: Conflict resolution


I don't think "giving headroom" is necessary, if types are needed at some time in the future, the proposal that implements types will make it's own room by itself. Adding something which has no meaning to a key rule just adds clutter and generates confusion.
Suppose a new player comes along and reads your conflict resolution rule, he stumbles on this "types" thing, since he has not encountered it anywhere else in the ruleset he would think he had just missed it, after searching for it everywhere he would rightly conclude that the sentence has no true significance. And thus oh so precious time is wasted.

Don't get me wrong, the idea of your proposal is great, and sorely needed. I'm just pointing out that in it's current state, I would vote AGAINST it.


----- Original Message ----
From: "shadowfirebird@xxxxxxxxx" <shadowfirebird@xxxxxxxxx>
To: discussion list for B Nomic <spoon-discuss@xxxxxxxxx>
Sent: Wednesday, November 22, 2006 5:49:43 PM
Subject: Re: [s-d] [s-b] Proposal: Conflict resolution

"creation date" was a typo.  I'll fix it in a minute.

I put in the bit about types of rules to allow some headroom for
further expansion (including but not limited to "hard rules" - but
note: nowhere have I said that a hard rule overrides a soft one).

I'm happy to revise the rule to use the "takes precedence" wording,
although it sounds a bit vague to me.  Most rules aren't designed to
be part-implemented, also.

I agree you can always call a Judge.  But we don't have them at the
moment, and besides a judge needs something to base a judgement ON.
Any arbitary method for resolving conflicts is always going to be
that.  So long as we know it is in place, we can design proposals with
it in mind.


On 11/22/06, antonio.dolcetta@xxxxxxxxx <antonio.dolcetta@xxxxxxxxx> wrote:
> > ----- Original Message ----
> > From: Andy Jones <shadowfirebird@xxxxxxxxx>
> > To: spoon-business@xxxxxxxxx
> > Sent: Wednesday, November 22, 2006 10:52:44 AM
> > Subject: [s-b] Proposal: Conflict resolution
> >
> > Proposal: "Conflict resoluton"
> >
> > 1) Change rule 1-8 to add at the end:
> > {{Every rule has an amendment date.  This is a date.  There can only
> > be one amendment date per rule.}}
> >
> > 2) Change all existing rules to add, as its amendment date, the date
> > that the rule was last changed.
> >
> > 3) Change rule 2-2; add the following at the end:
> > {{Each rule created or amended by the proposal has its amendment date
> > updated to the date the proposal passed.}}
> >
> > 4) Add a new rule titled "conflict resolution":
> > {{When two or more rules conflict, one rule "wins" and the rest are ignored.
>
> What exactly is ignored in the "losing" rule, just the conflicting part or the whole rule ?
> Usually in nomic this problem is handled by saying: "rule x takes precedence over rule y", this implies that any effects in rule y that are non-conflicting still happen.
> What you are saying is basically "rule x exists and rule y does not count" which can lead to pretty unpredictable results IMHO.
>
> >
> > If one rule says it overrides the others, that rule wins; otherwise,
> > if one rule is of a type that overrides the other rules' type(s), then
> > that rule wins; otherwise, the rule with the oldest creation date
> > wins.
>
> You have not yet defined a type that rules can have (I suppose this goes together with your proposed immutable rule proposal)
> Also you have not defined the creation date for a rule (if that is indeed a separate value from the amendment date)
>
> _______________________________________________
> spoon-discuss mailing list
> spoon-discuss@xxxxxxxxx
> http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss
>


-- 
It's Like This

Even the Samurai
Have teddy bears
And even the teddy bears
Get drunk
_______________________________________________
spoon-discuss mailing list
spoon-discuss@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss



_______________________________________________
spoon-discuss mailing list
spoon-discuss@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss