On Tue, Aug 6, 2013 at 12:51 AM, Tanner Swett <swe...@mail.gvsu.edu> wrote:
> This is a really long proposal that makes a heck of a lot of changes, some of 
> which I disagree with; I'd almost certainly vote AGAINST it, or any similar 
> proposal, unless it were broken into something like a dozen smaller 
> proposals, in which case I'd vote AGAINST only the objectionable parts and 
> FOR the rest.

This is indeed a very long proposal.  I should probably split it up
into a few pieces, since there are a few quite independent parts, and
splitting it up makes it easier to understand.  I could also split it
up into many pieces, as you suggest, and if more players have this
opinion then it may be required for me to do so to get the proposal to
pass.  However, I fundamentally don't want to, because I think most of
the mechanics I proposed changing need cleanup one way or another;
rather than having a proposal fail and leave that part of the rules
completely untouched, I would prefer to settle on some degree of
change that everyone can agree on.

> Besides, a proposal of this length is very likely to contain mistakes, 
> perhaps multiple significant ones; going through the proposal and checking to 
> make sure there aren't any significant mistakes seems like a pretty 
> significant effort.

Well, yes, but you would have the same burden if I submitted a dozen
smaller proposals at the same time.  I could space them out over
several weeks... it wouldn't be the end of the world, but it is also
not something I remember ever having been done before.  It's not
/that/ long.

> As for the particular parts I find objectionable: To me, Power has always 
> felt like one of the defining pillars of Agora; it seems useful enough to be 
> worth keeping around, and surely not confusing or complicated enough to be 
> worth getting rid of.

imo it is fundamentally wrong that Power is (a) untracked and (b) left
over on proposals after they take effect; moreover, I'm not even sure
it works the way we think it does, due to

      All entities have Power zero except
      where specifically allowed by the rules.

I'm not sure this actually makes a difference, since during my
playerhood nobody has ever succeeded at setting some random entity's
power (although I've tried setting my own at least once as part of
failed scams :), but it's weird.  My proto attempts to make this more
clear, although I think I should add an explicit clause about Power
only existing as defined by the rules to match the intent.

While I don't think the "can cause this rule to amend itself"
requirement is the end of the world, I don't think that removing it
constitutes removing Power; it just makes it less weird.  (Also stops
ais523 claiming that random actions fail because the actors don't have
enough power. :p)

> Second-class persons pass in and out of fashion in Agora; keeping the 
> definitions around allows them to keep doing so as Agorans wish, whereas 
> removing the definitions would make it significantly more difficult to bring 
> second-class persons back even if we want to.

There are two aspects of this.

One is jargon: it's not the inherent complexity of the concept of
first-class players, but the more literal impact of having the word
"first-class" everywhere that is the problem.  To quote yourself:
> The ruleset is really, really long, and a lot of it is really dense in 
> jargon. In order to understand Rule 2401 "Registration Yaks", you have to 
> know what "Registrar", "Yak Master", "Budget Switch", "first-class person", 
> "register", "impel", "Yak", "first-class player", "active", "Agoran 
> decision", "announce", and "CAN" mean.

My proto is in large part a reaction to that discussion: although at
some point you can only simplify the ruleset by removing
functionality, there is a bunch of stuff that has grown overly complex
and can be refactored "for free".  Among the bits of jargon you cited,
some are basically unavoidable, some are hard to think of a way to
improve (although the Yak stuff is volatile enough that I don't really
mind having it be a little confusing, since it'll probably change soon
anyway).  But "first-class" is low-hanging fruit, and makes the
ruleset that much more fluid to read.

An alternative fix would be changing "first-class" to "natural", but
prospective players might not immediately see that "natural player" =
"player that is a natural person".

The other aspect is that I don't see the point of second-class players
if they haven't been able to do almost anything for years, and are
unlikely to be granted those powers back.  They get to feel good about
being listed in the Registrar's report, and that's about it.  Unless
we're going to really treat second-class players like players (e.g. by
defining a limited number of them, as in scshunt's recentish
change-everything-by-dictatorship proposal), which would be easier to
set up /without/ "first-class" everywhere, I would prefer letting them
do things to be opt-in rather than opt-out - by defining a different
term that includes both players and the latest incarnation of
partnerships, and using that in those places.  My proto does not
itself create such a term because I don't think there's currently much
interest.  (You could argue that "person" provides a nice equivalence
with "can be the subject of obligations", but it's not like either of
the two current types of second-class persons is actually required to
devolve its obligations! - or perhaps "can send messages", but cron
jobs would like to disagree with you.  Stuff for the future to work
out in some interesting way, not just ignore while adding yet another
type of almost useless second-class person in the same old boring
framework.)

But I can see that as a more partisan thing that should go to a vote separately.

Incidentally, I forgot to go through and remove "first-class"
thoroughly, so there are some bugs here.

> Rule 105 "Rule Changes" does in fact do something, though I admit perhaps it 
> doesn't do very much; I'm thinking of CFJ 3300, where the existence of Rule 
> 105 allowed us to conclusively show that whichever-rule-it-was was not turned 
> into a Slave Golem (because making a rule into a Slave Golem is not a Rule 
> Change, and rules cannot be modified except via Rule Changes).

Fair enough, but I don't think that's worth keeping all that wording
around for.  Though programming analogies might cause groans, it's a
classic bit of ugly code - a bit of complication does a bunch of small
things; nobody quite knows the exact list of things, or how many of
those things are actually necessary, but there are enough different
things that it seems to be easier to keep around.  It probably seems
general and abstract, but it's also probably the wrong abstraction...

The previous paragraph is a sign I need sleep, but more concretely,
while the effect in CFJ 3300 could be replicated with a more succinct
prohibition against defining additional aspects of rules, I would
rather attack the problem a different way by generally making defining
a class of entities clearly have the semantics that entities can be
created and destroyed in that class, but whether a pre-existing entity
(what a vague term) is in that class cannot be changed.  I will
probably propose this separately.

Reply via email to