On 3 June 2011 07:44, Sean Hunt <scsh...@csclub.uwaterloo.ca> wrote:
> I CFJ {When enacted, a proposal performs the changes stipulated in its
> text}.
>
> Rule 106 says
> A proposal is a fixed body of text which has been made into a
> proposal using a process specifically described in the Rules.
> When a person creates a proposal, e SHOULD ensure that it
> specifies one or more changes to the gamestate. Except as
> prohibited by other rules, a proposal that takes effect CAN, as
> part of its effect, apply the changes that it specifies. If the
> proposal cannot make some such changes, this does not preclude
> the other changes from taking place.
>
> Nothing here actually directs the proposal to make such changes. Compare to
> a prior version of the rule
>
> A proposal is a fixed body of text which has been made into a
> proposal using a process specifically described in the Rules.
> When creating proposals, the person who creates them SHOULD
> ensure that the proposal outlines changes to be made to Agora,
> such as enacting, repealing, or amending rules, or making other
> explicit changes to the gamestate. When a proposal that includes
> such explicit changes takes effect, it applies those changes to
> the gamestate. If the proposal cannot make some such changes,
> this does not preclude the other changes from taking place.
>
> Note that the answer to this CFJ may well be TRUE by way of AIAN. By
> preventing proposals from making rule changes, we would be left without a
> way to ratify rule changes, I believe, and thus AIAN may have kicked in and
> canceled Proposal 6823's rule change here.
Gratuitous:
We still have this in R106 (power 3):
If the option selected by Agora on this decision is ADOPTED,
then the proposal is adopted, and unless other rules prevent it
from taking effect, its power is set to the minimum of four and
its adoption index, and then it takes effect.
--
Charles Walker
