I’m not sure that this is necessary.

From Enacting and Failing:
“Whenever an Admin Resolves a Votable Matter, they should mark their name, and are highly encouraged to report the final tally of Votes (or the fact that it was self-killed or vetoed). Comments cannot be made on Enacted or Failed Votable Matters.”

From Proposals:
“The oldest Pending Proposal may be Enacted by any Admin (by updating the Ruleset and/or Gamestate to include the specified effects of that Proposal, and then setting that Proposal’s status to Enacted)”
So it would be problem if it was a proposal that was enacted.

But the language isn’t replicated for failures:
“The oldest Pending Proposal may be Failed by any Admin, if any of the following are true:”

So I can’t see where it says that failed proposals have to be marked failed at all.

I think that the mark can just be corrected on the basis on inaccurate portrayal of gamestate.

Soft on the basis of no problem that requires remedy.

because I don’t trust AIS not to have a scam hidden here, and because the CfJ is unnecessary. The proposal was failed. There is nothing in the rules that requires it to be properly marked with the failed tag as part of the failing process.

not to mention, if we establish that AIS is right here (which passing this would) it would make my most recent proposal illegal due to the three pending proposals rule.

Good point Clucky - it would also make any pending proposal by me illegal on the basis of three pending.

CoV per the above. I’m going to go ahead and mark the proposal as failed now on the basis of Josh’s point.

lol I already marked it as failed Bredan too slow

Could someone clarify what specific action by an admin causes them to be taking the “fail a proposal” action, if it isn’t setting the status field to Failed? I can’t think of anything else we could look at to say “the admin is failing this proposal”; the marking of the name and the vote tally are, legally, things that you do after the proposal has already been failed.

> the marking of the name and the vote tally are, legally, things that you do after the proposal has already been failed.

yup. which means that marking the proposal as failed isn’t actually what fails the proposal, as that gets done at the same time as the other things.

instead the admin just waves their hand and fails the proposal. and then goes and marks it as failed.

That bit of the ruleset is very a legacy of the blogspot era

During the First Dynasty of Diabecko, there was a rule enacted with an intentional loophole that caused proposal, CFJ and DoV statuses to become variables tracked on a wiki page.

The Gamestate Tracking rule at the time was very similar to now (actions that update information tracked on a wiki page are performed by editing that wiki page).

As soon as that rule was enacted, there was then a defined process for enacting/failing proposals, CFJs and DoVs: you would need to edit that page to say that the proposal was enacted or failed. We haven’t been doing that, so no proposals, CFJs or DoVs have passed since then, and we’re still in the First Dynasty of Diabecko. (A side effect of that is that the auto-uphold that happens upon a DoV won’t have fixed things for us.)

We can probably fix this with a CFJ to uphold everything (or more reliably, just set the ruleset and gamestate to match what we think it is). We should probably add a defined process for proposal/CFJ/DoV enactment at the same time; it could be as simple as saying “the Failed/Enacted/Pending status of a Votable Matter is tracked using its status field on the blog, with ‘Illegal’ being another representation of ‘Failed’”.

who cares how the rules worked back in another dynasty? that isn’t how they work now.

If proposal status really were an untracked variable, like most of the people here are arguing, it would be how they work now.

Cuddlebeam, on Slack, has mentioned that we have a core rule “Votable Matters and other official posts, as well as specific gamestate information, shall be tracked by the BlogNomic blog at http://blognomic.com.”. That seems to imply that the blog is used to track the pending/enacted/failed status of proposals, thus it isn’t actually an untracked variable after all. That means that if this CFJ is voted down, the queue will be blocked until it is unblocked by some other means (e.g. by reverting the failure of, and then failing, every proposal in order since the one that broke).

well the comments on the proposal properly marked it as failed. there was just an error in the representation of the gamestate which got correctly.