Re: [spoon-discuss] The time has come, the Walrus said...

["Glotmorf" <glotmorf@xxxxxxxxxxxxx>]

On 6/22/03 at 1:06 AM Daniel Lepage wrote:

>> 2. What sort of administration processing time delay is acceptable?
>>
>> Dave is worried that his life won't allow him to continue in the
>> administrative capacity at all...that it's not a question of how long
>> it'd take to complete processing a turn as much as  that his real-life
>> demands/options would impede the game to the point of
>> non-functionality.  If someone other than Dave were to attempt to do
>> the job, what sort of wait-time would be considered acceptable and
>> non-excessive?  My view on admin wait-time has been, "Take however
>> long it takes, as long as we can rest assured it'll eventually get
>> done."  On the other hand, we had that one miscreant who was willing
>> to drag our name through the mud because of wait-time.  How long is
>> too long?
>
>Who dragged our name through the mud because of wait-time? I mean,
>dude, we're one of the fastest moving nomics out there. Most nomics
>only get a few proposals every week... we get periodic entire-ruleset
>rewrites. Given how much happens, I think we've got an incredibly small
>lag.

You don't remember whatshisname?  The entity that said e wanted to join, then got pissy elsenomic when e wasn't recognized in what e thought was a timely manner?  Then again, forgetting about all that is probably just as well.

>But I wouldn't mind slowing down a bit... give me some time to finish
>other projects and whatnot.

What I meant was, right now Rule 0 lists a one-week absence as grounds for an emergency.  Dave frets and apologizes if the delay is going to be more than a day or two.  How long is too long?  I can tell you, my SO is far less understanding of online computer games than Dave's apparently is.  Were I, therefore, to admin, or even be on admin rotation, there could be delays.

>> 3. How necessary is it to separate administrative duties from
>> playerness?
>>
>> We've already got ministers for a bunch of things.  What's left that
>> absolutely requires a central administrator, and what about that which
>> is left requires or begs a non-player admin?  I still think automation
>> would go a long way, but I'll acknowledge that won't solve everything.
>
>The Admin is only really necessary for the keeping of secret
>information. Things like private votes, Bonus box locations, etc. can't
>be trusted to any normal player because they'd give so much of an
>advantage to em.

Bonus boxes are phenomena, and can be coded.  Private voting is player input, and can be handled via procmail-scripting and/or web forms.

But coding for these could take time.  If having an admin became sufficiently problematical before the code was written, perhaps those things that absolutely require adminity could be deactivated...?

>1) Proposal Scripting
>	A simple scripting language is devised to essentially automate the
>implementation of rule-changes in proposals. Nothing fancy, just forces
>people to use a format like,
>{{
>__<proposal name>__
>
>CREATE RULE
>{{
>__<rule name>__
>
><rule text>
>}};
>
>REPEAL RULE {{ <rule number> }};
>
>AMEND RULE {{ <rule number>}} REPLACE {{ <<text>> }} {{ <new text> }};
>
>AMEND RULE {{ <rule number>}} REPLACE ALL {{ <new text> }};
>}}
>Then, a simple perl/python/even c++ script can handle all the rule
>changes in proposals.

This would suffer from requirement creep -- the language would become increasingly complex to handle all possible user demands.  For example, I might want to be able to replace all instances of some text in a rule or in all rules with some other text.  Or, in the case of, say, r256 or r301, it may be desirable to be able to specify subsections as part of the rule number.

Which isn't necessarily a bad thing.  It's just that maintaining the language might become as much work as running the game.

>2) Personal Record-Keeping
>	Every player is given a small account on Nomic.net. Every player gains
>access to the props database, but only privileges to create/alter
>proposals with them as the proponent. Thus, the duty of updating 10
>props in an nweek falls to the player who busted two nweeks worth of
>bandwidth to make them. Policing could be done by the Admin, or by the
>vigilante system described next.

I suspect Joel would much rather have players maintaining their props by webform or procmail over giving out too many shell accounts on his system.  We could use virtual accounts driven by mySQL.

>3) Vigilanteism
>	A lot of ministries could be operated not by a set person, who tends
>to disappear and go on vacation, but instead by whoever gets there
>first. For example, updating the weather could be optional - it only
>happens if somebody decides, within the first day or two of an nweek,
>to update the weather. Whoever decides to do it rolls the dice for it
>and posts the results, gaining some bonus from it, say, 10 points plus
>the option to set any one weather attribute to any legal value of their
>choosing. Also, things like making sure that everyone's personal
>records are accurate could be policed by the other players - a player
>caught misrepresenting eir props would have to pay points to whoever
>caught em, and perhaps would lose that prop, and the bandwidth
>associated with it.

Would we want to pay in points?  While keeping the current victory condition?  The game could be won simply by out-obsessing-compulsing everyone else.

>4) Vote scripting
>	Similar to proposal scripting, vote scripting involves the creation of
>a special voting syntax to allow a counter program to have the text of
>messages pasted in. Things like bonus votes would be easy to add:
>P1634 YES + PROXY_YES + UIN_HAND_YES
>or maybe just: P1634 YES x 3

I remember seeing a couple times where someone who held two proxies voted yes with one and no with the other, because that's what e thought the proxied players would want.  A custom voting form could show how many votes one had and why, or an auto-email could provide unique codes for each type of vote.

Those vote codes would have to show up in the voting results lists too, so that someone can, if necessary, CFI someone else's philosophical mandate vote.

>5) Communal Recordkeeping
>	Using something like a Wiki site, records like the Grid page could be
>maintained by everyone - if you decide to run across the grid grabbing
>objects and blowing things up, it's up to you to update the page.
>	Since all changes to wiki sites can be logged, and usually are for
>sites like nomicwiki, it would be easy to see what people had done that
>they shouldn't have, and punish 'em for it.

Another upside of this is that "webpages" can be given to ministers without their needing shell accounts.  The admin would need to set access privileges for a user for a page.

>6) Email-based Records
>	Agora basically runs the entire game on email. They have three lists -
>business, discussion, and official. The first two function like ours.
>The third is for posting game records. Periodically, the various
>Officers post whatever records they're responsible for tracking,
>including things like all active proposals and the entire ruleset.
>	We could do that for a lot of things - it's easy to have ministers do
>things like Weather updates when all they need to do is post a message
>to the OFF forum. In fact, I think the official Jedi Roster page is far
>out of date now; I'm basically using the forum now already.

The forum can also be a backup for web-based or procmail-based actions, echoing the action to the public forum after it's been processed.

There was that to be said about BlogNomic: posts on the main body of the blog were the official actions, and each action had its own built-in discussion thread.  Discussions were always easy to track, and an admin only needed to skim the blog to know what had to be dealt with at a given time.

The blog software needed/would need some tweaks, though.  Archiving was hard to control, and, if actions were to be processed out of order, then processed actions would have to somehow drop down below unprocessed actions.

						Glotmorf

-----
The Ivory Mini-Tower: a blog study in Social Technology.
http://ix.1sound.com/ivoryminitower

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