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?

@JonathanDark: A while ago, I proposed to make it unambiguously work like that, but it got voted down. As it is, it’s ambiguous – there are two explanations of how to enact a proposal in the core rules and one in the appendix, and they all differ slightly in the details.

I think the appendix rule you quoted was intended for the purpose of “as soon as an admin edits the status in the blog backend, a proposal counts as enacted for the purpose of rules which care about whether or not it was enacted, even if not all the steps were applied.” But I agree with you that that isn’t what the rule actually says, and it can be difficult to work out the implications of the actual wording.

i unidle for the free winshare

And this is why you guys should have taken me up on my CfJ.

I did!

Hmm… on JonathanDark’s reasoning, I think this proposal doesn’t actually do anything if enacted.

Above, I mentioned that there were three different sets of rules for resolving a proposal – two in the core rules and one in the appendix – but wasn’t sure how to resolve it. But there is of course a way to resolve it: the appendix takes precedence over the core rules. As such, anything that wouldn’t be possible with the appendix version of proposal resolution isn’t possible for proposal resolution in general.

With the appendix version, a proposal is considered to have been resolved as soon as the “enacted” mark is placed on the proposal post, and that updates the ruleset and gamestate accordingly. (The remaining steps of adminning the proposal are then to update the ruleset and gamestate trackers to match the new state of the ruleset and gamestate.) This means that any step that can’t be applied immediately as a result of placing the “enacted” mark can’t happen at all. The core rules are consistent with this view – they allow for skipping steps that can’t be immediately applied, and they restrict proposals to making ruleset and gamestate changes. (The “do the steps one at a time” is weird in this view, but it gets overridden by the Appendix, and can be treated as consistent with the other rules via using it as a method of calculating the resulting combined ruleset and gamestate change when a proposal contains multiple changes.)

All this precludes doing anything based on the result of a dice roll directly in the proposal (without creating a rule to make it possible) – that means that a) this proposal doesn’t work and b) Josh’s win of the previous dynasty was illegitimate and didn’t occur (although the DoV was voted through anyway, making him emperor).

I think you might be taking “immediately” too literally. By that measure, updating gamestate and changing the ruleset can’t be done either because neither is “immediate”. I know it personally takes me a few minutes to copy-paste things correctly or format the wiki gamestate page correctly, and I certainly can’t do both concurrently (not enough hands and eyes).

In this sense, the only reasonable interpretation of “immediately” is “without any requirement of delay”. The examples given in the rules are good ones, and I don’t see why it wouldn’t work here as well. There are steps to follow, and each step is only delayed by the performance of the previous one, not on any time delay or anything else that would be out of the enacting admin’s control to perform.

Well, we can certainly rule that the gamestate and ruleset updates happen immediately, and only the corresponding tracker update is delayed. I think that’s also a reasonable interpretation of “immediately” – and it’s the only one consistent with considering the voting matter to have been resolved as soon as the post status is changed to “Enacted”.

This isn’t a theoretical issue, either. Kevan once won a dynasty by enacting a proposal that made a change to a variable for each player via changing the values one at a time (leading to a victory state existing at a point in the middle of adminning the proposal, which he subsequently used to declare victory). If you declare that enacting a proposal does all the changes instantaneously, that scam doesn’t work.

Well, you might as well make the CfJ now, or at least start writing it up. I’m pretty sure Clucky’s going to enact this Proposal as soon as we hit the 12-hour mark on it.

All aboard the unidling train! 🚂

I unidle, quorum rises to 6.

I was planning to vote against the resulting DoV (although because DoV votes don’t have to be done on an “I believe this win is valid” basis I might vote for it if I like the person the dice came up with).

Note that I would encourage players to vote against the DoV regardless of whether or not they think the win is valid if one of the previously idle players ends up winning, because this is a silly way for the dynasty to end.

It’s the most nomic way to end a dynasty too

Well, I won already, and have been having so many dynasties recently that I was considering trying to manufacture some way to pass the mantle.

I think this ending is hilarious – Josh replaces a buggy victory rule using an victory proposal that is also very buggy (rather than respecting the outcome produced by the buggy rule, which happened to be the same as the “correct” non-scam outcome of the dynasty, and voting through the DoV), and ends up making his own dynasty pointless as a result. Even though any win from this proposal won’t actually be valid, that’s unlikely to matter; with this many previously idle players unidling (and presumably voting through the win regardless of who is selected) the DoV is almost certainly going to pass regardless of whether the win is actually valid or not.

@ais523 I have read your comments on this proposal and I don’t see any valid arguments for you claims that “this proposal doesn’t work”, “Josh’s win of the previous dynasty was illegitimate” and “any win from this proposal won’t actually be valid”. Also the suggestion that proposals and blog comments aren’t gamestate is preposterous.

Also the state of having achieved victory is by definition a matter of opinion, so I’m not sure there’s much point to debating whether someone’s “win” is “valid” or not.

@Zack: I searched the entire ruleset, but couldn’t find a rule allowing you to make the comment you just made.

As such, if the comment is gamestate (as you apparently believe), it was illegal to make it, as gamestate changes are only allowed when permitted by the ruleset.

Proposals are gamestate. Blog posts that aren’t Official Posts, and blog comments, aren’t.

I noticed that this proposal has been closed as illegal due to having been illegally edited, and then reopened.

Not being an admin, I can’t see what the apparent illegal edits were, in order to judge whether they happened or not. Could an admin specify what the change was?

The edit was a correction of Make->Madke-> Made. I assert the first edit was illegal as that is not “correcting” a typo.

SingularByte is trying to use core rules scams to illegally prevent this from passing

OK, relevant rules:
“An official post may only be altered by its author as allowed by the Ruleset.”
“Nomicers may correct obvious spelling, punctuation, typographical, and/or formatting mistakes in the Ruleset, the Building Blocks page, and their own Pending Votable Matters at any time, including replacing Spivak and gender-specific pronouns that refer to Nomicers with the corresponding forms of the singular ‘they’.”

I also think those unambiguously make the edit illegal – “made” to “madke” is not a typo correction, because “madke” is not the correct word.

@Clucky: there is not a rule against using core rule scams to prevent a victory. The only relevant rule is “A Nomicer should not use a Core, Building Blocks, or Appendix rules scam to directly or indirectly cause a Nomicer to achieve victory.” Even if someone breaks that rule, the scam is still considered to have happened – the remedy that the ruleset prescribes is to vote down any resulting DoV, possibly on top of a CFJ to ban or reprimand the perpetrator.

So even if you consider this to be a core rules scam intended to indirectly achieve victory (which is highly debatable), that doesn’t mean that the proposal itself hasn’t been made illegal (and is no longer capable of having any effect on the ruleset or gamestate).

(Something that’s also worth noting: even if nobody had noticed the illegal edit, the proposal still would be in an illegally-edited state, and incapable of making any ruleset or gamestate changes. So this isn’t so much a core rules scam, as pointing out a core rules issue; the issue would prevent the victory being awarded even if nobody had explicitly tried to scam it.)

@ais523 Per Keywords, gamestate is defined as “ Any information which the Ruleset regulates the alteration of.” The rule Fair Play regulates the alteration of comments. Therefore comments are gamestate. There not need to be any rule that says “You are allowed to make a comment” for me to be allowed to make comments. There are many rules which suggest content that I may include in a comment, if I so choose, which would all be moot if I was not allowed to make a comment.

preventing victory indirectly allows others to achieve victory, and thus is clearly against the fair play rules

also illegal edits do not make a post illegal

@Zack: after reading your argument I think that we’re both right, and this is some sort of contradiction in the rules. The fact that a comment has been made cannot be gamestate – making a comment alters that, and yet players can alter it without explicit ruleset permission. The comment itself is gamestate under that definition, as the Fair Play rule bans changing them. But the history of gamestate changes is itself gamestate. Those positions can’t all be reconciled with each other, and yet they all logically follow from the rules.

I’m enacting this as-is. Please do not un-enact or otherwise change the status. Take up a CfJ instead.

Thank you for your cooperation.