Re: DIS: Proto: Generalize Dependent Actions, version 2
1. (Technical) Automate the proposal distribution process entirely. Not likely to pass after what happened to Nomic World. What's wrong with automation? The internet is a much more stable and long-term place now then it used to be. NomicWorld has been defunct for 14-15(?) years now. A lot has changed since then. I say a lot could be automated (reports, distribution, assignment of CFJs, etc.) without causing harm to the game. As long as there is a provision to manually override any automation, then why not? BobTHJ
DIS: Proto: Generalize Dependent Actions, version 2
Maud wrote: How temporary should it be? Only until the current state of emergency has passed. (by temporary, I meant temporary way of killing a proposal until we fixed abortion not a temporary power). What is the real role of the Speaker? A true prize for winning the game; I'd suggest the best prize is greater impact on the Ruleset for the next game (e.g. greater voice on proposals). I'd personally like to see different Speakers impart different flavors to their regimes. Maybe a little like FRC, but more like past Agora; for example, when Speaker lee said e would as a matter of policy, make all oligarchic proposals democratic which was a speaker's power at the time. A secondary benefit would be emergency powers for killing bad proposals/invasions/scams. The problem, of course, is if the speaker regularly uses eir powers to promote every scam that comes along with eir powers. Of course, that's part of a regime's flavor... -Goethe
Re: DIS: Proto: Generalize Dependent Actions, version 2
Roger Hicks wrote: What's wrong with automation? It goes away when its maintainer does. It has in some cases not in fact been kept up to date. If it bypasses email, there's no reliable record of the transactions that actually occurred. I'm all in favour of automation, as a tool for officers to execute their obligations. I have used varying degrees of automation each time that I have held office in Agora. But ultimately we need to have an AI-complete entity (with present technology, a human) responsible for carrying out the official duties. If you prefer, the responsibility is not so much for performing the duties directly, and more for ensuring that automation is in place, kept up to date, and running smoothly. *That* can't be delegated to a hundred lines of Perl. The condition for appropriate use of automation is pretty much that it's appropriate if it can't be noticed. The human+program ensemble has to be responsive to changes in the rules, claims of irregularity, reinterpretations, and exceptions in crisis situations. It has to respond to and in English. That's all we require, and I'll be impressed if you can do it without the human. -zefram
Re: DIS: Proto: Generalize Dependent Actions, version 2
Sorry, I wasn't very clear. What you describe is more or less what I was referring to regarding manual override. For instance, I have no problem with a bot distributing Proposals automatically as long as at least one player (or more preferably a chain of command) has the ability to manually distribute Proposals as well, should the bot be down, or should a unique situation arise requiring it. Another place where automation might be of good benefit is with my economic proposals. An automated web-page can easily track transfers of property and property ownership taking 90% of the hassle out of it. An audit record can be maintained by sending e-mail notification of all transactions to the mailing list, and provisions can be allowed for the Secretary of the Treasury to be able to manually undo or make transactions. The rule would simply need to state that the Secretary must maintain records and historical information on the list for audit purposes. BobTHJ On 5/22/07, Zefram [EMAIL PROTECTED] wrote: Roger Hicks wrote: What's wrong with automation? It goes away when its maintainer does. It has in some cases not in fact been kept up to date. If it bypasses email, there's no reliable record of the transactions that actually occurred. I'm all in favour of automation, as a tool for officers to execute their obligations. I have used varying degrees of automation each time that I have held office in Agora. But ultimately we need to have an AI-complete entity (with present technology, a human) responsible for carrying out the official duties. If you prefer, the responsibility is not so much for performing the duties directly, and more for ensuring that automation is in place, kept up to date, and running smoothly. *That* can't be delegated to a hundred lines of Perl. The condition for appropriate use of automation is pretty much that it's appropriate if it can't be noticed. The human+program ensemble has to be responsive to changes in the rules, claims of irregularity, reinterpretations, and exceptions in crisis situations. It has to respond to and in English. That's all we require, and I'll be impressed if you can do it without the human. -zefram
Re: DIS: Proto: Generalize Dependent Actions, version 2
Michael Slone wrote: The default time limit for a collective action is (a) fourteen days, if the action is not the adoption of a proposal; or (b) forever and a day, if the action is the adoption of a proposal. Suggest that you make (a) be the default, and then override this in the rules about proposals. A vote on a collective action is valid if ... (d) the vote has not been retracted; and (e) the number of unretracted votes submitted by that player on that action is strictly less than that player's voting limit on that action. These two don't work together. (d) only makes sense if you're applying these conditions at (or after) the end of the voting period. (e) needs to be applied at the time the vote is cast. Each collective action has a support index, an objection index, a present index, and a voting index. presence index would flow better. An action achieves quorum if the present index is at least the quorum for that action. This is out of place and ought to go in the An action is approved if list. The voting limit of an active player that is not lively is one less than it would be if the player were lively. This is unnecessary. The defaults that you've set imply this already, provided that everything else that sets VLOP refers to the default rather than an explicit one. A player is lively if e is active and a natural person. This definition is used in more than one rule, and so should go into a definition rule. The adoption index of a proposal is a positive integer multiple of 0.1, defaulting to 1. Need to require a minimum AI of 1. The effect of that is implicit in the current rules, in the requirement that a proposal achieve a majority in order to be adopted. With the generalisation that a collective decision can be approved with a minority of votes, it is necessary to make the restriction here. Any player is permitted to distribute a proposal in the Proposal Pool. While retaining the Promotor, I don't think this provision brings sufficient benefit to be worthwhile. I think Promotorless proposal adoption is better handled by letting a player temporarily take over the job of Promotor if the Promotor is tardy, which is already possible via Timing Orders. set to the current number of players plus one, other rules governing quorum notwithstanding. Stop messing about: set it to Unanimity. Or, after reintroduce indices, positive infinity, since quorum is a count rather than a ratio. The maximum objection index of Unanimity should also be positive infinity, for the same reason. -zefram
Re: DIS: Proto: Generalize Dependent Actions, version 2
On 5/21/07, Kerim Aydin [EMAIL PROTECTED] wrote: A couple years back I floated something similar, Steve's comment was how do we keep our proposal numbering system straight, it's a substantial historical series. Not that it's a bad idea, but it's worth pondering. I think the formal distribution adds a little parliamentary flavor. -Goethe 1. (Technical) Automate the proposal distribution process entirely. Not likely to pass after what happened to Nomic World. 2. (Semi-technical) Require each player who wishes to distribute a proposal get a ticket number from an N + 1 server. 3. (Semi-customary) ``Within 72 hours from the time a proposal is distributed, the Promotor shall assign it a proposal number for reference.'' -- C. Maud Image (Michael Slone) You know you're not abusing your station enough when people don't want you out. -- root, in agora-discussion
Re: DIS: Proto: Generalize Dependent Actions, version 2
On 5/21/07, Zefram [EMAIL PROTECTED] wrote: These two don't work together. (d) only makes sense if you're applying these conditions at (or after) the end of the voting period. (e) needs to be applied at the time the vote is cast. I was hoping people wouldn't notice that they lose *all* their votes if they cast too many, bwa ha ha. This is unnecessary. The defaults that you've set imply this already, provided that everything else that sets VLOP refers to the default rather than an explicit one. I really don't understand why people are afraid of the tiniest bit of redundancy in the rules. Where we have irredundancy, it will come back to haunt us. Stop messing about: set it to Unanimity. Or, after reintroduce indices, positive infinity, since quorum is a count rather than a ratio. The maximum objection index of Unanimity should also be positive infinity, for the same reason. First, there is a difference between N + 1 and Unanimity, since players could register and help bring something to quorum (one would probably require at least two, since the Speaker is unlikely to vote on something e vetoes). Second, ``Reintroduce indices'' specifically defines Unanimity as a synonym for the maximum element of the extended real numbers, so there's no reason to use the term ``positive infinity'' where ``unanimity'' will do. Third, I'd like to know the historical reasons for why the Speaker's veto doesn't just kill the proposal. -- C. Maud Image (Michael Slone) Well, it's succinct, at least. -- Kelly, in agora-discussion
DIS: Proto: Generalize Dependent Actions, version 2
Here is a version of Generalize Dependent Actions which attempts to include the adoption of proposals under its umbrella. Rather than getting rid of the Promotor and Assessor, I allow a player to distribute a proposal on eir own if e wants and have the Promotor do it if nobody else does. There are still some sketchy things. In particular, the effect of time limit needs to be clearly stated somewhere. I found four rules to repeal, some of them by incorporating the essential part of the rule in a more appropriate place. -- Protoproposal h0138 (AI=2) Generalize Dependent Actions The provisions of this (proto)proposal are nonseverable. == Section 0. Basic definitions. -- Change the title of rule 693 (Agoran Decisions) to Collective Action. Amend rule 693 to read: An action is collective if and only if the rules so indicate. The default voting period for a collective action is one week. The default time limit for a collective action is (a) fourteen days, if the action is not the adoption of a proposal; or (b) forever and a day, if the action is the adoption of a proposal. Change the title of rule 1728 (Dependent Actions) to Classes of Collective Actions. Amend rule 1728 to read: The following classes of collective actions are defined: (a) actions with N supporters, for which the required support is a nonnegative integer N, the maximum objection count is Unanimity, and the adoption index is zero; (b) actions without N objections, for which the required support is zero, the maximum objection count is a positive integer N, the adoption index is zero, and the voting period is four days; (c) actions with Agoran consent, for which the required support is one, the maximum objection count is Unanimity, the adoption index is one, and the voting period is four days; (d) adopting a proposal, for which the required support is one, the maximum objection count is Unanimity, and the adoption index is the adoption index of the proposal. An action with support is an action with one supporter, and an action without objection is an action without one objection. Change the title of rule 107 (Initiating Agoran Decisions) to Intent to Perform a Collective Action. Amend rule 107 to read: A notice of intent to perform a collective action is a document which unambiguously describes an action and sets out the intent to perform the action. The notice is valid if and only if (a) the rules authorise the author to publish the notice; (b) in combination, the rules and the notice explicitly state the support index, objection index, and adoption index for the action; and (c) the notice satisfies any other requirements placed upon it by other rules. [This will be reworded to talk about collective actions.] An actor can announce intent to perform a dependent action only by publishing a valid notice of intent to that effect. The voting period for a dependent action begins when a valid notice of intent to perform the action is published. Change the title of rule 208 (Resolving Agoran decisions) to Performing Collective Actions. Amend rule 208 to read: A notice of collective action is a document which unambiguously describes a collective action and clearly indicates that the author performs it. The notice is valid if and only if (a) one of the following is true: (1) the actor announced intent to perform exactly that action; (2) the actor is an office required to perform the action if it is approved, and another office announced and was required to announce intent to perform exactly that action; or (3) the entity required to perform the action has not yet performed it, at least seven days have passed since the end of the voting period for the action, and the actor has announced that e takes up the role of vote collector for the action; (b) either (1) the voting period for the action has ended or (2) the action is an action with N supporters; [clarify when time limit begins] (c) the time limit for performing the action has not yet passed; and (d) the action is approved. An actor can perform a collective action by publishing a valid notice of collective action. An actor who could perform an action either as a regular action or as a collective action need not perform it as a collective action. A rule authorising the performance of a collective action may restrict the eligibility of players to support or
DIS: Proto: Generalize Dependent Actions
In this proto, I attempt to average dependent actions and actions with Agoran consent. -- Protoproposal h0138 (AI=2) Generalize Dependent Actions Amend rule 1728 (Dependent Actions) to read: A notice of intent to perform a dependent action is a document which sets out the intent to perform an unambiguously described dependent action. The notice is valid if and only if (a) the notice is public; (b) the described action is a dependent action its publisher is authorised to perform; and (c) in conjunction, the rules and the notice explicitly state the support index, objection index, and adoption index for the action. An actor can perform a dependent action by announcement. E is permitted to make such an announcement if and only if (a) the actor published a valid notice of intent to perform the action; (b) no more than fourteen days have passed since the announcement of intent to perform the action; (c) either the action is with N supporters or at least four days have passed since the notice of intent to perform the action was published; (d) either (1) the actor is a player or (2) the actor is an office, and the office is required or privileged to perform the action; (e) either the actor published the notice of intent or the entity that published the notice of intent was authorised to perform the action by virtue of holding a rules-defined position the actor holds at the time of eir announcement; (f) at the time of the actor's announcement, (1) the number of players who have published and not publicly retracted support for the action (the Yays) meets or exceeds the support index for the action; (2) the number of players who have published and not public retracted objections to the action (the Nays) is strictly less than by the objection index for the action; and (3) the ratio of the Yays to the Nays meets or exceeds the adoption index for the action. The specification in the rules that an action can be performed dependently does not prohibit performing that action independently if doing so would otherwise be permissible. A rule authorising the performance of a dependent action may restrict the eligibility of players to support or object to that specific action. Change the title of rule 2124 (Agoran Consent) to Classes of Dependent Actions. Amend rule 2124 to read: The following classes of dependent actions are defined: (a) actions with N supporters, for which the support index is a nonnegative integer N, the objection index is Unanimity, and the adoption index is zero; (b) actions without N objections, for which the support index is zero, the objection index is a positive integer N, and the adoption index is zero; (c) actions with Agoran consent, for which the support index is one, the objection index is zero, and the adoption index is one. An action with support is an action with one supporter, and an action without objection is an action without one objection. -- -- C. Maud Image (Michael Slone) (This makes me sad.) -- Sherlock, in agora-discussion
Re: DIS: Proto: Generalize Dependent Actions
Maud wrote: In this proto, I attempt to average dependent actions and actions with Agoran consent. I can't help but feel that a proto to adopt proposals with Agoran consent is right around the corner.
