Re: [s-b] Refresh Prop, take 3

["Peter Cooper Jr." <pete+bnomic@xxxxxxxxxxxxx>]

Just to make sure that there exists at least one thing to vote on, I
submit the following >-quoted prop as my Refresh Proposal. Thank you
Wonko for putting this together, but since you haven't submitted it
yet, I will. (We may want to update our Emergency Procedure soon to
deal with no proposal submissions, and/or let us accelerate/decelerate
the process as needed.)

Daniel Lepage <dpl33@xxxxxxxxxxx> writes:
> {{
> __Fixing the World__
>
> Replace the text of rule 2-2 with:
> {{
> == Proposals ==
>
> === Definition ===
>
> Proposals are Game Documents. Each proposal has the following  
> properties:
> * A Title, which is a string
> * A Body, which is a block of text that contains a list of changes to  
> be made to the gamestate
> * A Status, which is one of Pending, Open, or Historical
> * A Success state, which is one of Won, Lost or Undecided
> * A Proposal Number, which is an integer or null
> * A set of Conflicts, which are other proposals
> * A set of Dependencies, which are other proposals
>
> If, in a set of two proposals, either lists the other as a Conflict,  
> those proposals are said to Conflict with each other.
>
> If one proposal lists another on its list of Dependencies, then the  
> first is said to Depend on the second.
>
> /* Note that a proposal may contain text in addition to its list of  
> gamestate changes, but this text is generally ignored. It may be  
> unclear whether or not a particular part of the text is a gamestate  
> change; determining this is left to the Administrator and the justice  
> system. */
>
> === Submission and Revision ===
>
> Any player may submit a proposal at any time, or may revise a Pending  
> proposal e owns by resubmitting it, unless a rule says otherwise. To  
> submit a proposal, a player need only specify its Body. E may  
> optionally also specify its Title, Conflicts, and Dependencies; if  
> any of these are not specified, they default to being empty.
>
> The player who submits a proposal is known as the Proposal's Author,  
> and is said to own that proposal.
>
> When a new proposal is submitted, it is assigned the Status Pending,  
> the Success state Undecided, and the Proposal Number null. The  
> Administrator must then assign it a new Proposal Number that is  
> greater than all previously used Proposal Numbers as soon as e can.
>
> /* Note that this doesn't include other things called Proposal  
> Numbers from the distant past; the fact that five years ago there  
> were proposals numbered in the thousands is irrelevant. */
>
> === Voting ===
>
> The Voting Period for a given nweek, or just "Voting", is defined as  
> the period of time from the beginning of nday 9 of that nweek until  
> the end of that nweek.
>
> At the beginning of each Voting Period, all Pending proposals become  
> Open.
>
> Any Player may submit a Vote on an Open proposal at any time. The  
> Vote must be one of the words FOR, AGAINST, or ABSTAIN; other words  
> are ignored.
>
> The most recent Vote on a proposal by a Player is called that  
> player's Final Vote on that proposal.
>
> === Tallying the votes ===
>
> A proposal's Strength is equal to the number of players whose Final  
> Vote on that proposal is FOR minus the number of players whose Final  
> Vote on that proposal is AGAINST.
>
> When Voting ends, the following events happen, in order:
>    * Each Open proposal with positive Strength becomes Won; all other  
> Open proposals become Lost.
>    * Dependency Culling occurs (see below).
>    * Conflict Culling occurs (see below).
>    * Dependency Culling occurs again.
>    * All Open proposals that are Won Pass, in order by Proposal Number.
>    * All Open proposals become Historical
>
> When a proposal Passes, its list of changes to the gamestate occur.
>
> Proposals that do not Pass are said to have Failed.
>
> === Dependency Culling ===
> When Dependency Culling occurs, every Open proposal is processed in  
> ascending order by Proposal Number. When a proposal is processed in  
> this manner, if it Depends on a proposal that is Lost, then it  
> becomes Lost itself. This process is repeated as long as there is any  
> Open proposal that Depends on a Lost proposal and is not Lost itself.
>
> === Conflict Culling ===
> When Conflict Culling occurs, every Open proposal is processed in  
> descending order of Strength, and of Proposal Number when Strength is  
> equal. When a proposal is processed in this manner, if it is Won,  
> then every proposal that Conflicts with it becomes Lost.
>
> }}
>
> Give Peter 5 points.
>
> }}

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