From owner-nomic Fri Jun 23 12:10:06 2000 Received: (from majordom@localhost) by majordomo.iastate.edu (8.8.5/8.8.2) id MAA23002 for nomic-outgoing; Fri, 23 Jun 2000 12:01:26 -0500 (CDT) X-Authentication-Warning: majordomo.iastate.edu: Processed from queue /local2/spool/majordomo/nomic Received: from pop-4.iastate.edu (pop-4.iastate.edu [129.186.1.64]) by majordomo.iastate.edu (8.8.5/8.8.2) with ESMTP id MAA23863 for ; Fri, 23 Jun 2000 12:01:24 -0500 (CDT) Received: from dial-v90-2-99.ppp.iastate.edu (dial-v90-2-99.ppp.iastate.edu [129.186.99.219]) by pop-4.iastate.edu (8.9.3/8.9.3) with SMTP id MAA01205 for ; Fri, 23 Jun 2000 12:01:23 -0500 Received: (qmail 24839 invoked by uid 500); 23 Jun 2000 16:58:32 -0000 Message-ID: <20000623165832.24837.qmail@dial-v90-2-99.ppp.iastate.edu> X-Mailer: exmh version 2.1.1 10/15/1999 To: nomic@iastate.edu Subject: Nomic: 2 things From: Joel Uckelman Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jun 2000 11:58:32 -0500 Sender: owner-nomic@iastate.edu Precedence: bulk Reply-To: nomic@iastate.edu 1. First, I'd like to welcome those who have (re)subscribed to the Berserker Nomic mailing list in the last few weeks. It's good to see that there's interest in getting things rolling again. 2. One important thing I think we need to decide before resuming play is what sort of ontology of actions we want. I see two possibilities (though I don't claim this to be exhaustive), analogous to physical and human-created law. The former was how we, for the most part, conducted Berserker. Under such a system, illegal and impossible are synonymous--the rules serve as abstract limitations within our game just as physical laws constrain our actions in the world. Thus, I could no more break a rule than travel faster than light. The latter system, like human-created bodies of law, does not itself limit the actions of agents under its jurisdiction--i.e., the existence of a law against theft does not make it impossible for me to steal--instead, it might stipulate a course of action in the event of its violation--i.e., it caught, I am arrested and thrown in jail. I tend to prefer the second system due to some drawbacks of the first. Since illegal actions were impossible in Berserker, judicial decisions could result in the identification as a non-event of something hitherto thought to be an in-game event. This leads to the awkward situation of either a) rewinding the game to the point at which the non-event occurred or b) undoing just those actions made possible by the non-event. The former seemed (and still seems) too drastic though it would, strictly speaking, be the correct response to such a situation. Understandably, we chose b). Additionally, we added a statute of limitations, which declared "actions" not judicially challenged within two turns to be legal. On reflection, I think such a rule in a physics-like game is simply unintelligible. Note the actual text of the rule: Rule 455/0(m) : Statute of Limitations A Judgment may not undo actions that occurred more than two turns prior to its corresponding Request for Judgment. All such actions are to be considered legal and in accord with the Rules. The problem stems from determining the referent of "actions". In a physics-like game, the rules specify what actions are possible--thus, for something to be termed an action, it must be possible within the game. Presumably, when a player attempts something within the game it will from that point either be an action or a non-action. Thus, if it is an action, R455/0 is inoperative, because actions are legal *by definition*; conversely, if it is a non-action, R455/0 has nothing to say about it--it guards only actions from legal challenge. What's worse, if this rule is construed as it was intended, it would actually have us altering the past, which raises a host of difficult questions. At this point, it might be objected that the difficulties I note are due to poor implementation of the idea and not a flaw in the idea itself. I grant this is possible, but have yet to devise a scheme in which something like this does work. An advantage of a law-like system is that there is no question about what actions happened--all actions are possible. Instead, the courts must decide which actions are illegal and must be reversed (or ignored). What does everyone else think about this? Tom and I talked about it some a few days ago, so I'm sure he has something to say about it... -- J. Uckelman uckelman@iastate.edu http://www.public.iastate.edu/~uckelman/ From owner-nomic Fri Jun 23 12:20:07 2000 Received: (from majordom@localhost) by majordomo.iastate.edu (8.8.5/8.8.2) id MAA23767 for nomic-outgoing; Fri, 23 Jun 2000 12:20:03 -0500 (CDT) X-Authentication-Warning: majordomo.iastate.edu: Processed from queue /local2/spool/majordomo/nomic Received: from mailhub.iastate.edu (mailhub.iastate.edu [129.186.1.102]) by majordomo.iastate.edu (8.8.5/8.8.2) with ESMTP id MAA23403 for ; Fri, 23 Jun 2000 12:19:59 -0500 (CDT) Received: from heavyweight (adsl165.desm.uswest.net [207.108.47.165]) by mailhub.iastate.edu (8.9.3/8.9.3) with ESMTP id MAA31054 for ; Fri, 23 Jun 2000 12:19:58 -0500 Message-Id: <4.2.0.58.20000623122023.00a03390@mpotter.mail.iastate.edu> X-Sender: mpotter@mpotter.mail.iastate.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 23 Jun 2000 12:22:07 -0500 To: nomic@iastate.edu From: Matthew G Potter Subject: Re: Nomic: 2 things In-Reply-To: <20000623165832.24837.qmail@dial-v90-2-99.ppp.iastate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nomic@iastate.edu Precedence: bulk Reply-To: nomic@iastate.edu It's merely symptomatic of our postmodern ennui. There are no absolutes, unless you define our life as meaningless, when it's really your own freedom you detest! ...I like pork! From owner-nomic Fri Jun 23 20:50:06 2000 Received: (from majordom@localhost) by majordomo.iastate.edu (8.8.5/8.8.2) id UAA25859 for nomic-outgoing; Fri, 23 Jun 2000 20:45:00 -0500 (CDT) X-Authentication-Warning: majordomo.iastate.edu: Processed from queue /local2/spool/majordomo/nomic Received: from pop-4.iastate.edu (pop-4.iastate.edu [129.186.1.64]) by majordomo.iastate.edu (8.8.5/8.8.2) with ESMTP id UAA26622 for ; Fri, 23 Jun 2000 20:44:58 -0500 (CDT) Received: from pv3eac.vincent.iastate.edu (pv3eac.vincent.iastate.edu [129.186.62.172]) by pop-4.iastate.edu (8.9.3/8.9.3) with ESMTP id UAA00677 for ; Fri, 23 Jun 2000 20:44:56 -0500 Received: from localhost (kortbein@localhost) by pv3eac.vincent.iastate.edu (8.8.5/8.8.5) with SMTP id UAA07492 for ; Fri, 23 Jun 2000 20:44:55 -0500 (CDT) Message-Id: <200006240144.UAA07492@pv3eac.vincent.iastate.edu> To: nomic@iastate.edu Subject: Re: Nomic: 2 things In-reply-to: Your message of "Fri, 23 Jun 2000 11:58:32 CDT." <20000623165832.24837.qmail@dial-v90-2-99.ppp.iastate.edu> Date: Fri, 23 Jun 2000 20:44:55 CDT From: desert search for techno allah Sender: owner-nomic@iastate.edu Precedence: bulk Reply-To: nomic@iastate.edu Joel Uckelman writes: >An advantage of a law-like system is that there is no question about what >actions happened--all actions are possible. Instead, the courts must decide >which actions are illegal and must be reversed (or ignored). What does >everyone else think about this? Tom and I talked about it some a few days ago, >so I'm sure he has something to say about it... I see this as the only reasonable alternative. Physics-like (physicist?) rules have no place in a game of this format. Because any action is either (a) specified to "happen" according to the rules when some set of conditions are met, or (b) prompted by a player's "speech" via email, we should do what these kinds of actions suggest. Speech acts suggest a mirroring of typical real-life legislative or parlimentary procedure - things "happen" when they happen according to the rules, but there are also safeguards which say when things didn't happen according to the rules. I think it's best here to avoid confusing terminology - certainly every even "happens" in this case, but that's not the point. Using words like "reversed" or "ignored" seems to be a throwback to "undoing" actions, which is the kind of language we don't want. If the president suddenly stepped to the mic and started firing underlings and asking for his bitches, but was later found to be (at the time) mentally unstable, it seems the government wouldn't "undo" the firings, it would simply note that the president's utterances had had no effect. On the other hand, if the president made pronouncements which had, say, economic effects, and those effects were actually tangible (someone actually loses money that was once theirs), "undoing" actions makes more sense. Still it makes more sense to me, rather than "rewinding" the game as if it were some large state machine, to just effect the change through game machinery on a less total level: give the money back. But don't "undo" anything. There may be a slight problem, though. Actions under (a) above seem highly physicist. How do they interact with (b)? Josh -- josh blog: http://www.public.iastate.edu/~kortbein/blog/ tdr: http://www.public.iastate.edu/~kortbein/tdr/ From owner-nomic Fri Jun 23 22:00:06 2000 Received: (from majordom@localhost) by majordomo.iastate.edu (8.8.5/8.8.2) id VAA27015 for nomic-outgoing; Fri, 23 Jun 2000 21:58:32 -0500 (CDT) X-Authentication-Warning: majordomo.iastate.edu: Processed from queue /local2/spool/majordomo/nomic Received: from pop-3.iastate.edu (pop-3.iastate.edu [129.186.1.63]) by majordomo.iastate.edu (8.8.5/8.8.2) with ESMTP id VAA26814 for ; Fri, 23 Jun 2000 21:58:29 -0500 (CDT) Received: from dial-v90-2-15.ppp.iastate.edu (dial-v90-2-15.ppp.iastate.edu [129.186.99.35]) by pop-3.iastate.edu (8.9.3/8.9.3) with SMTP id VAA26508 for ; Fri, 23 Jun 2000 21:58:28 -0500 Received: (qmail 3509 invoked by uid 500); 24 Jun 2000 02:55:36 -0000 Message-ID: <20000624025536.3507.qmail@dial-v90-2-15.ppp.iastate.edu> X-Mailer: exmh version 2.1.1 10/15/1999 To: nomic@iastate.edu Subject: Re: Nomic: 2 things In-Reply-To: Your message of "Fri, 23 Jun 2000 20:44:55 CDT." <200006240144.UAA07492@pv3eac.vincent.iastate.edu> From: Joel Uckelman Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jun 2000 21:55:36 -0500 Sender: owner-nomic@iastate.edu Precedence: bulk Reply-To: nomic@iastate.edu > > Joel Uckelman writes: > >An advantage of a law-like system is that there is no question about what > >actions happened--all actions are possible. Instead, the courts must decide > >which actions are illegal and must be reversed (or ignored). What does > >everyone else think about this? Tom and I talked about it some a few days ago, > >so I'm sure he has something to say about it... > > I see this as the only reasonable alternative. Physics-like (physicist?) > rules have no place in a game of this format. Because any action is > either (a) specified to "happen" according to the rules when some > set of conditions are met, or (b) prompted by a player's "speech" > via email, we should do what these kinds of actions suggest. > > Speech acts suggest a mirroring of typical real-life legislative > or parlimentary procedure - things "happen" when they happen according > to the rules, but there are also safeguards which say when things > didn't happen according to the rules. I think it's best here to > avoid confusing terminology - certainly every even "happens" in > this case, but that's not the point. Using words like "reversed" > or "ignored" seems to be a throwback to "undoing" actions, which > is the kind of language we don't want. Mea culpa. This is a difficult thing to talk about precisely; the same words can seemingly apply to both cases. What I meant by "reversed" was something akin to "set back to the way things were before", in the sense that I can "reverse" rearranging my furniture by spending more time moving it back the way it was after having changed it arrangement. The implication that I could make it so I had never moved my furniture in the first place is what I'm opposing; nothing of this sort was meant. > If the president suddenly > stepped to the mic and started firing underlings and asking for > his bitches, but was later found to be (at the time) mentally > unstable, it seems the government wouldn't "undo" the firings, > it would simply note that the president's utterances had had no > effect. > > On the other hand, if the president made pronouncements which > had, say, economic effects, and those effects were actually > tangible (someone actually loses money that was once theirs), > "undoing" actions makes more sense. Still it makes more sense to me, > rather than "rewinding" the game as if it were some large state > machine, to just effect the change through game machinery on > a less total level: give the money back. But don't "undo" anything. I take it you mean something akin to "restitution" here. That was what I had in mind to start with, though I didn't (and should have) make it clear. > There may be a slight problem, though. Actions under (a) above > seem highly physicist. How do they interact with (b)? > > > Josh Hmm. That's a good question. With regard to (a) do you mean things like scheduled voting? I suspect that most things of this nature would be pegged to the passage of time, and though they would be causally privileged over player actions, I'm not sure they would pose a serious problem. Perhaps an example would be enlightening. Josh? -- J. Uckelman uckelman@iastate.edu http://www.public.iastate.edu/~uckelman/ From owner-nomic Fri Jun 23 22:20:06 2000 Received: (from majordom@localhost) by majordomo.iastate.edu (8.8.5/8.8.2) id WAA27717 for nomic-outgoing; Fri, 23 Jun 2000 22:16:22 -0500 (CDT) X-Authentication-Warning: majordomo.iastate.edu: Processed from queue /local2/spool/majordomo/nomic Received: from pop-5.iastate.edu (pop-5.iastate.edu [129.186.1.65]) by majordomo.iastate.edu (8.8.5/8.8.2) with ESMTP id WAA27721 for ; Fri, 23 Jun 2000 22:16:19 -0500 (CDT) Received: from pv3eac.vincent.iastate.edu (pv3eac.vincent.iastate.edu [129.186.62.172]) by pop-5.iastate.edu (8.9.3/8.9.3) with ESMTP id WAA08021 for ; Fri, 23 Jun 2000 22:16:19 -0500 Received: from localhost (kortbein@localhost) by pv3eac.vincent.iastate.edu (8.8.5/8.8.5) with SMTP id WAA07667 for ; Fri, 23 Jun 2000 22:16:19 -0500 (CDT) Message-Id: <200006240316.WAA07667@pv3eac.vincent.iastate.edu> To: nomic@iastate.edu Subject: Re: Nomic: 2 things In-reply-to: Your message of "Fri, 23 Jun 2000 21:55:36 CDT." <20000624025536.3507.qmail@dial-v90-2-15.ppp.iastate.edu> Date: Fri, 23 Jun 2000 22:16:19 CDT From: desert search for techno allah Sender: owner-nomic@iastate.edu Precedence: bulk Reply-To: nomic@iastate.edu Joel Uckelman writes: >> There may be a slight problem, though. Actions under (a) above >> seem highly physicist. How do they interact with (b)? > >Hmm. That's a good question. With regard to (a) do you mean things like >scheduled voting? I suspect that most things of this nature would be pegged to >the passage of time, and though they would be causally privileged over player >actions, I'm not sure they would pose a serious problem. Perhaps an example >would be enlightening. Josh? Yes, I do mean things like that - also automatic transfers of property, funds, legalization and nullification of rules, etc. At the moment I can't think of any examples that cause problems. But I didn't really mean to indicate that I thought there were any interesting examples - just that, because "automatic" actions will probably be tied to the passage of real time, and thus we'll treat them much the same as we do real-life events, we may be tempted to think in similar ways about speech actions. Which we shouldn't. That's all. Josh -- josh blog: http://www.public.iastate.edu/~kortbein/blog/ tdr: http://www.public.iastate.edu/~kortbein/tdr/ From owner-nomic Fri Jun 23 22:30:06 2000 Received: (from majordom@localhost) by majordomo.iastate.edu (8.8.5/8.8.2) id WAA27525 for nomic-outgoing; Fri, 23 Jun 2000 22:25:22 -0500 (CDT) X-Authentication-Warning: majordomo.iastate.edu: Processed from queue /local2/spool/majordomo/nomic Received: from pop-5.iastate.edu (pop-5.iastate.edu [129.186.1.65]) by majordomo.iastate.edu (8.8.5/8.8.2) with ESMTP id WAA23981 for ; Fri, 23 Jun 2000 22:25:18 -0500 (CDT) Received: from mach1.wlu.ca (mach1.wlu.ca [192.54.242.17]) by pop-5.iastate.edu (8.9.3/8.9.3) with ESMTP id WAA09327 for ; Fri, 23 Jun 2000 22:25:18 -0500 Received: from localhost (wald7330@localhost) by mach1.wlu.ca (8.9.1a/8.9.1) with ESMTP id XAA24377 for ; Fri, 23 Jun 2000 23:25:20 -0400 (EDT) Date: Fri, 23 Jun 2000 23:25:19 -0400 (EDT) From: Dan Waldron To: nomic@iastate.edu Subject: Re: Nomic: 2 things In-Reply-To: <200006240316.WAA07667@pv3eac.vincent.iastate.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-nomic@iastate.edu Precedence: bulk Reply-To: nomic@iastate.edu The rules could require (and authorize) players to perform such automatic actions themselves, within a set time period. If there is to be some On Fri, 23 Jun 2000, desert search for techno allah wrote: > > Joel Uckelman writes: > >> There may be a slight problem, though. Actions under (a) above > >> seem highly physicist. How do they interact with (b)? > > > >Hmm. That's a good question. With regard to (a) do you mean things like > >scheduled voting? I suspect that most things of this nature would be pegged to > >the passage of time, and though they would be causally privileged over player > >actions, I'm not sure they would pose a serious problem. Perhaps an example > >would be enlightening. Josh? > > Yes, I do mean things like that - also automatic transfers of property, > funds, legalization and nullification of rules, etc. > > At the moment I can't think of any examples that cause problems. > But I didn't really mean to indicate that I thought there were > any interesting examples - just that, because "automatic" actions > will probably be tied to the passage of real time, and thus we'll > treat them much the same as we do real-life events, we may be > tempted to think in similar ways about speech actions. Which > we shouldn't. That's all. > > > Josh > > -- > josh blog: http://www.public.iastate.edu/~kortbein/blog/ > tdr: http://www.public.iastate.edu/~kortbein/tdr/ > From owner-nomic Mon Jun 26 13:50:07 2000 Received: (from majordom@localhost) by majordomo.iastate.edu (8.8.5/8.8.2) id NAA23219 for nomic-outgoing; Mon, 26 Jun 2000 13:40:28 -0500 (CDT) X-Authentication-Warning: majordomo.iastate.edu: Processed from queue /local2/spool/majordomo/nomic Received: from pop-4.iastate.edu (pop-4.iastate.edu [129.186.1.64]) by majordomo.iastate.edu (8.8.5/8.8.2) with ESMTP id NAA23622 for ; Mon, 26 Jun 2000 13:40:25 -0500 (CDT) Received: from thomson.uni2.net (thomson.uni2.net [195.82.195.104]) by pop-4.iastate.edu (8.9.3/8.9.3) with ESMTP id NAA09811 for ; Mon, 26 Jun 2000 13:40:24 -0500 Received: from richardmayhew (p457-17.ppp.get2net.dk [195.47.135.17]) by thomson.uni2.net (8.10.0/8.9.1) with SMTP id e5QIeCD24512 for ; Mon, 26 Jun 2000 20:40:12 +0200 Message-ID: <015901bfdf9d$8723e7c0$9b812fc3@richardmayhew> From: "Ole Andersen" To: References: <200005301937.OAA15804@isua3.iastate.edu> Subject: Re: Nomic: Okay.. Date: Mon, 26 Jun 2000 19:28:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by majordomo.iastate.edu id NAA23220 Sender: owner-nomic@iastate.edu Precedence: bulk Reply-To: nomic@iastate.edu Aye-aye -- Ole Andersen Brøndbyøster, Denmark palnatoke@get2net.dk If you're gonna try this, drop a couple of lemons into the water. Road kill stinks when you cook it. -Camille Landry-Gaters ----- Original Message ----- From: "Tom Plagge" To: Sent: Tuesday, May 30, 2000 9:37 PM Subject: Nomic: Okay.. : All in favor of some sort of a constitutional convention followed : by a full game reboot say aye. : From owner-nomic Thu Jun 29 00:10:10 2000 Received: (from majordom@localhost) by majordomo.iastate.edu (8.8.5/8.8.2) id AAA25803 for nomic-outgoing; Thu, 29 Jun 2000 00:01:14 -0500 (CDT) X-Authentication-Warning: majordomo.iastate.edu: Processed from queue /local2/spool/majordomo/nomic Received: from pop-5.iastate.edu (pop-5.iastate.edu [129.186.1.65]) by majordomo.iastate.edu (8.8.5/8.8.2) with ESMTP id AAA25668 for ; Thu, 29 Jun 2000 00:01:09 -0500 (CDT) Received: from dial-v90-2-14.ppp.iastate.edu (dial-v90-2-14.ppp.iastate.edu [129.186.99.34]) by pop-5.iastate.edu (8.9.3/8.9.3) with SMTP id AAA18818 for ; Thu, 29 Jun 2000 00:01:08 -0500 Received: (qmail 31254 invoked by uid 500); 29 Jun 2000 04:57:53 -0000 Message-ID: <20000629045753.31252.qmail@dial-v90-2-14.ppp.iastate.edu> X-Mailer: exmh version 2.1.1 10/15/1999 To: nomic@iastate.edu Subject: Nomic: automation status From: Joel Uckelman Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Jun 2000 23:57:53 -0500 Sender: owner-nomic@iastate.edu Precedence: bulk Reply-To: nomic@iastate.edu I'm sure at least one or two people have been wondering how work has been progressing with regard to admin automation stuff. I'm working on the last essential component now, the script that filters frequently taken and sufficiently standardized actions from messages to the mailing list, and from them automatically updates various data files from which html is generated. An example: If I send a message to the list that looks something like this, --------- To: nomic@iastate.edu Subject: foo! From: Joel Uckelman Date: Fri, 23 Jun 2000 21:55:36 -0500 This is my brand new proposal: 12 March will hereafter be known as Berserker Nomic Day. -------- the filter will see the tags, correctly format the proposal, append it to the proposal data file, assign it a number, and send a message with that number back to the list. The new proposal will then appear on the web page after the next time the update program is run (probably every few hours). In case anyone would want to include a tag in the text of a proposal, it would have to be backslashed, (e.g. \) to show up correctly. Does this seem reasonably simple to everyone? Does anyone have any suggestions for how this should/shouldn't be implemented, before I finish coding it? -- J. Uckelman uckelman@iastate.edu http://www.public.iastate.edu/~uckelman/ From owner-nomic Thu Jun 29 22:10:06 2000 Received: (from majordom@localhost) by majordomo.iastate.edu (8.8.5/8.8.2) id WAA05357 for nomic-outgoing; Thu, 29 Jun 2000 22:06:52 -0500 (CDT) X-Authentication-Warning: majordomo.iastate.edu: Processed from queue /local2/spool/majordomo/nomic Received: from mailhub.iastate.edu (mailhub.iastate.edu [129.186.1.102]) by majordomo.iastate.edu (8.8.5/8.8.2) with ESMTP id WAA05771 for ; Thu, 29 Jun 2000 22:06:50 -0500 (CDT) Received: from Debug (webmail-1.cc.iastate.edu [129.186.1.71]) by mailhub.iastate.edu (8.9.3/8.9.3) with SMTP id WAA29632 for ; Thu, 29 Jun 2000 22:06:50 -0500 Message-Id: <200006300306.WAA29632@mailhub.iastate.edu> To: nomic@iastate.edu From: Subject: Re: Nomic: automation status Date: Thu, 29 Jun 2000 22:06:50 CST6DST X-Mailer: Endymion MailMan Professional Edition v3.0.14 Sender: owner-nomic@iastate.edu Precedence: bulk Reply-To: nomic@iastate.edu Proposals shall be delimited by an opening and a closing tag. The opening proposal tag shall be The closing proposal tag shall be \ In the body of an email where these tags need to be named, the opening tag shall be written as and the closing tag shall be written as "the closing tag shall be written as.." (Note that the second of the two periods ends the sentence and is not actually part of the name of the tag, nor are the quotation marks.) How are immutable rules made? Can I do this? Proposals shall be delimited by an opening and a closing tag. The opening proposal tag shall be and the closing proposal tag shall be where the space between the 'p' and the 's' in both tags is replaced with an 'o'. In the body of an email where these tags need to be named, they may be written by putting a '\' character immediately before them. E.g. \ This rule shall be immutable. From owner-nomic Fri Jun 30 03:20:07 2000 Received: (from majordom@localhost) by majordomo.iastate.edu (8.8.5/8.8.2) id DAA08583 for nomic-outgoing; Fri, 30 Jun 2000 03:19:29 -0500 (CDT) X-Authentication-Warning: majordomo.iastate.edu: Processed from queue /local2/spool/majordomo/nomic Received: from mailhub.iastate.edu (mailhub.iastate.edu [129.186.1.102]) by majordomo.iastate.edu (8.8.5/8.8.2) with ESMTP id DAA08119 for ; Fri, 30 Jun 2000 03:19:27 -0500 (CDT) Received: from heavyweight (ddsl91.desm.uswest.net [207.108.37.91]) by mailhub.iastate.edu (8.9.3/8.9.3) with ESMTP id DAA07941 for ; Fri, 30 Jun 2000 03:19:26 -0500 Message-Id: <4.2.0.58.20000630031830.00944250@mpotter.mail.iastate.edu> X-Sender: mpotter@mpotter.mail.iastate.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 30 Jun 2000 03:21:35 -0500 To: nomic@iastate.edu From: Matthew G Potter Subject: Re: Nomic: automation status -> BITCHSLAP In-Reply-To: <200006300306.WAA29632@mailhub.iastate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nomic@iastate.edu Precedence: bulk Reply-To: nomic@iastate.edu You have been bitchslapped. Be thankful I don't have a nightstick. Yet. Bitch. Potter > >Proposals shall be delimited by an opening and a closing tag. The opening >proposal tag shall be The closing proposal tag shall be >\ In the body of an email where these tags need to be named, the >opening tag shall be written as and the closing tag shall be >written as "the closing tag shall be written as.." (Note that the second of >the two periods ends the sentence and is not actually part of the name of the >tag, nor are the quotation marks.) > > > >How are immutable rules made? Can I do this? > > > >Proposals shall be delimited by an opening and a closing tag. The opening >proposal tag shall be and the closing proposal tag shall be sal> where the space between the 'p' and the 's' in both tags is replaced >with >an 'o'. In the body of an email where these tags need to be named, they >may be >written by putting a '\' character immediately before them. E.g. \ >This rule shall be immutable. > > From owner-nomic Fri Jun 30 20:00:07 2000 Received: (from majordom@localhost) by majordomo.iastate.edu (8.8.5/8.8.2) id TAA18487 for nomic-outgoing; Fri, 30 Jun 2000 19:57:43 -0500 (CDT) X-Authentication-Warning: majordomo.iastate.edu: Processed from queue /local2/spool/majordomo/nomic Received: from pop-2.iastate.edu (pop-2.iastate.edu [129.186.1.62]) by majordomo.iastate.edu (8.8.5/8.8.2) with ESMTP id TAA18700 for ; Fri, 30 Jun 2000 19:57:41 -0500 (CDT) Received: from charybdis.ellipsis.cx (bdsl28.desm.uswest.net [207.108.36.28]) by pop-2.iastate.edu (8.9.3/8.9.3) with SMTP id TAA25004 for ; Fri, 30 Jun 2000 19:57:39 -0500 Received: (qmail 3385 invoked by uid 500); 1 Jul 2000 00:57:19 -0000 Message-ID: <20000701005719.3383.qmail@charybdis.ellipsis.cx> To: nomic@iastate.edu Subject: Nomic: draft ruleset From: Joel Uckelman Date: Fri, 30 Jun 2000 19:57:19 -0500 Sender: owner-nomic@iastate.edu Precedence: bulk Reply-To: nomic@iastate.edu This is something I pulled together over the last few days, using our old ruleset as a source. Most of what appears herein is in function and spirit much like Berserker's ruleset; a little of it is lifted verbatim, the rest has been stripped down, reworded, and hopefully simplified. Rules are categorized by content (roughly) and marked with a leading * instead of a rule number, for reasons which will soon become apparent. As you read this, you will notice the lack of precedence and judicial rules. Both were problematic in the past (the latter moreso than the former); both were omitted because I wasn't sure whether to follow the old model or create an new one; and these seemed to me the most likely areas over which there would be some disagreement. So in the absence of precedence rules to guide such decisions, I avoided assigning rule numbers. If there's something you don't like here, suggest a change. I haven't done more than spellcheck this, so there might be some ungramatical constructions [read: typos] to be pointed out as well. We don't have to use this when we start, but I think it provides a good place to focus discussion. -------- The Game * [game name] shall refer to the specific instance of Nomic game which possesses the body of rules containing this definition, unless it is made clear, whether explicitly or via the context, that [game name] refers to something else. To this end, all permutations of letter case of [game name] shall be considered equivalent. Players, Playerlike Entities * Playerlike entities are game objects capable of action. Playerlike entities may be created and destroyed only as specified in the rules. A playerlike entity may destroy itself, but may not create itself. [[Nihil ex nihilo.]] * A player is a playerlike entity capable of independent action. Each player must be exactly one real-world sentient being. No real-world sentient being may be more than one player. Each player must have a uniquely identifying name, which may be specified initially and changed only by the player emself. * A player forfeits by destroying emself. No restrictions may be placed on when a player may forfeit. * A new player is created whenever a Motion to Add is passed. A Motion to Add must include the prospective player's name. It may be made by any player at any time, and requires a two-thirds majority vote or unanimous consent. * All playerlike entities must always abide by all the rules then in effect, in the form in which they are then in effect. This rule takes precedence over all other rules. Motions * A player making a motion may request unanimous consent at the time the motion is made, if the rules permit it. Unanimous consent is granted if no players object within one day of the motion. * A motion passes if it receives unanimous consent or the appropriate majority. * Motions requiring voting are placed on the ballot for the next voting period. Fora * Fora are the conceptual spaces in which players communicate. Fora may be public or private. A player using a forum is considered to be in that forum at the time of its use. Actions may be taken only in public fora, unless otherwise specified in the rules. * Creation of a public forum if there are no extant public fora need not [[and cannot!]] be done publicly. * Only the Administrator may redesignate fora as private or public. Only fora reasonably accessible to all players may be designated public. Pursuant to these restrictions, the Administrator may redesignate fora at any time. The Administrator must, in a timely fashion, maintain and make available to all players a list of all public fora. Rules * The ruleset is the collective body of rules then in effect. The ruleset may be altered only as provided therein. * Each rule has a unique positive integer as its rule number, and a nonnegative integer as its revision number. A rule's revision number is initially zero, and is incremented whenever the rule is changed but not repealed. * Any change to the game state is a state change. A rule change is the enactment, repeal, amendment, or transmutation of a rule. Rule changes are state changes. * Rule changes that affect rules needed to allow or apply rule changes are as permissible as other rule changes. Even rule changes that amend or repeal their own authority are permissible. No rule-change or type of move is impermissible solely on account of the self-reference or self-application of a rule. * Whatever is not prohibited or regulated by the ruleset is permitted and unregulated, with the sole exception of rule changes, which are permitted only when a rule or set of rules explicitly or implicitly permits them. Proposals * A proposal consists of a title and one or more proposed state changes. Each proposal submitted in the proper way shall have as its proposal number the least positive integer greater than 300 never before assigned to another proposal or rule, and a nonnegative integer as its revision number. A proposal's revision number is initially zero, and is incremented whenever its owner changes but does not withdraw it. * A proposal to create multiple new rules must specify an allowable rule number for each new rule to be created. Rules created by Proposals creating only one new rule receive the number of the proposal that created them, unless otherwise specified in said proposal. * Only playerlike entities may make proposals. A proposal's owner is the playerlike entity that made it. Only the owner of a proposal may alter it, but only when the rules so allow it. Players may make proposals at any time. Each player may make up to ten proposals per day, but may own than ten live proposals. * A proposal may be live or dead. Live proposals are either active, inactive, or voting. Dead proposals are either passed, failed, or withdrawn. New proposals are active by default. Only active and inactive proposals may be altered. An active or inactive proposal may be withdrawn by its owner at any time. The owner of a proposal may change its status from active to inactive at any time, and vice versa. * Voting proposals receiving the required number of votes at the close of voting pass. Voting proposals that do not, fail. * The state changes specified in a proposal will occur if and only if the proposal meets the criteria for passage. * A proposal passes if it receives a simple majority of the non-neutral votes cast in voting on it. Sequence of Events * One nomic week, hereafter know as a nweek, is ten days in duration. At the start of the eighth day of each nweek, all active proposals become voting proposals. At the close of the last day of each nweek, all voting proposals become dead proposals, to be classified as passed or failed corresponding with the outcome of voting on them. * The first nweek begins concurrently with the first game day. Each successive nweek begins concurrently with the end of the previous nweek. * For game purposes, the day begins at 00:00:00 UCT. * The provisions of adopted proposals are considered to come into effect at the end of the nweek in which they were adopted, in order of proposal number from least to greatest. Events triggered by the close of voting occur in order of the number of the proposal that triggered them. Events triggered by the same proposal number occur in order of the precedence of the rules causing them. * Actions occur at the time they appear in the forum in which they are committed. No state changes may occur prior to the actions which caused them. Voting * Every player not in Limbo is an eligible voter. * Each player eligible to vote on a matter is entitled to cast exactly one vote on it. * A quorum is a simple majority of eligible voters. If fewer votes are cast during voting than is needed to reach a quorum, all voting proposals revert to active proposals and none are adopted; all motions fail. * Only votes equivalent to "yes" or "no" are counted toward adoption of motions and proposals. Abstentions and other non-committal votes are considered neutral. * Voting is an action that may be taken privately if the voter so desires, by notifying the Administrator in the appropriate forum. Votes may be cast only during the final two days of each nweek. Scoring * A player may not voluntarily reduce eir score below zero, nor may a player arbitrarily increase eir score. Each player begins with zero points. * Each player who votes against a successful proposal shall receive 5* (favorable votes/non-neutral votes) points, rounded to the nearest integer, at the close of the nweek in which the vote was taken. * The owner of a failed proposal loses 5 points at the close of the nweek in which it failed. * The owner of a successful proposal gains 20*(favorable votes/non-neutral votes) points, rounded to the nearest integer, at the close of the nweek in which it passed. Winning * Whenever a player's score reaches or exceeds 500 points, e shall be credited with a win. * In the even of a win, all scores are reset to their initial value. If possible, play continues normally; otherwise, play ceases. * In the even that further play becomes impossible, or if the legality of an action cannot be determined with finality, then the player who took the action is credited with a win. Limbo * There exists a place called Limbo, to which players are sent only upon failing a Limbo check or declaring themselves in Limbo. While in Limbo, players are prohibited from taking any actions except returning from Limbo or forfeiting. * Any player may, at any time, request a Limbo check on any player, including emself. The Administrator executes a Limbo check by determining when the checkee last took action, and announcing failure if the action was more than two nweeks prior to the request, passage otherwise. Offices * Players holding offices are officeholders. Players may resign from any offices they hold at any time. * The Administrator is the player who is responsible for all game duties not delegated by the rules to other officeholders. The Administrator is the player controlled by Joel Uckelman. * Officeholders, in their capacity as such, may possess privileged information. This information may not be shared with any other player, directly or indirectly, until such time as the rules make it public. * If an officeholder forfeits or goes into Limbo, e vacates the office at that time. Vacant offices are held by the Administrator until new officeholders are selected pursuant to the rules for filling the offices. Definitions * For a given r, an r-majority shall be defined as a function from the positive integers to the positive integers, whose value for an argument N is the smallest integer m such that m is greater than or equal to r multiplied by N. A simple majority shall be defined as an (N+1)/(2N)-majority. * The following table entries, known as Spivak pronouns, shall be understood to take the places of the standard English pronouns whose table entries they occupy. Where two pronouns, the male and female, are replaced by a single Spivak pronoun, the Spivak pronoun shall be understood to refer to both genders. [[Example: "e" refers to both "he" and "she".]] First Person Second Person Third Person Subject I you e Object me you em Possessive my/mine your/yours eir/eirs Reflexive myself yourself emself * The following characters: [ ] { } are considered "reserved characters" when appearing in proposals and rules in ways defined below. Brackets: Excepting any text prior to and including this sentence in this rule, any text appearing within doubled square brackets ("[[" and "]]") shall be considered "comment" text. Comment text shall not have the force of rule; its purpose is solely elucidative or demonstrative. Braces: Excepting any text prior to and including this sentence in this rule, any text appearing within double braces ("{{" and "}}") shall be considered "self-deleting" text. As soon as a proposal containing self-deleting text is passed, the following shall happen, in the following order: (1) Any self-deleting text in any rules created shall have its effect. (2) Any self-deleting text, along with its respective braces, shall be deleted from the rules. [[This provides a regular way in which to add self-removing clauses to rules.]] -- J. From owner-nomic Fri Jun 30 20:10:09 2000 Received: (from majordom@localhost) by majordomo.iastate.edu (8.8.5/8.8.2) id UAA18633 for nomic-outgoing; Fri, 30 Jun 2000 20:04:37 -0500 (CDT) X-Authentication-Warning: majordomo.iastate.edu: Processed from queue /local2/spool/majordomo/nomic Received: from pop-2.iastate.edu (pop-2.iastate.edu [129.186.1.62]) by majordomo.iastate.edu (8.8.5/8.8.2) with ESMTP id UAA18556 for ; Fri, 30 Jun 2000 20:04:35 -0500 (CDT) Received: from charybdis.ellipsis.cx (bdsl28.desm.uswest.net [207.108.36.28]) by pop-2.iastate.edu (8.9.3/8.9.3) with SMTP id UAA25508 for ; Fri, 30 Jun 2000 20:04:34 -0500 Received: (qmail 3414 invoked by uid 500); 1 Jul 2000 01:04:15 -0000 Message-ID: <20000701010415.3412.qmail@charybdis.ellipsis.cx> To: nomic@iastate.edu Subject: Nomic: precedence From: Joel Uckelman Date: Fri, 30 Jun 2000 20:04:15 -0500 Sender: owner-nomic@iastate.edu Precedence: bulk Reply-To: nomic@iastate.edu With regard to a rule precedence system, here are some possibilities that I see: 1. Provide no explicit method for resolving rule conflicts. This could be very interesting. It would put a heavy burden on the judiciary to interpret the rules. 2. Use the mutable/immutable, last-changed system we had in Berserker. It wasn't a *bad* system, though how we numbered the initial ruleset would be very important. 3. Develop some other sort of system, possibly with more than two tiers of precedence (Agora has 3; some other nomic, the name of which escapes me, uses the positive integers), or just something else entirely. Thoughts? -- J.