Imperative Rework

An archived copy of Josh's November 2015 Second Stab proposal to sharpen up the game's definition of imperative "must" and "should" type actions, presented here split into sections for discussion and tinkering.

({{quote|your text here}} templates default to grey; you can add other colours as a second variable - {{quote|your text here|ffc}} - if you want to distinguish your quotes from Josh's originals.)

Removal

De-italicise all text in this proposal.

Remove the items “Can”, “May”, “May not”, “Shall” and “Should” from the Glossary.

Remove the items “Daily Action”, “Daily Communal Action”, “Weekly Action” and “Weekly Communal Action” from the Glossary.

Definition

Add a new rule to the glossary, entitled Imperatives and Frequencies:

An Action is any activity that the ruleset specifically permits Readers to carry out, and regulates the usage of.

The ruleset regulates the usage of Actions through Imperatives and Frequencies. A Frequency defines how frequently an Action may be undertaken by each Reader. An Imperative defines the circumstances within which Readers can undertake an Action. The keywords used below to describe Imperatives and Frequencies are only keywords in that context when they apply to Actions, as defined in this rule. In all other situations, they take their regular English meaning.

Imperatives

Add a sub-rule to that rule, entitled Imperatives:

Imperatives in use within BlogNomic are as follows:

• Can or May: A Reader is permitted to carry out this Action at any time, with no restrictions beyond those otherwise explicitly defined by the Ruleset.
• Should: A Reader is required to carry out this Action at their first opportunity. The “should” imperative confers flexibility upon the gamestate but not the Reader; a Reader is required to treat the “should” imperative upon an Action that applies to themselves as if it were a “must”, but their failure to do so does not put the gamestate into an illegal state. The failure of a Reader to carry out an Action with a “should” imperative may be the subject of a CfJ, if it cannot otherwise be trivially resolved, but such a CfJ may not present a retroactive remedy.
• Must or Shall: A Reader is required to carry out this Action before they undertake any further Actions (unless the further Action in question is raising a CfJ, per the clause elsewhere in this rule). It is suggested that this Imperative is primarily used for subordinate Actions or steps undertaken in the carrying out of other Actions. If a Reader is subject to two or more “must” imperatives at the same time then they may undertake them in any order that they chose.

The gamestate is in an illegal state if it reflects the results of an Action that was carried out illegally. “Resolving the Illegality” means correcting the illegally carried-out Action and any subsequent Actions that relied upon that Action for their legality or legitimacy. If the gamestate is in an illegal state due to a clear and unambiguous error, and there are no subsequent Actions that would be rendered illegal by correcting that error, and if doing so does not pre-empt a requirement upon the Reader who caused the error to make some form of decision, then any Reader may amend the gamestate to Resolve the Illegality. Otherwise, any Reader should seek to Resolve the Illegality by means of a CfJ If the gamestate has been in an illegal state for seven days due to an Reader’s failure to carry out an action with a “Must” imperative, and no CfJ has been raised that attempts to Resolve the Illegality; or if the gamestate has been in an illegal state for fourteen days, and no CfJ has passed that attempts to Resolve the Illegality; or if a CfJ or Reader Action Resolves the Illegality, then the gamestate ceases to be in an illegal state and the failure to carry out that action is considered legal.

No part of this rule restricts Readers from posting a CfJ, under any circumstances.

In that event that any Imperative is immediately followed by the word “not”, it instead means that the described Action is strictly forbidden under the stated circumstances, or under all circumstances if not further qualified.

I commented in my vote that "should" and "must" seemed very similar under this wording - is "at their first opportunity" meaningfully different from "before they undertake any further Actions"? It seems like this proposal is breaking down "shoulds" into "if it applies to you, it's a must; otherwise it's a may".

Looking at existing rules I think "shoulds" generally would benefit from being flipped up or down to "must" or "may" depending on their context, but I'm not sure I'd trust a rule to make that call automatically. It seems safer to keep them all at "may", with the distinction that although the action is optional, other players would prefer that you did it. --Kevan (talk) 10:08, 13 November 2015 (UTC)

Tricky, here, as the distinction between Should and Must is one for the ruleset, not the player. The player should treat them as synonymous, but from a ruleset perspective it's to ensure that a player's failure to carry out a "should" action doesn't tip the gamestate into ongoing illegality. I'd expect that "must"s would be used sparingly, if ever. 14:08, 15 May 2020 (UTC)

I think the definitions here suffer from confusion about the distinction between the gamestate and the representation of the gamestate. In our rules at the moment, the gamestate, and the wiki tracking it, are different things; performing an action illegally changes the wiki but the gamestate does not change, so there's no way to "create an illegal gamestate". I'd prefer to keep that property in any rework. Ais523 (talk) 05:55, 19 May 2020 (UTC)

Countersuggestion by ais523:

Add a sub-rule to that rule, entitled Imperatives:

Imperatives in use within BlogNomic are as follows:

• can: If a Player "can" perform an action, attempts by that player to perform it will succeed, unless specifically forbidden or limited elsewhere in the ruleset;
• must: If a Player "must" perform an action, and that Player gains an advantage (even accidentally) from failing to perform it or delaying its performance, then all Players are encouraged to remove that advantage using a Call for Judgement; until that advantage is removed (or becomes irrelevant due to, e.g., a change of dynasty), that Player cannot achieve victory.

If a rule states that a player must perform an action (perhaps under certain circumstances), that by default implies that that player can perform the action (under the same circumstances), except when the context implies otherwise.

Add a bullet point to the Core rule "Fair Play":

• An Amnesiac should not intentionally fail to perform an action that the rules state that Amnesiac "must" perform, nor attempt to gain an advantage from intentionally delaying such an action.

The nice thing about this is that it never leads to any doubt about the gamestate (any gamestate uncertainty gets neatly tied up into a DoV or CFJ and resolved by voting), and never leads to an illegal gamestate; rather, we just fix the mess via CfJ (or ignore it if nothing bad happened as a consequence) and move on. I don't see a need for more than two categories, and it avoids the confusion involved in "may" and "should". Ais523 (talk)

Frequencies

Add another new subrule to the rule “Imperatives and Frequencies”, entitled Frequencies:

Standardised frequencies in use in BlogNomic are as follows:

• Daily: A Reader may carry out this Action once per Day, but not more than once in any eight-hour period.
• Bi-daily: A Reader may carry out this Action once every two Days, but not more than once in any twelve-hour period.
• Weekly: A Reader may carry out this Action once every Week, but not more than once in any twenty-four-hour period.

Action frequencies may be modified as follows:

• Communal: Any Action that is marked as Communal may only be carried out by a single Reader in the stated Frequency period.
• X-Usage: Any Action that is marked as X-Usage, where X is any integer, may be carried out X times in its Frequency period.

Why are you making dailies faster? There was much arguing about the correct limitation on repeating the action in the past, and the current value of 10 hours is something of a compromise. (If you make it much faster than that, you're giving a major disadvantage to scamsters who are normally asleep at midnight UTC.) For what it's worth, my preferred value for keeping scams fair is 18, but it was reduced because that can interfere somewhat with non-scam gameplay. Ais523 (talk) 05:58, 19 May 2020 (UTC)

Cleanup

In “Ruleset and Gamestate”, change “The Ruleset and Gamestate can only be altered in manners specified by the Ruleset” to “The Ruleset and Gamestate must only be altered in manners specified by the Ruleset”.

In “Resolution of Proposals”, 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 “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 should be failed by any Admin”.

In “Seasonal Downtime”, change “During this time no game actions may be taken” to “During this time game actions may not be taken”.

In “Drawing”, remove “choose to” and “at any time” in items 5, 6 and 7 in the numbered list.

In “Discards”, change “then any Reader may remove all the Cards from each Reader’s Discard pile” to ” then any Reader should remove all the Cards from each Reader’s Discard pile”.

In “Fair Play”, change all instances of “should” in the 2nd, 3rd, 4th and 6th bullets to “must”.