Oops, sorry Josh. I was working on a similar CfJ and posted it before I saw yours.

I’m happy to let mine go, although I think it has the benefit of explicitly listing out the proper number ranges.

Ah, and I just realized yours is not a CfJ. Oops again. I’m still ok letting mine go in favor of yours. I’m not wedded to either as long as functionally we get to the same place.

This has the thing again of how we would calculate “a chance of being selected that is equivalent to amount of Equity they hold as a proportion of N” where that Equity was negative.

@Kevan I think that may be covered by Numbers and Variables, as the chance in question is a distinct variable from Equity itself.

Oh, Numbers and Variables covering it would be good. So the chance defaults to zero and “can hold only non-negative integers” and if we calculate -3 Equity as being a -2.73% chance of being selected (if that’s what the maths would say), it can’t take that value so stays at zero?

Ironclad boilerplate is a good idea (my go-to solution is to “select a random Equity point among those held by players”), but it is often an enjoyable part of the game to thrash these things out from scratch each time, and to hunt for usable loopholes. Maybe a bit of a swizz that it’s often only enacting admins who can use loopholes, though.

I’m satisfied with this being covered by Numbers and Variables.

because this allows for players to Heightened Mill each other while it’s pending (which did in fact happen).

Oh right, I think this doesn’t work at all – “make a post to the blog” is not gamestate and so a proposal can’t require it to happen.

(And along similar lines, “if the Admin Enacting it reaches a step which cannot be applied immediately” then that step is skipped, and I don’t think the comment can be made immediately because it relies on the dice roll. That said, the proposal seems to function correctly even without mandating the comment, so that doesn’t break things.)

Thinking more about it, a proposal can actually require an admin to make a post, even though that isn’t a gamestate change, because there are two separate sets of instructions for adminning proposals and the first set of instructions make it happen even if the second set doesn’t. But it leads to weird timing issues because it becomes hard to define the point at which the proposal becomes enacted.

CoV this proposal is affected by the Reinitialisation scam I closed in “Late Re-arrivals at the Nomicer’s Ball” – Raven and/or Darknight could trivially give themselves a positive chance to win by Reinitialising before the proposal enacted.

How is the blog not gamestate? There are numerous rules regulating blog posts. And in the Official Posts rule it says:

Votable Matters and other official posts, as well as specific gamestate information, shall be tracked by the BlogNomic blog at http://blognomic.com

@JonathanDark: if the blog were gamestate, you wouldn’t be able to make posts and comments to it.

Official Posts are gamestate – those which follow the format defined by a rule – but this proposal doesn’t create an Official Post because the format is defined in a proposal, rather than a rule.

Funnily enough, the status of being an Official Post or not has very little actual impact upon the game. Non-official posts can serve a function if required, provided that their posting and context is permitted by a rule, which in this case it is (“When a Proposal is Enacted, its stated effects are applied by treating the text in the Proposal as a series of steps starting from the beginning of that Proposal’s text and performing each step until reaching the end of that Proposal’s text”).

@Josh: indeed, but there aren’t, e.g., rules against editing them.

Doesn’t matter; the process of enacting the proposal can’t be interrupted once started and editing the post after the enactment would have no impact on the outcome.

What stops an enactment from being interrupted?

on the reinitialisation grounds, for now, but would be willing to CoV in the morning.

I don’t believe anything prevents an admin from doing things in the middle of an enactment, under current rules – there are protections against interleaving actions but those only apply to atomic and dynastic actions, and proposal enactment is neither.

However, the way the rules are currently written, all the ruleset and gamestate changes made by a proposal happen simultaneously at the end of the proposal, even though the steps are done one at a time. That feels like a bug to me.

Interestingly, I also suspect that a proposal can have its non-gamestate/non-ruleset effects applied twice if two different admins start trying to enact it simultaneously, although I’m not very sure because the rule isn’t written very clearly.

If used in a context of a Votable Matter, the word “Resolve” means to perform the act, as an Admin, of enacting, failing, or marking illegal a Votable Matter. The world “Resolution” means then the act of doing so. If used in any other context, the meaning of both “Resolve” and “Resolution” is the standard English meaning of these words. The resolution of a votable matter is tracked by reference to its status in the blog post edit form. If otherwise legally applied, the application of any status through the blog post editing form is sufficient to consider that votable matter to have been correctly resolved, but a resolved votable matter should have the correct status wherever possible; if any admin believes that a resolved votable matter has an incorrect status then they may correct it.

So my understanding is that by marking a Proposal “enacted”, “failed”, etc, that it is considered to have been resolved immediately at that time. If marking a Proposal “enacted” is done first, then performing the actual steps in an enacted Proposal is simply adjusting the ruleset and gamestate tracking to match the state of the rules and gamestate per the enactment.

Isn’t that why steps that can’t be applied immediately have to be ignored?