On Sat, Aug 8, 2009 at 8:07 AM, Geoffrey Spear<geoffsp...@gmail.com> wrote:
> The text report at http://www.nomictools.com/agora/registrar is pretty
> much up to date with my recordkeeping. I have plans to introduce a
> RESTful interface to the registration data in the near future.
ITT: redundancy. *sigh*
Why can't we just have an interface that
- is open-source (so we know what's going on, and can replicate it to
another server if the original one goes down),
- is cross-platform (so I can run it),
- is easy to change (preferably gives recordkeepors the ability to
change the portions of the code related to their corner of the game),
and
- is versioned (so we don't have to fall back to email records to
check old gamestate, and can more easily verify it)
Then we wouldn't need five competing recordkeeping systems (of which
BobTHJ's is by far the most complete, but it isn't complete and
fulfills the least of those goals).
Having it track everything avoids a lot of duplicate work, but
depending on one person to recordkeep everything is a bad idea.
Self-service or split work is a good idea-- I think it would be best
if anyone could go on and recordkeep what hasn't been done yet.
The above goals range from most to least important. In particular,
adding versioning, as well as many other fancy features, is easier if
anyone can contribute the programming.
I was going to send a long rant about this, but I don't feel like
editing it, so here's Suber on why staying with BobTHJ's system as is
is a bad idea:
{
Players who try to go beyond text processing and actually put some
Nomic bookkeeping in a program are warned that the complexities are
subtle. First, such a program should be as easy to modify as the rules
of the game, or else the difficulty of changing it will put an
unwanted brake on play. Moreover, it is very easy inadvertently to
give the program decisions to make that are not actually clerical and
that belong to the players, that is, to change Nomic without realizing
it. This is true even of the most deceptively simple decisions such as
renumbering rules after amendment, computing scores, and deciding who
plays next. For the same reasons, mere word processing can introduce
distortions. Decisions necessary to write a program or edit text may
require a precision not explicit in the rule as written, in which case
the programmer usurps the power of the game Judge if she simply
chooses a reading of the rule. In any case, the game Judge should be
the final arbiter of all questions and decisions, even those made by a
program, unless of course a rule has changed the role of the Judge.
}
-Peter Suber, The Paradox of Self-Amendment
I believe there are already symptoms of these problems: consider
Murphy's objections some months ago to changes in the appeal
mechanism, or the current temporal quorum issue. If the programmer is
too lazy to change his code, and it is not open source and nobody else
can change it, there were always be a bias toward staying with the
current rules depending on the programmer.
On the other hand, consider the AAA/PBA situation last year for an
example of where the lack of automation is detrimental to the game.
In this case also, open source would help as ehird and BobTHJ could
have just used the same system.
BobTHJ's database is a promising candidate and tracks a large portion
of the gamestate, but it fails the portability and versioning goals; I
haven't seen any other script with the potential to track
"everything". So I think the best approach is to start fresh.
--
-c.
