Saturday, August 07, 2021

Proposal: [Core] Good-faith proposal processing

Self killed

Adminned at 08 Aug 2021 13:11:43 UTC

In “Resolution of Proposals”, change the first two instances of “The oldest Pending” to “A Pending”.

Then change

If a Proposal somehow ends up being pending for more than 7 days, it is ignored for the purpose of calculating the oldest pending Proposal, and can be failed by any Admin.

to

Admins must make a good-faith attempt to process proposals in order; a proposal should not be Enacted or Failed unless it is the oldest pending Proposal. However, if an Admin inadvertently enacts or fails a proposal out of sequence, this does not invalidate that enactment or failure.

To “Fair Play”, add a new bullet point:

  • An Admin should not intentionally Enact or Fail a Proposal that is not the oldest pending Proposal.

We repeatedly have trouble with the queue becoming blocked because a proposal is inadvertently adminned out of order, in theory causing a domino effect in which future proposals are also adminned out of order and thus not being processed legally.

In practice, the best solution to this is to simply uphold the enactment/failure of proposals if the enacting/failing admin does so in good faith (and that’s pretty much what we’re doing anyway). This proposal codifies that solution in the Rules – admins are allowed to inadvertently process proposals in the wrong order, but are not allowed to do so intentionally.

Comments

Janet: she/her

07-08-2021 17:38:52 UTC

greentick

Darknight: he/him

07-08-2021 18:06:32 UTC

The only issue is if a proposal gets enacted but needs a proposal before it to pass first though yes?

Clucky: he/him

07-08-2021 18:13:09 UTC

against

If a proposal is enacted out of order, and changing the order stuff was enacted would change what that proposal does, we shouldn’t go “oh well guess it was legal” we should properly enact the proposal

Janet: she/her

07-08-2021 18:15:31 UTC

for

Admins still would be able to deliberately enact out of order in order to mess stuff up with this. I think an occasional “whoops those proposals were out of order, we need to fix this” is better than ever having “whoops, a proposal was never legally resolved, so nothing after that was actually enacted”, especially given that the first is more likely to be noticed than the second.

ais523:

07-08-2021 18:29:35 UTC

@Clucky: in most cases, changing the order in which the proposals were enacted/failed doesn’t change what they do; yet our current rules say that in that case, the entire proposal system freezes. (Even if two proposals are failed out of order, the entire proposal system freezes, according to what the rules currently say; and yet the order in which proposals are failed shouldn’t make a difference.)

I prefer the “OK, something went wrong, but it’s no big deal” approach; if BlogNomic’s player base as a whole agrees with me on this, it will be preferable to explicitly specify in the rules that we’re using that approach (as opposed to having it as an unwritten social agreement that might not be guessed by new players). I hope they do, and this proposal is effectively a poll on that.

Clucky: he/him

07-08-2021 18:31:08 UTC

You are wrong. There are many cases where proposal order matters.

If something goes wrong with the proposal queue, we do what we’ve always done: play on and pass a CfJ upholding things

Janet: she/her

07-08-2021 18:34:02 UTC

This makes a CfJ required only when a queue mishap actually messes up proposal effects, rather than whenever a queue mishap happens (silently invalidating everything until the CfJ passes).

Josh: Observer he/they

07-08-2021 18:38:25 UTC

against

Clucky: he/him

07-08-2021 18:38:38 UTC

sure.

but in one case, its a quick easy “play on exactly how people would expect things to work”

in the other case, you now actually have a potentially contentious CfJ with stuff to resolve other than simply playing on because under the letter of the rules, the proposal was completely legally enacted

also most of the time something is improperly resolved, it is quickly caught and can quickly be undone without the need for a CfJ—the only time it becomes a problem is if someone doesn’t realize that an error happened until much later (which at that point, generally, the error didn’t really effect anything so everyone can just play on).

This would mean that if someone fails to count votes correctly on proposal A because they forgot to realize that a person idled, then enacts proposal B… suddenly even if someone spots the error five minutes later its too late to revert stuff

 

ais523:

07-08-2021 19:02:25 UTC

@Clucky: I think “someone doesn’t realise that an error happened until much later” is much more common than you’re suggesting above; it happens multiple times most dynasties.

I also think “the error didn’t really affect anything so everyone can just play on” is inaccurate – even if you personally aren’t upset by there having been “officially” no gameplay for days/weeks/months, some players are, and prefer to see fix CFJs to uphold everything that happened rather than going along with people just unofficially deciding to uphold everything, and those CFJs can be contentious. A rule like this would reduce the frequency at which this sort of contentious CFJ is required to ensure that everyone agrees on the gamestate, whereas I expect “I accidentally enacted these two proposals out of order because I miscounted the votes, and it turned out to make a difference” CFJs to be both much rarer (especially if admins develop a habit of double-checking the votes on older proposals before adminning newer proposals that depend on them), and much less contentious.

I would not be opposed to agreeing a principle that “mistakes made weeks or months ago shouldn’t have ongoing effects, and we treat the resulting gamestate-tracker updates as though they were legal”. I do, however, think that such a principle needs to be codified into the rules to have any force, because the rules are the determining factor for what is legal in a nomic, and what is true about its gamestate. Right now (other than the “uphold everything at ascension” rule, which doesn’t deal with everything), the rules don’t care about how long ago a mistake was made; if they suggest reverting mistakes that happened ten minutes ago (and I think they do), they also suggest reverting mistakes that happened ten months ago. This is probably bad for the game, and could do with changing if we find a wording that we all agree with – but while the rules say what they do, we need to follow them.

Kevan: he/him

07-08-2021 19:05:31 UTC

Seems okay for historical cleanup, but bad for some live situations, where enacting a proposal out of order may well mess up the ruleset or gamestate that earlier ones were expecting to be there, or end up overwritten. If we realise a mistake immediately, I’d have thought the obvious solution was to undo it, rather than stand by it and hope nothing crashes into it.

From a ruleset clarity perspective, phrasing the everyday, expected behaviour as an exception makes the basic game structure more opaque, and will undoubtedly increase the rate of new players asking their self-kill to be processed straight away (if the rule now literally says “A Pending Proposal may be Failed by any Admin…”).

against

Raven1207: he/they

07-08-2021 19:07:54 UTC

against

Clucky: he/him

07-08-2021 19:23:35 UTC

the rules are *not* the determining factor in nomic. The players are. That is why we have CfJs. Rules can be interpreted differently by different players. The results of CfJs cannot.

At the end of the day, you’re still likely going to need a CfJ to interpret the rules. So adding formal rules about when you should revert vs when you should play on would just complicate the process by making it harder for the players to determine the right resolution for a given situation.

ais523:

07-08-2021 19:51:44 UTC

@Clucky: I disagree with your first paragraph above. From my point of view, the reason we have CFJs is precisely so that, if the players disagree about something, or would prefer a different outcome from the outcome suggested by the rules, they can cause the rules to change their view of things to match the majority view (and thus cause the minority players to agree with the majority about what the gamestate is). If BlogNomic were entirely based on the consensus of the player-base, CFJs wouldn’t be necessary; we could just informally agree to keep on playing from a different gamestate, rather than needing to codify it.

I also disagree that the results of CFJs can’t be interpreted differently by different players – if a CFJ is enacted, everyone normally agrees that the changes suggested in it were made (as long as it’s unambiguous what those changes would do in each possible gamestate), but if a CFJ is failed, that leaves a lot open to intepretation. (Are people saying that there wasn’t a problem, and the CFJ would cause one? That there wasn’t a problem, and the CFJ does nothing and is therefore unnecessary? That there was a problem, but they don’t like the fix suggested in the CFJ?)

It also seems to be quite common to have situations where players agree that there’s an issue, but disagree as to what the correct / fairest resolution would be. An example of that from last dynasty: when we realised that bounces had been processed incorrectly, I submitted a CFJ to revert the recent examples of incorrectly processed bounces, upholding the older ones that were too early to easily revert, but it failed in favour of a CFJ to uphold all of them. This is despite the fact that “uphold” was a tactically better resolution than “revert” from my point of view; I submitted the “revert” CFJ because I felt that because it wasn’t too late to revert the bounces, they should be.

Having some sort of guidance in the Ruleset (or linked from it) as to when to revert and when to uphold is likely to reduce a lot of tension, even if we still need to manually CFJ, because at least everyone will then agree on what the appropriate goal for the fix CFJ is.

lemon: she/her

08-08-2021 00:25:37 UTC

against

Lulu: she/her

08-08-2021 00:46:54 UTC

against

ais523:

08-08-2021 05:53:41 UTC

against s/k:

a) people seem to think that this proposal is making the wrong tradeoff between quickly-noticed mistakes and slowly-noticed mistakes, and I sympathise with that position;

b) it’s possible that this proposal was illegal at some point (due to Hiatus never ending), at which point it can never again have any effect on the ruleset even if a CFJ tries to make it legal, and I want to avoid any potential uncertainty in the core ruleset that might end up existing as a consequence of this proposal passing.