Re: [s-d] [s-b] Codae's Refresh Proposal

["Geoffrey Spear" <geoffspear@xxxxxxxxx>]

Honestly I'm not sure that revamping the Oracularities process is
really so urgent that it needs to be dealt with in a Refresh Proposal.

As for a speedy process for uncontroversial changes to the gamestate
or rules, I'd be in favor of a rule allowing players to make such
changes without objection and possible with N support for some
reasonable value of N (just to make sure someone else actually sees
the "uncontroversial" proposal and has a chance to object, so no one
can shove things through when everyone else happens to not read the
mailing list for 2 ndays).

I'd propose such a rule now (I think this would also be beyond the
scope of what I'd like to see a RP do), but I suspect we'll adopt a RP
that would eliminate my open proposal so I'll wait on that.

On Nov 28, 2007 11:59 AM, Jamie Dallaire <bad.leprechaun@xxxxxxxxx> wrote:
> On Nov 27, 2007 5:38 PM, Justin Ahmann <quesmarktion@xxxxxxxxxxxxx> wrote:
>
> >
> > Append to the section of Rule 2-2 entitled "Voting":
> >
> > {
> > As a Game Action with 2 Support, the Oracle or the Chairman may declare a
> > Voting Period for Oracularities only.  This impromptu Voting Period begins
> > once the second Player to pledge his Support for this Game Action does so,
> > and ends three ndays later.  In all other ways this Voting Period behaves
> > like an nweekly Voting Period.
> > }
> > [[I'm not entirely sure yet how to fit this in with Conflicts,
> > Dependencies, and Vote Power.  Any suggestions?]]
>
>
> For one, I'd suggest giving the impromptu voting period an official name by
> which it's always referred to distinguish it from the regular voting period.
> Perhaps smth as simple as "Impromptu Voting Period"?
>
> Secondly, as for conflicts and dependencies and such, I'm thinking that
> proposals voted on on an impromptu basis could be ascribed conflicts or
> dependencies by other proposals proposed during the same nweek, as long as
> the impromptu-voted proposal is not yet historical. Then conflict and
> dependency culling could happen at the end of the nweek including those snap
> voted ones. BUT then that either brings up a quantum gamestate problem where
> a proposal is passed or not depending on future culling, or we say we wait
> till the end of the nweek which sort of defeats the purpose of the impromptu
> vote. That, or we just say that snap voted proposals can't list dependencies
> or conflicts and also can't have conflicts listed on them (dependencies are
> ok but just redundant as a proposal can be withdrawn) except by other
> proposals voted on in the same impromptu voting period. Perhaps if called
> within the same nday or something two proposals belong to the same impromptu
> voting period? So... I don't really have a good answer, just throwing out
> some ideas.
>
> Billy Pilgrim
> _______________________________________________
> spoon-discuss mailing list
> spoon-discuss@xxxxxxxxx
> http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss
>



-- 
Geoffrey Spear
http://www.geoffreyspear.com/
_______________________________________________
spoon-discuss mailing list
spoon-discuss@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss