BlogNomic: The First Dynasty of Desertfrog

I can imagine cases where this would be a big deal, but can’t actually remember many. If there’s an exploitable timing gap between two proposals, the second proposal should really have anticipated it (as it could also be exploited by players choosing to delay their voting).

Not for the second sentence, but for the first. Admins are already not able to selectively admin proposals (they can only ever admin the oldest outstanding one). I can see that clause being willfully misinterpreted, though; is not any action that is not obliged selective?

(Afraid I coincidentally idled Josh out a minute and a half before he posted that, so it’s not a legal vote unless he formally unidles.)

This entire rule does nothing (in the absence of a fast veto). If there are two pending proposals in the queue, even if they’ve both made quorum, the newer one can’t be resolved until after the older one is, so there’s only one proposal that could be resolved at the time that the older one is.

I don’t really see the rule being necessary, anyway. Pretty much the only way this is exploitable is via performing an action that the first proposal to resolve allows, and the second proposal to resolve forbids. You’d be able to exploit that anyway under all combinations of timings, except when the newer proposal hit quorum before the older proposal hit quorum or timed out.

Finally, this rule (if fixed) has the platonism problem. What happens if an admin doesn’t (either intentionally, or accidentally)? Do we just assume that the newer proposal adminned itself? Normally when there’s a “must” in a Nomic rule, it’s interpreted to mean “this happens even if nobody explicitly does it”, unless some punishment is specified for not doing it.

Per Josh, but I don’t think this would give much benefit anyway.

Knowing that proposals resolve in blocks would be handy, but still scammable in practice - admins will sometimes be able to change votes to slow the queue down, and since they can only process proposals at human speeds, there’s still time for accomplices to intervene between two enactments (and an admin could even be deliberately slow about enacting the second).

I guess the thing I was trying to prevent was an Admin quickly enacting a proposal they wanted to enact, and then waiting to enact another proposal, in hopes of it gaining more Against votes.

That’s not exploitable. If nobody wants the latter proposal to pass, then it’s not going to get enough FOR votes to pass. If somebody wants the latter proposal to pass, they can either admin it themselves, or hire a friendly admin to do it for them. (It’s not like admins are in short supply, and there’s been something of an unofficial policy that if the ability to do something is admin-only, non-admins can ask admins to do it on request, so as to keep access to scams symmetrical.)

My computer has gone out in between admin-ings before. Once during, though luckily enough I got home and finished it before anyone did anything.

In my case, I just failed a proposal, then discovered I had forgotten my wiki password, and the wiki-password retrive-o-tron wasn’t working, so I couldn’t enact the next proposal. How will this respond to that?

self kill