Sunday, August 22, 2021

Proposal: Victory Executed Through Obstruction

Enacted popular, 9 votes to 0. Josh

Adminned at 22 Aug 2021 17:19:24 UTC

Create a new dynastic rule, “Victory”:

A Proposal which is Pending, Popular, at least 12 hours old, and for which all older Pending proposals are Self-Killed, Vetoed, Popular or Unpopular, is known as an “Enactable Proposal”.

Each Enacted Proposal not authored by the Wielder of Vetoes is known as a “Scoring Proposal”. If this rule has existed for at least 72 hours, and no Scoring Proposal was Enacted within the previous 72 hours, no Pending Proposal has been open for voting for 48 or more hours, and no proposals are Enactable, then the author of the most recently Enacted Scoring Proposal achieves victory.

Create a new dynastic rule, “The Veto List”:

A proposal is a Misfit if it does not have all of the properties on the following list:

  1. It would, if enacted, add a new entry to this list.

If, using the definition of “Misfit” at the time a proposal was posted (as opposed to the current definition), a proposal is a Misfit, then the Wielder of Vetoes is strongly encouraged to veto it. Legislators are encouraged to draw attention to Misfit proposals that have not been vetoed yet, and to avoid voting FOR on them.

The core mechanic: each proposal introduces a new restriction on what can go in a proposal, and (as long as there are no timed-out proposals waiting to be processed) the last player to pass a proposal wins.

For safety (so that the queue doesn’t end up getting semi-permanently blocked when we inevitably discover that we were wrong about whether or not a proposal is a Misfit), the restrictions on what make a valid proposal aren’t enforced automatically by the rules, but rather via the use of vetoes. As a consequence, it is quite possible that I’ll end up vetoing a huge number of proposals this dynasty.


Clucky: he/him

22-08-2021 02:34:02 UTC

I wonder if “list of stuff a proposal can’t do” or “list of stuff a proposal must do” would be easier to work with. I think the negative case might trip some people up.


22-08-2021 02:36:36 UTC

I’ve flipped it around to be a list of things a proposal must do – it seems like it’d be easier to use once you’re familiar with the mechanic.

Clucky: he/him

22-08-2021 02:38:10 UTC

I also think it might be a good idea to have the rules require that there not just be any pending proposals which have been open for voting for more than 48 hours, but make it so that the oldest pending proposal cannot be resolved. Otherwise, admins have a distinct advantage (as I could simply choose not to resolve a popular proposal hoping to burn out the clock before another admin gets around to doing it, whereas were I the one with the pending proposal I could resolve it and deny someone else the win)


22-08-2021 02:41:08 UTC

I’ve changed that, too.

I am a little uneasy that it allows for a potential admin scam the other way – choosing not to enact/fail a proposal in order to give another proposal time to time out, so that a non-admin couldn’t gain victory – but that seems less likely to be exploited, as it would require all the admins to cooperate to stop the victory.

Clucky: he/him

22-08-2021 02:57:43 UTC

” legally Enacted or Failed” has me a bit worried that a non-admin could try and argue they cannot legally enact or fail any proposal.

To clarify your worry to make sure I understand it:

Lets say Lemon’s proposal passed 72 hours ago

There is a pending proposal that is going to fail in the queue. And then another proposal that looks like its going to be popular, but is a vote short on quorum.

I, as an admin, don’t do anything with the pending proposal until after someone else votes on it. Whereas if it was my proposal that was on the button I could fail the other one and win?

Yeah that is also a problem. Maybe something like

“There exists no pending proposal which could legally be enacted by an admin (assuming they first failed all pending proposals which they could legally fail)”

could work?


22-08-2021 03:30:32 UTC

I think I’ve found a wording that works, now – instead of referencing the core rules, it just uses the same check that they do to see whether a proposal could be enacted by failing proposals first or not. (The check doesn’t work if there’s a timed-out proposal, but we have a separate check for that.)

Clucky: he/him

22-08-2021 06:13:45 UTC



22-08-2021 08:38:57 UTC


Josh: he/they

22-08-2021 09:24:01 UTC


Kevan: City he/him

22-08-2021 10:05:56 UTC


Janet: she/her

22-08-2021 13:28:28 UTC


Lulu: she/her

22-08-2021 13:39:19 UTC


Lulu: she/her

22-08-2021 13:55:21 UTC


Darknight: he/him

22-08-2021 14:36:51 UTC


Raven1207: he/they

22-08-2021 16:49:58 UTC