Re: DIS: Re: BUS: Re: OFF: [Assessor] Resolution of Proposal 8177
On Tue, May 28, 2019 at 1:26 PM omd wrote: > On Tue, May 28, 2019 at 7:05 AM D Margaux wrote: > > Additionally, I do not think the conditional vote “required the report > > ratification to go through before the voting period ended”; did it? If the > > empty reports self-ratify tomorrow, wouldn’t your vote still resolve to > > FOR? That is because, upon self-ratification, the Clork and Astronomor > > switches would revert to their default values at the time of the report > > publication, which would be before the end of the voting period. > > > > So I could have waited until report self-ratification and assessed the > > votes the same way on Wednesday (but didn’t have to because of my > > ratification without objection). > > That's another case that depends on whether ratification creates a > legal fiction about the past. If it does, that would work. If it > doesn't... well, it depends on whether you read R2127's "a conditional > vote is evaluated at the end of the voting period" as (a) "a > conditional vote is evaluated at the time of resolution based on > circumstances at the end of the voting period", or (b) literally "a > conditional vote is automatically evaluated at the end of the voting > period, and that value is then stuck into the gamestate, waiting to be > used when it's resolved". In the latter case, it also works, because > ratification would change that value stuck in the gamestate. In the > former case, ratifying after the end of the voting period but before > assessment wouldn't work; ratifying *after* assessment would work if > not for the prohibition on ratification implicitly modifying the > ruleset. One of the things that biases me towards omd's counterarguments (a bit, both are reasonable IMO) is that conditional votes work by defining when a voting value was clearly specified, which links to the requirement in R683.4. In general, when we require clear specification, we don't allow a person who communicates ambiguously to go back and clarify with retroactive effect. For example, we don't allow someone to say "now that ratification has clarified the game state 3 days ago, I hereby clarify that my announcement of 2 days ago meant X instead of Y".
DIS: Re: BUS: Re: OFF: [Promotor] Distribution of Proposals 8178-8179
On Tue, May 28, 2019 at 7:12 AM David Seeber wrote: > I vote as follows: > > 8178 - FOR > 8179 - FOR > > I declare null and void any other votes cast on my behalf. I'm afraid you have to do this in the opposite order. The "null and void" bit presumably successfully retracted the ballots cast on your behalf, but your attempt to cast new votes didn't work because the existing ones hadn't been retracted yet (see Rule 683).
Re: DIS: Re: BUS: Re: OFF: [Assessor] Resolution of Proposal 8177
On Tue, May 28, 2019 at 7:05 AM D Margaux wrote: > Additionally, I do not think the conditional vote “required the report > ratification to go through before the voting period ended”; did it? If the > empty reports self-ratify tomorrow, wouldn’t your vote still resolve to FOR? > That is because, upon self-ratification, the Clork and Astronomor switches > would revert to their default values at the time of the report publication, > which would be before the end of the voting period. > > So I could have waited until report self-ratification and assessed the votes > the same way on Wednesday (but didn’t have to because of my ratification > without objection). That's another case that depends on whether ratification creates a legal fiction about the past. If it does, that would work. If it doesn't... well, it depends on whether you read R2127's "a conditional vote is evaluated at the end of the voting period" as (a) "a conditional vote is evaluated at the time of resolution based on circumstances at the end of the voting period", or (b) literally "a conditional vote is automatically evaluated at the end of the voting period, and that value is then stuck into the gamestate, waiting to be used when it's resolved". In the latter case, it also works, because ratification would change that value stuck in the gamestate. In the former case, ratifying after the end of the voting period but before assessment wouldn't work; ratifying *after* assessment would work if not for the prohibition on ratification implicitly modifying the ruleset.
Re: DIS: Re: BUS: [Referee] Recusal (attn H. Arbitor)
On Mon, May 27, 2019 at 10:56 PM Kerim Aydin wrote: > On the subject of community size - welcome back, o and omd!!! Thanks :)
Re: DIS: Re: BUS: [Referee] Recusal (attn H. Arbitor)
On Tue, May 28, 2019 at 11:21 AM D. Margaux wrote: > > On May 26, 2019, at 9:01 PM, omd wrote: > > > >> On Sun, May 26, 2019 at 5:49 PM D. Margaux wrote: > >> and, therefore, any attempt to impose a fine was retroactively INEFFECTIVE. > > > > ...wow, that's strange. Why the heck is rule 2531 designed to make > > the gamestate (whether fines are EFFECTIVE, and thus indirectly > > people's voting power) depend on so many "soft" factors? Including > > the legality of actions, whether someone "more likely than not" > > performed an action (according to whom?), and even whether or not a > > fine is "blatantly and obviously unsuited". > > I think it’s important for there to be some strict conditions for the > POSSIBILITY of the referee blotting someone, precisely because it > affects voting power. We wouldn’t want it to be POSSIBLE for the Referee > to ILLEGALLY issue 40 blots to each player and exile em or negate their > voting power, and create a dictatorship that way. > It might be a good idea to amend the rule so that failing some > requirements make the fine IMPOSSIBLE, and failing other requirements > enable a player to remove the blots by some process (like through a > CFJ). I’m not sure which requirements should be in which category though. This has been a long-term structural question. We've always needed a "quick punishment" system for trivially-true crimes (e.g. late reports) and a more deliberative system to grind out justice. We have called these things like Infractions vs Crimes, or "plea bargain" vs "criminal trial". If something seems like a quick punishment but the defendant wants longer justice, the question of "what punishment status should be applied in the interim" is a tricky one. The "blot people out of the game" has in fact happened before. On the other hand, blots prevent winning. So if the defendant can delay a punishment by calling for a long trial, e might win in the mean time (I'm thinking of cases where the win conditions were independent of the alleged crime). So there's a balance to be struck. We once had a long and complicated process of Judicial Orders (punishment was applied via an order) but orders could be stayed, vacated by another judge, etc. Dueling order battles were fun! Sorta. But very very confusing, especially when we started ordering each other not to issue further orders. I think, in balance, I agree with D. Margaux that the "make it IMPOSSIBLE and adjust game understanding retroactively if a CFJ comes up" is a good way to go. It tips the balance away from being either too much favoring the defendant versus the prosecution and the expense of some overall game uncertainty - so far so minor. A second option might be a short delay - The Referee applies a punishment without Objection from the defendant, but the only method the defendant can use to Object is to demand trial (i.e. call a CFJ). The Trial would be required to apply the default punishment while the referee could offer a lesser sentence for not objecting. The main issue with this is it requires some follow-up from the referee for each offense. A third thing - specifically on the voting side - is to say that voting results can only be CoEd the result (ADOPTED vs REJECTED) and not differences in the vote count that don't affect the outcome (this is useful in many contexts, actually!)
Re: DIS: [Proto-proposal] Hotfixes
On Tue, May 28, 2019 at 10:36 AM Aris Merchant wrote: > I think it would be better to have some sort of proposal expedition > mechanism again. It's more general and cleaner (no need to have > another free-text decision type). The basic principle is to have a > process whereby a person can mark a proposal as urgent, and then to > process it in some special accelerated fashion. I thought about suggesting this too, but then thought there was a value to creating a change process like this proposed one, that was not allowed to make rule changes. The main long-term reason for keeping the main sequence of proposal numbers going is for rule change/FLR research and corrections - non rule-changes don't need the same level of historicity. If a type of proposal is restricted to non rule-changes, I think we can detach from the multi-officer numbering process and evolve a new experimental system for the non-retroactive setting of our more ephemeral quantities - that might be interesting to try.
Re: DIS: [Proto-proposal] Hotfixes
I think it would be better to have some sort of proposal expedition mechanism again. It's more general and cleaner (no need to have another free-text decision type). The basic principle is to have a process whereby a person can mark a proposal as urgent, and then to process it in some special accelerated fashion. -Aris On Tue, May 28, 2019 at 8:47 AM ATMunn wrote: > > On 5/28/2019 11:19 AM, ais...@alumni.bham.ac.uk wrote:>> For such > a decision, the vote collector is the Assessor, and the > >> adoption index is 3.0. > > > > I'm fairly sure there are more essential parameters than that (although > > some of them may be implied by the existence of an adoption index?). > > It'd be worth finding the whole list of essential parameters and > > ensuring that they're all specified by something. > > > I thought so too, but I was basing it off the proposal rules, which had > just this and the information about the proposal. I dunno, I'll have to > look into it some more.
Re: DIS: [Proto-proposal] Hotfixes
A big question to me is whether such fixes should be retroactive? Probably not - that's what ratification is for.So one option (an even faster hotfix) is to allow anything that can be self-ratified to also be changable in a non-retroactive manner with 3 Agoran Consent. Maybe excepting votes! On Tue, May 28, 2019 at 8:47 AM ATMunn wrote: > > On 5/28/2019 11:19 AM, ais...@alumni.bham.ac.uk wrote:>> For such > a decision, the vote collector is the Assessor, and the > >> adoption index is 3.0. > > > > I'm fairly sure there are more essential parameters than that (although > > some of them may be implied by the existence of an adoption index?). > > It'd be worth finding the whole list of essential parameters and > > ensuring that they're all specified by something. > > > I thought so too, but I was basing it off the proposal rules, which had > just this and the information about the proposal. I dunno, I'll have to > look into it some more.
Re: DIS: [Proto-proposal] Hotfixes
On 5/28/2019 11:19 AM, ais...@alumni.bham.ac.uk wrote:>> For such a decision, the vote collector is the Assessor, and the adoption index is 3.0. I'm fairly sure there are more essential parameters than that (although some of them may be implied by the existence of an adoption index?). It'd be worth finding the whole list of essential parameters and ensuring that they're all specified by something. I thought so too, but I was basing it off the proposal rules, which had just this and the information about the proposal. I dunno, I'll have to look into it some more.
Re: DIS: [Proto-proposal] Hotfixes
On Tue, 2019-05-28 at 11:03 -0400, ATMunn wrote: > At most once per Agoran week, any player CAN, by announcement, > propose a hotfix, specifying its text. When a player proposes a > hotfix, an Agoran Decision to enact the hotfix is immediately > started. "an Agoran Decision into whether or not to enact the hotfix". > For such a decision, the vote collector is the Assessor, and the > adoption index is 3.0. I'm fairly sure there are more essential parameters than that (although some of them may be implied by the existence of an adoption index?). It'd be worth finding the whole list of essential parameters and ensuring that they're all specified by something. -- ais523
DIS: [Proto-proposal] Hotfixes
So with all this discussion and confusion about trying to ratify an
incorrect document to fix the gamestate, which frankly flew right over
my head, I thought it might be good to have a better method of fixing
the gamestate when an error has been made.
Right now, if a gamestate error appears, there are two options:
1) do what just recently happened and attempt to ratify an incorrect
document; the problem with this method is that it might not be legal,
and it just doesn't feel right, or
2) create a proposal to fix it; although this is a more sound way to do
it, it has to go through the whole distribution process and can take
quite a while.
For this reason, I came yp with the idea of hotfixes. The idea is that a
hotfix is a piece of text meant to fix an error in the gamestate, and
that an Agoran Decision is immediately started, so as to speed up the
process.
I am sure that this current proposal is very oversimplified (it's been a
while since I've written a proposal) but I wanted to get the idea out there.
Title: "Hotfixes"
AI: 3.0
Author: ATMunn
Enact a new power-3 rule titled "Hotfixes" with the following text:
{
A hotfix is a piece of text which describes a change in the gamestate.
When a hotfix is enacted, the gamestate is modified in order to make
the hotfix as true and accurate as possible in the moment it is enacted.
Such a modification CANNOT cause inconsistencies between the gamestate
and the rules, and CANNOT cause the Rules to be modified in any way.
}
Enact a new power-3 rule titled "Proposing Hotfixes":
{
At most once per Agoran week, any player CAN, by announcement,
propose a hotfix, specifying its text. When a player proposes a hotfix,
an Agoran Decision to enact the hotfix is immediately started.
Players SHOULD NOT propose a hotfix for any reason other than to fix
an error in the gamestate.
For such a decision, the vote collector is the Assessor, and the
adoption index is 3.0.
When the decision of whether to enact a hotfix is resolved, if the
outcome is ADOPTED, then the hotfix is enacted and the gamestate is
modified accordingly.
}
DIS: Re: BUS: Re: OFF: [Promotor] Distribution of Proposals 8178-8179
I vote as follows: 8178 - FOR 8179 - FOR I declare null and void any other votes cast on my behalf. I also protest at the mistreatment of zombies and declare that I shall be campaigning for rights of zombies as valued members of the Agoran community to be respected! :D Signed, Baron von Vaderham From: agora-business on behalf of D Margaux Sent: Tuesday, May 28, 2019 2:58:26 PM To: Agora Business Subject: Re: BUS: Re: OFF: [Promotor] Distribution of Proposals 8178-8179 I vote and cause L to vote as follows: > 8178 Trigon 3.0 n't PRESENT > 8179 D Margaux, Aris 2.0 Intent is Important (v1.1) FOR
DIS: Re: BUS: Re: OFF: [Assessor] Resolution of Proposal 8177
Oops, don't mind me - I see the parallel attempts now this is sooo confusing... On Mon, May 27, 2019 at 11:12 PM Kerim Aydin wrote: > > CoE: My conditional vote quoted below required the report > ratification to go through before the voting period ended (I mis-read > D. Margaux's ratification intent as being without objection, under > which it could have been completed in time). I think this makes the > votes come out as a REJECTED. > > "I change my vote on 8177 to conditional: FOR if all of the switches > for which either the Astronomor or Clork are recordkeepor are at their > default value; AGAINST otherwise. > > On behalf of Telnaior, Telnaior changes er vote on 8177 to > conditional: FOR if all of the switches for which either the > Astronomor or Clork are > recordkeepor are at their default value; AGAINST otherwise." > > On Sun, May 26, 2019 at 7:39 PM D. Margaux wrote: > > > > I resolve the Agoran decision of whether to adopt the below proposal(s) as > > follows: > > > > Result IDAuthor(s) AITitle > > --- > > ADO 8177 Aris, [1] 3.0 Side-Game Suspension Act (v3) > > > > [1] D. Margaux, G. > > > > Proposal 8177 > > === > > FOR: D. Margaux, L, Murphy, Falsifian, VJ Rada, G., Telnaior > > PRESENT: ATMunn, omd > > AGAINST: > > Ballots: 9 (quorum 3) > > AI (F/A): 21/0 (all voters have 3 strength) > > Outcome: ADOPTED > > > > The full text of the aforementioned adopted proposal(s) is included below. > > > > // > > ID: 8177 > > Title: Side-Game Suspension Act (v3) > > Adoption index: 3.0 > > Author: Aris > > Co-authors: D Margaux, G. > > > > Enact a new power 3.0 rule, entitled "Side-Game Suspension", with the > > following text: > > > > > > 1. The Spaaace Rules are defined to be Rules 2588, 2589, 2590, 2591, 2592, > > 2593 and 2594. > > > > 2. The Politics Rules are defined to be Rules 2533, 2534, 2535, 2536, 2537, > > 2538, 2539, 2540, 2586, 2542, and 2543. > > > > 3. Rules to the contrary notwithstanding, the Spaaace Rules are suspended > > and > > have no force or effect until Spaaace is Revived. > > > > 4. Rules to the contrary notwithstanding, the Politics Rules are > > suspended and have no force or effect until Politics is Revived. > > > > 5. A player CAN with 2 support Revive Spaaace (unless Spaaace has already > > been Revived); that player is thereby installed into the office > > of Astronomor. > > > > 6. A player CAN with 2 support Revive Politics (unless Politics has already > > been Revived); that player is thereby installed into the office of > > Clork. > > > > 7. If Politics and Spaaace have both been Revived, then any player CAN > > cause > > this Rule to repeal itself with Notice. > > > > 8. Any player CAN with Agoran Consent trigger this Rule. When this Rule is > > triggered, the following events happen in order: (a) the Politics Rules > > are > > automatically repealed in ascending numerical order (unless > > Politics has been > > Revived), (b) the Spaaace Rules are automatically repealed in ascending > > numerical order (unless Spaaace has been Revived), and (c) this Rule is > > automatically repealed.
