Re: DIS: Re: BUS: conducting some business
Really?
If the first attempt worked, then the second attempt didn't, so the
action was performed exactly once.
If the first attempt failed, then the second attempt worked, so the
action was performed exactly once.
There were no changes to the gamestate between the two attempts, and I
don't think it's in anybody's report exactly when I deputised for the
office, so isn't the gamestate unambiguous now?
Jason Cobb
On 7/29/19 1:16 AM, Kerim Aydin wrote:
Heh - the "if I have not done so already" is conditional on whether your
previous conditional worked so you haven't solved your problem...
On 7/28/2019 9:59 PM, Jason Cobb wrote:
Oh, I didn't know that.
If I have not done so already, I temporarily deputise for Referee to
perform the following actions:
{
I find Falsifian's Finger Pointing against Jason Cobb to be Shenanigans.
}
(I really hope this doesn't get me another No Faking charge...)
Jason Cobb
On 7/29/19 12:57 AM, Aris Merchant wrote:
Precedent (or at least game custom) says that you can’t condition an
action
on whether something is LEGAL. The reason is that SHALLs are often
used for
things that are hard to calculate (e.g. faking), and so such conditions
make the gamestate ambiguous.
-Aris
On Sun, Jul 28, 2019 at 9:08 PM Jason Cobb
wrote:
I note that the office of Referee is vacant because its former holder
(R. Lee) has ceased to be a player.
If I CAN do so, and if it is LEGAL for me to do so, I temporarily
deputise for Referee to perform the following actions:
{
I find Falsifian's Finger Pointing against Jason Cobb to be
Shenanigans.
}
(this is legal by my reading because there's no restriction on me
resolving a Finger-point against myself.)
I recognize that this is really scammy and probably against game
custom,
but oh well.
Jason Cobb
On 7/24/19 9:58 AM, James Cook wrote:
Just in case, for future reference, here's my record of purported
actions related to NSC:
2019-07-22 20:22: 10 Coins G. -> NSC
2019-07-22 20:39: 10 Coins NSC -> Trigon
2019-07-22 21:42: 4 Coins NSC -> Jason Cobb
2019-07-22 21:42: 2 Coins NSC -> Jason Cobb (with comment:
TURNPIKE)
2019-07-22 21:42: 6 Coins NSC -> Jason Cobb (with comment:
BLACKMAIL)
2019-07-22 23:19: R. Lee does everything 15 times
- Falsifian
I Point my Finger at Jason Cobb for violating Rule 2471 (No Faking).
Jason Cobb published messages claiming e transferred a total of 12
Coins from NSC, when NSC had at most 10 Coins. I can think of three
cases:
* E did not know the text of NSC, in which case e surely believed eir
actions would not be effective, and so violated R2471 with the first
attempted action.
* E did know the text, and therefore knew specifically which of the
actions would fail.
* E did know the text, but the text makes it hard for em to know
which
of the earlier actions would succeed, so e did not know which of the
later actions would succeed. This seems unlikely, but I welcome Jason
Cobb to try to convince us of this.
I do think the statements were made with the intent to mislead: there
wis intentionally uncertainty around what NSC is, and Jason Cobb must
have known eir statements would add to the confusion.
--
- Falsifian
Re: DIS: Re: BUS: conducting some business
Heh - the "if I have not done so already" is conditional on whether your
previous conditional worked so you haven't solved your problem...
On 7/28/2019 9:59 PM, Jason Cobb wrote:
Oh, I didn't know that.
If I have not done so already, I temporarily deputise for Referee to perform
the following actions:
{
I find Falsifian's Finger Pointing against Jason Cobb to be Shenanigans.
}
(I really hope this doesn't get me another No Faking charge...)
Jason Cobb
On 7/29/19 12:57 AM, Aris Merchant wrote:
Precedent (or at least game custom) says that you can’t condition an action
on whether something is LEGAL. The reason is that SHALLs are often used for
things that are hard to calculate (e.g. faking), and so such conditions
make the gamestate ambiguous.
-Aris
On Sun, Jul 28, 2019 at 9:08 PM Jason Cobb wrote:
I note that the office of Referee is vacant because its former holder
(R. Lee) has ceased to be a player.
If I CAN do so, and if it is LEGAL for me to do so, I temporarily
deputise for Referee to perform the following actions:
{
I find Falsifian's Finger Pointing against Jason Cobb to be Shenanigans.
}
(this is legal by my reading because there's no restriction on me
resolving a Finger-point against myself.)
I recognize that this is really scammy and probably against game custom,
but oh well.
Jason Cobb
On 7/24/19 9:58 AM, James Cook wrote:
Just in case, for future reference, here's my record of purported
actions related to NSC:
2019-07-22 20:22: 10 Coins G. -> NSC
2019-07-22 20:39: 10 Coins NSC -> Trigon
2019-07-22 21:42: 4 Coins NSC -> Jason Cobb
2019-07-22 21:42: 2 Coins NSC -> Jason Cobb (with comment: TURNPIKE)
2019-07-22 21:42: 6 Coins NSC -> Jason Cobb (with comment: BLACKMAIL)
2019-07-22 23:19: R. Lee does everything 15 times
- Falsifian
I Point my Finger at Jason Cobb for violating Rule 2471 (No Faking).
Jason Cobb published messages claiming e transferred a total of 12
Coins from NSC, when NSC had at most 10 Coins. I can think of three
cases:
* E did not know the text of NSC, in which case e surely believed eir
actions would not be effective, and so violated R2471 with the first
attempted action.
* E did know the text, and therefore knew specifically which of the
actions would fail.
* E did know the text, but the text makes it hard for em to know which
of the earlier actions would succeed, so e did not know which of the
later actions would succeed. This seems unlikely, but I welcome Jason
Cobb to try to convince us of this.
I do think the statements were made with the intent to mislead: there
wis intentionally uncertainty around what NSC is, and Jason Cobb must
have known eir statements would add to the confusion.
--
- Falsifian
Re: DIS: Re: BUS: conducting some business
IANAL. Not that this is really relevant, but if there's been severe misconduct in the first trial, then jeopardy never attaches (because the defendant was never "in jeopardy"), and the accused can be retried. Jason Cobb On 7/29/19 12:55 AM, Rebecca wrote: (just as it is in the real life consequence in cases of, say, bribing the jurors)
Re: DIS: Re: BUS: conducting some business
Precedent (or at least game custom) says that you can’t condition an action
on whether something is LEGAL. The reason is that SHALLs are often used for
things that are hard to calculate (e.g. faking), and so such conditions
make the gamestate ambiguous.
-Aris
On Sun, Jul 28, 2019 at 9:08 PM Jason Cobb wrote:
> I note that the office of Referee is vacant because its former holder
> (R. Lee) has ceased to be a player.
>
> If I CAN do so, and if it is LEGAL for me to do so, I temporarily
> deputise for Referee to perform the following actions:
>
> {
>
> I find Falsifian's Finger Pointing against Jason Cobb to be Shenanigans.
>
> }
>
> (this is legal by my reading because there's no restriction on me
> resolving a Finger-point against myself.)
>
> I recognize that this is really scammy and probably against game custom,
> but oh well.
>
> Jason Cobb
>
> On 7/24/19 9:58 AM, James Cook wrote:
> >> Just in case, for future reference, here's my record of purported
> >> actions related to NSC:
> >>
> >> 2019-07-22 20:22: 10 Coins G. -> NSC
> >> 2019-07-22 20:39: 10 Coins NSC -> Trigon
> >> 2019-07-22 21:42: 4 Coins NSC -> Jason Cobb
> >> 2019-07-22 21:42: 2 Coins NSC -> Jason Cobb (with comment: TURNPIKE)
> >> 2019-07-22 21:42: 6 Coins NSC -> Jason Cobb (with comment: BLACKMAIL)
> >> 2019-07-22 23:19: R. Lee does everything 15 times
> >>
> >> - Falsifian
> > I Point my Finger at Jason Cobb for violating Rule 2471 (No Faking).
> >
> > Jason Cobb published messages claiming e transferred a total of 12
> > Coins from NSC, when NSC had at most 10 Coins. I can think of three
> > cases:
> >
> > * E did not know the text of NSC, in which case e surely believed eir
> > actions would not be effective, and so violated R2471 with the first
> > attempted action.
> >
> > * E did know the text, and therefore knew specifically which of the
> > actions would fail.
> >
> > * E did know the text, but the text makes it hard for em to know which
> > of the earlier actions would succeed, so e did not know which of the
> > later actions would succeed. This seems unlikely, but I welcome Jason
> > Cobb to try to convince us of this.
> >
> > I do think the statements were made with the intent to mislead: there
> > wis intentionally uncertainty around what NSC is, and Jason Cobb must
> > have known eir statements would add to the confusion.
> >
> > --
> > - Falsifian
>
Re: DIS: Re: BUS: conducting some business
This is actually proof of why double jeopardy attaching on an acquittal is
a bad plan in the agoran context (just as it is in the real life
consequence in cases of, say, bribing the jurors)
On Monday, July 29, 2019, Rebecca wrote:
> Someone just point another finger, and assign it to the arbitor.
>
> On Monday, July 29, 2019, Jason Cobb wrote:
>
>> I note that the office of Referee is vacant because its former holder (R.
>> Lee) has ceased to be a player.
>>
>> If I CAN do so, and if it is LEGAL for me to do so, I temporarily
>> deputise for Referee to perform the following actions:
>>
>> {
>>
>> I find Falsifian's Finger Pointing against Jason Cobb to be Shenanigans.
>>
>> }
>>
>> (this is legal by my reading because there's no restriction on me
>> resolving a Finger-point against myself.)
>>
>> I recognize that this is really scammy and probably against game custom,
>> but oh well.
>>
>> Jason Cobb
>>
>> On 7/24/19 9:58 AM, James Cook wrote:
>>
>>> Just in case, for future reference, here's my record of purported
actions related to NSC:
2019-07-22 20:22: 10 Coins G. -> NSC
2019-07-22 20:39: 10 Coins NSC -> Trigon
2019-07-22 21:42: 4 Coins NSC -> Jason Cobb
2019-07-22 21:42: 2 Coins NSC -> Jason Cobb (with comment: TURNPIKE)
2019-07-22 21:42: 6 Coins NSC -> Jason Cobb (with comment: BLACKMAIL)
2019-07-22 23:19: R. Lee does everything 15 times
- Falsifian
>>> I Point my Finger at Jason Cobb for violating Rule 2471 (No Faking).
>>>
>>> Jason Cobb published messages claiming e transferred a total of 12
>>> Coins from NSC, when NSC had at most 10 Coins. I can think of three
>>> cases:
>>>
>>> * E did not know the text of NSC, in which case e surely believed eir
>>> actions would not be effective, and so violated R2471 with the first
>>> attempted action.
>>>
>>> * E did know the text, and therefore knew specifically which of the
>>> actions would fail.
>>>
>>> * E did know the text, but the text makes it hard for em to know which
>>> of the earlier actions would succeed, so e did not know which of the
>>> later actions would succeed. This seems unlikely, but I welcome Jason
>>> Cobb to try to convince us of this.
>>>
>>> I do think the statements were made with the intent to mislead: there
>>> wis intentionally uncertainty around what NSC is, and Jason Cobb must
>>> have known eir statements would add to the confusion.
>>>
>>> --
>>> - Falsifian
>>>
>>
>
> --
> From R. Lee
>
>
--
>From R. Lee
Re: DIS: Re: BUS: conducting some business
Someone just point another finger, and assign it to the arbitor.
On Monday, July 29, 2019, Jason Cobb wrote:
> I note that the office of Referee is vacant because its former holder (R.
> Lee) has ceased to be a player.
>
> If I CAN do so, and if it is LEGAL for me to do so, I temporarily deputise
> for Referee to perform the following actions:
>
> {
>
> I find Falsifian's Finger Pointing against Jason Cobb to be Shenanigans.
>
> }
>
> (this is legal by my reading because there's no restriction on me
> resolving a Finger-point against myself.)
>
> I recognize that this is really scammy and probably against game custom,
> but oh well.
>
> Jason Cobb
>
> On 7/24/19 9:58 AM, James Cook wrote:
>
>> Just in case, for future reference, here's my record of purported
>>> actions related to NSC:
>>>
>>> 2019-07-22 20:22: 10 Coins G. -> NSC
>>> 2019-07-22 20:39: 10 Coins NSC -> Trigon
>>> 2019-07-22 21:42: 4 Coins NSC -> Jason Cobb
>>> 2019-07-22 21:42: 2 Coins NSC -> Jason Cobb (with comment: TURNPIKE)
>>> 2019-07-22 21:42: 6 Coins NSC -> Jason Cobb (with comment: BLACKMAIL)
>>> 2019-07-22 23:19: R. Lee does everything 15 times
>>>
>>> - Falsifian
>>>
>> I Point my Finger at Jason Cobb for violating Rule 2471 (No Faking).
>>
>> Jason Cobb published messages claiming e transferred a total of 12
>> Coins from NSC, when NSC had at most 10 Coins. I can think of three
>> cases:
>>
>> * E did not know the text of NSC, in which case e surely believed eir
>> actions would not be effective, and so violated R2471 with the first
>> attempted action.
>>
>> * E did know the text, and therefore knew specifically which of the
>> actions would fail.
>>
>> * E did know the text, but the text makes it hard for em to know which
>> of the earlier actions would succeed, so e did not know which of the
>> later actions would succeed. This seems unlikely, but I welcome Jason
>> Cobb to try to convince us of this.
>>
>> I do think the statements were made with the intent to mislead: there
>> wis intentionally uncertainty around what NSC is, and Jason Cobb must
>> have known eir statements would add to the confusion.
>>
>> --
>> - Falsifian
>>
>
--
>From R. Lee
Re: DIS: Re: BUS: Re: OFF: [Promotor] Distribution of Proposals 8215-8234
On 7/28/19 6:04 PM, Kerim Aydin wrote:
I'm willing to try this voluntarily for Proposals and it might be
interesting to broach the idea of requiring Subject format (that we've
never
done before).
Rule 2463 ("Motion of No Confidence") requires a subject line that
includes "MOTION OF NO CONFIDENCE".
Jason Cobb
Re: DIS: Re: BUS: Re: OFF: [Promotor] Distribution of Proposals 8215-8234
On 7/28/2019 2:49 PM, Aris Merchant wrote: > What would be most helpful would be a flat deadline where I wouldn’t be > obliged to deal with anything after that time. Actually I was just contemplating bringing back Pending with the simple method "all proposals in the Proposal Pool become pending at the beginning of the week" (and either no other way to do it so hard deadline, or a very searchable way to do it like requiring a fee-based "Notice of Urgency" where the label is required like for Notices of Honour). > Incidentally, it’s pretty unlikely that I could persuade y’all to approve > this, but my life would be way simpler if proposals could only be > submitted > in messages that had “proposal” in the subject line. Currently, I have to > read through every public message to even formulate a list of proposals. > If > we went that direction, it would probably make sense to do it for CFJs and > votes as well. I'm willing to try this voluntarily for Proposals and it might be interesting to broach the idea of requiring Subject format (that we've never done before). I don't agree to it for votes for the moment because it's important to record everyone's votes and I'd rather not raise barriers there. CFJs maybe - I don't mind the idea but searching Business for "cfj" or "call" has worked so far without many misses. And since they're not released as a batch, and since CFJs don't require "everyone" to respond the way voting does, it's pretty easy to say "that wasn't really a CFJ" or "oops forgot one" with very limited consequences. -G.
Re: DIS: Re: BUS: Re: OFF: [Promotor] Distribution of Proposals 8215-8234
On Sun, Jul 28, 2019 at 2:38 PM Kerim Aydin wrote: > > On 7/28/2019 2:29 PM, Jason Cobb wrote: > > 8226: summary has "Contractual Delimitation" by Aris, text has > "Cancelling > > Proposals" by twg. > > > > There is no "Contractual Delimitation" in the text section, and > "Cancelling > > Proposals" does not appear in the summary section. > > > > This is a CoE. > > You know, maybe we should have a "the promotor CAN cancel any distribution > within the first 48 hours of the voting period, thus putting the proposal > back in the pool - if e uses this e SHALL re-distribute within 24 hours" or > something. (and some sort of limit so e couldn't just keep cancelling a > proposal forever). > > This could even apply to correctly-distributed proposals with the idea that > "if enough proposals in a batch are wrong so that everyone's confused which > ones are still valid, just start over". > > -G. > That might work. The basic problem I have that stopped me from, e.g., just submitting a draft of this week’s report, is that I’m required to continually update it until official publishing. By the time people have read over the draft (and sometimes even in response to the draft), people will have retracted several proposals, submitted modified versions of some, and added others. What would be most helpful would be a flat deadline where I wouldn’t be obliged to deal with anything after that time. That way I could make really really sure that I got things correct by publishing a draft and checking it several times over, in the knowledge that nothing could change after the deadline. Other officers can do this by publishing a report with an effective date before the time of publishing, but it’s not really an option for Promotor at the moment. Incidentally, it’s pretty unlikely that I could persuade y’all to approve this, but my life would be way simpler if proposals could only be submitted in messages that had “proposal” in the subject line. Currently, I have to read through every public message to even formulate a list of proposals. If we went that direction, it would probably make sense to do it for CFJs and votes as well. -Aris > >
DIS: Re: BUS: Re: OFF: [Promotor] Distribution of Proposals 8215-8234
On 7/28/2019 2:29 PM, Jason Cobb wrote: 8226: summary has "Contractual Delimitation" by Aris, text has "Cancelling Proposals" by twg. There is no "Contractual Delimitation" in the text section, and "Cancelling Proposals" does not appear in the summary section. This is a CoE. You know, maybe we should have a "the promotor CAN cancel any distribution within the first 48 hours of the voting period, thus putting the proposal back in the pool - if e uses this e SHALL re-distribute within 24 hours" or something. (and some sort of limit so e couldn't just keep cancelling a proposal forever). This could even apply to correctly-distributed proposals with the idea that "if enough proposals in a batch are wrong so that everyone's confused which ones are still valid, just start over". -G.
DIS: Ratification via closed timelike curves (was [proposal] Contract party fixes)
Two responses inline...
On Sun, 28 Jul 2019 at 20:20, Kerim Aydin wrote:
> On 7/28/2019 1:03 PM, Aris Merchant wrote:
> > That may be a reasonable point; I know that tends to be a weakness in
> > my proposals, although I tried pretty hard not to do it in that one.
> > Still, I'm not sure I see a much simpler codification of our existing
> > precedents, especially given that it has to be safe. And I think those
> > are good precedents which should darn well be codified. If anyone has
> > simplifications though (including complete alternate approaches), I'd
> > be happy to hear them. As soon as the safety concerns are dealt with,
> > I'll see if I can come up with anything simpler myself.
>
> I thought playing with "timelines" was a really clever concept actually but
> I got bogged down working my way through various things that work due to
> precedents, to see if it codified them or changed them (sometimes "codifying
> precedent" makes something rigid and brittle that was formerly flexible or
> could be overturned, so that's the kind of thing I was looking for).
I've been thinking about another option for implementing ratification,
with the following three possible advantages:
(a) No need to refer to a poorly-defined concept of "gamestate", and I
suspect it would generally simplify the rules.
(b) No multiple timelines. (Like the fixed history model of time
travel.) I think this is an advantage unless you think the rules
aren't complicated enough as it is.
(c) Might not require any high-powered rules to make it work. It's
just a new definition of "ratifiable action" that rules of whatever
power could refer to as they please.
I haven't yet tried to write it out, but hope to do so soon, and since
it's come up, I'll give an outline of my idea:
A "ratifiable" action takes effect at the time it is published, but
only if at some point in the next N days it is ratified (or some
similar condition involving the future).
For example, we could make publishing an officer's report into a
ratifiable action that flips all the listed switches to their listed
values. Then, we could say the change happens immediately, so long as
it is ratified in the future according to the usual self-ratifying
rules.
Between the time when a ratifiable action is published and when it is
ratified (or some time limit for that runs out, etc) it it may be
impossible to know whether the action had an effect. At the time the
actual ratification happens, nothing actually changes, except our
knowledge of the situation.
Some disadvantages I can think of, and some responses to them:
(a) The uncertainty about the gamestate mentioned in the previous
paragraph may be undesirable. But, I think the current situation,
where the gamestate is retroactively changed, is at least as
confusing.
(b) This may lead to paradoxes. But as with (a), I think we're already
in that situation. Right now, I can find an action X that I can
currently take, but that retroactively changes the past so I couldn't
have taken X, that could be a paradox; twg tried to do this when we
fixed dependent actions. The solution is to be careful about when we
allow ratifiable actions.
(c) I claimed we can get rid of references to "gamestate", and
justified it by giving an example about switches and officer's reports
where the word "gamestate" didn't come into it. But if we want to keep
the ability to ratify an arbitrary document (e.g. ratification without
objection), we'd need to keep the wording involving gamestate.
Personally, I'm okay with removing the flexibility to ratify an
arbitrary document, and replace it with a fast-track proposal process.
Instead of ratifying {there are no spaceships}, you would simply
fast-track a proposal: {destroy all spaceships}. If it's really
important that it happen at the time it's originally published, you
could turn it into a ratifiable action as outlined above, so as long
as it's approved soon enough in the future, it takes effect when it's
published.
(d) Currently, it's possible to ratify a document listing an effective
date before it was published. This new system would not allow that. Is
that a big loss?
> > Speaking of those safety concerns, I'm a tad peeved that several
> > people voted against the proposal on the basis that "this might be
> > dangerous", including you, and yet no one seems to be able to explain
> > to me exactly what danger is involved so that I can mitigate it. Yes,
> > it might be dangerous, that's a dangerous area of rule making, and
> > it's quite fair to have high standards. That being said, I'd like to
> > know exactly what the standards are so that I can meet them. At this
> > point it feels like people are saying "there might be problems"
> > without providing anything approaching a direction I can go in to
> > persuade them otherwise.
Sorry, I was mostly just scared by others' comments with that one. I
didn't find time to do a second reading, and even if I did and found
nothing wrong, I don't feel experienced
DIS: Re: OFF: [Promotor] Distribution of Proposals 8215-8234
Proposal text for 8224 accidentally in 8225? > 8224 R. Lee 3.0 Remove Inactive Sods! > 8225 twg, Jason Cobb 1.0 Repairing Defeated Spaceships v3 [snip] > // > ID: 8224 > Title: Remove Inactive Sods! > Adoption index: 3.0 > Author: R. Lee > Co-authors: > > > Deregister each player who has not posted to a public forum in 30 > days. > > // > ID: 8225 > Title: Remove Inactive Sods! > Adoption index: 3.0 > Author: R. Lee > Co-authors: > > > Deregister each player who has not posted to a public forum in 30 > days. > > //
Re: DIS: Re: BUS: [proposal] Contract party fixes
On 7/28/2019 1:03 PM, Aris Merchant wrote: That may be a reasonable point; I know that tends to be a weakness in my proposals, although I tried pretty hard not to do it in that one. Still, I'm not sure I see a much simpler codification of our existing precedents, especially given that it has to be safe. And I think those are good precedents which should darn well be codified. If anyone has simplifications though (including complete alternate approaches), I'd be happy to hear them. As soon as the safety concerns are dealt with, I'll see if I can come up with anything simpler myself. I thought playing with "timelines" was a really clever concept actually but I got bogged down working my way through various things that work due to precedents, to see if it codified them or changed them (sometimes "codifying precedent" makes something rigid and brittle that was formerly flexible or could be overturned, so that's the kind of thing I was looking for). I did find a (possible) technical bug or at least something that seemed off and worth asking about (will have to go look again to remember), though it was after the voting period when I did so. Speaking of those safety concerns, I'm a tad peeved that several people voted against the proposal on the basis that "this might be dangerous", including you, and yet no one seems to be able to explain to me exactly what danger is involved so that I can mitigate it. Yes, it might be dangerous, that's a dangerous area of rule making, and it's quite fair to have high standards. That being said, I'd like to know exactly what the standards are so that I can meet them. At this point it feels like people are saying "there might be problems" without providing anything approaching a direction I can go in to persuade them otherwise. Very valid point and I'm sorry about that - since I was in "voting mode" and not "editing a proto mode" I think I took my reflections on the complexity/inelegance and translated that into "this is muddling enough to me that it might be worrying". I should have translated as "let's think about this some more I'm not quite comfortable yet" rather "unfamiliar = omg danger danger!". (I still might have voted against this version due to the "think about it some more" aspect, but I shouldn't have been alarmist like that). -G.
Re: DIS: Re: BUS: [proposal] Contract party fixes
On Sun, Jul 28, 2019 at 12:52 PM Kerim Aydin wrote: > > > On 7/28/2019 12:41 PM, Aris Merchant wrote: > > Like, forgive me if I'm missing something, but in light of that > > provision I don't see how this could also be broken? > > > > Also, did you ever write that time security proto or come up with a > > list of changes that would be satisfactory? > > I won't have time to think on "deep time protections" for a while. But I > did read your proposal several times and (whether there's anything > explicitly dangerous or not) it honestly struck me as similar to your > comments about some of Jason Cobb's proposals - an inelegant and overly > complex solution to a problem that I'm not convinced needs it. > > (I can't point to any particular thing that's "wrong" that's just my > overall impression of the proposal as a whole). > > -G. That may be a reasonable point; I know that tends to be a weakness in my proposals, although I tried pretty hard not to do it in that one. Still, I'm not sure I see a much simpler codification of our existing precedents, especially given that it has to be safe. And I think those are good precedents which should darn well be codified. If anyone has simplifications though (including complete alternate approaches), I'd be happy to hear them. As soon as the safety concerns are dealt with, I'll see if I can come up with anything simpler myself. Speaking of those safety concerns, I'm a tad peeved that several people voted against the proposal on the basis that "this might be dangerous", including you, and yet no one seems to be able to explain to me exactly what danger is involved so that I can mitigate it. Yes, it might be dangerous, that's a dangerous area of rule making, and it's quite fair to have high standards. That being said, I'd like to know exactly what the standards are so that I can meet them. At this point it feels like people are saying "there might be problems" without providing anything approaching a direction I can go in to persuade them otherwise. -Aris
Re: DIS: Re: BUS: [proposal] Contract party fixes
On 7/28/2019 12:41 PM, Aris Merchant wrote: > Like, forgive me if I'm missing something, but in light of that > provision I don't see how this could also be broken? > > Also, did you ever write that time security proto or come up with a > list of changes that would be satisfactory? I won't have time to think on "deep time protections" for a while. But I did read your proposal several times and (whether there's anything explicitly dangerous or not) it honestly struck me as similar to your comments about some of Jason Cobb's proposals - an inelegant and overly complex solution to a problem that I'm not convinced needs it. (I can't point to any particular thing that's "wrong" that's just my overall impression of the proposal as a whole). -G.
Re: DIS: Re: BUS: [proposal] Contract party fixes
On 7/28/2019 12:21 PM, Aris Merchant wrote: What about the "For the purposes of this rule, agreement includes both consent and agreement specified by contract"? That pretty clearly says that if the contract species it, consent isn't necessary. The way you've written it makes it sound (to me anyway) like explicitly withholding consent can override any agreement specified by the contract. When you say "includes both" there's no notion that one overrides the other and no clear way of determining scope of "consent" nor the relative precedence of different acts of consent. (this is an existing big problem with "consent" in general - this just seems to clarify it in a way that's a little broken). -G.
Re: DIS: Re: BUS: [proposal] Contract party fixes
Like, forgive me if I'm missing something, but in light of that
provision I don't see how this could also be broken?
Also, did you ever write that time security proto or come up with a
list of changes that would be satisfactory?
-Aris
On Sun, Jul 28, 2019 at 12:21 PM Aris Merchant
wrote:
>
> What about the "For the purposes of this rule, agreement includes both
> consent and agreement specified by contract"? That pretty clearly says
> that if the contract species it, consent isn't necessary.
>
> -Aris
>
> On Sun, Jul 28, 2019 at 12:16 PM Kerim Aydin wrote:
> >
> >
> > Actually, I think your proposal may be broken. If a contract (once created
> > with 2 people) explicitly allows a third person to join without the consent
> > of the existing parties, it's not clear if your proposed text overrides that
> > or if "agreeing to the contract that allows other people to join later
> > without further consent" constitutes the needed agreement.
> >
> > E.g. There's a contract between X and Y, and the text of the contract says
> > "Z CAN join by announcement." Y says "I don't agree to Z joining."
> > We don't have good rules to cover that, given that "consent" is something
> > that can be withdrawn (or at least has been held to be withdrawable).
> >
> > The current version is enabling ("CAN if") and this version is preventing
> > ("CANNOT unless") and that changes the weight of how giving agreement is
> > treated, and the relative precedence of past versus current consent.
> >
> > -G.
> >
> > On 7/28/2019 12:02 PM, Aris Merchant wrote:
> > > Okay, I agree that definitely sounds better in the long run. That
> > > being said, there isn't any reason to retract my proposal right now,
> > > so I'm not going to.
> > >
> > >
> > > -Aris
> > >
> > > On Sun, Jul 28, 2019 at 11:57 AM Kerim Aydin wrote:
> > >>
> > >>
> > >> I've been working on a major contract re-write for the last week or so
> > >> based on what we've found/discussed - I'll publish a proto tomorrow-ish.
> > >>
> > >> I don't think we can bolt on to the existing I think it's just better
> > >> to do a complete re-write.
> > >>
> > >> Rough outline:
> > >>
> > >> - Better defines agreements as a whole, and explicitly defines
> > >> several type of agreement: The rules, pledges, private contracts, and
> > >> public contract (and makes it clear that "the rules" don't fall into
> > >> the other categories).
> > >>
> > >> - Some formalization of the bootstrap procedure - a person "tenders
> > >> an offer" consisting of a body of text, to which other parties agree,
> > >> but they can't agree if the text doesn't let them join. Some other
> > >> formalities added (e.g. an offer lasts 1 week by default, or until
> > >> withdrawn, etc.)
> > >>
> > >> - Fixes some of the Consent issues that have been raised.
> > >>
> > >> - Makes it so private contracts can't ENABLE people to do stuff or hold
> > >> any
> > >> currency, etc (no CANs, acts-on-behalf). A private contract only binds
> > >> actions through SHALLs. Only parties to a private contract can point the
> > >> finger at other parties; non-parties lack standing to do that.
> > >>
> > >> - Public contracts have the various abilities that contracts have now
> > >> (act-on-behalf, CAN hold and support currency transfers, etc.) All
> > >> changes to a public contract must be published to take effect, the
> > >> full text must be provided
> > >>
> > >> - Does this by tying public contracts to regulations, and the
> > >> promulgation thereof.
> > >>
> > >> =G.
> > >>
> > >> On 7/28/2019 11:41 AM, Jason Cobb wrote:
> > >>> I already withdrew my original proposal, so the first clause is a no-op.
> > >>>
> > >>> Jason Cobb
> > >>>
> > >>> On 7/28/19 2:13 PM, Aris Merchant wrote:
> > On Tue, Jul 23, 2019 at 12:14 PM Jason Cobb
> > wrote:
> > > I submit the following proposal
> > >
> > > Title: Limited-party contracts
> > >
> > > AI: 2.5
> > >
> > > Text:
> > >
> > > {
> > >
> > > Amend Rule 1742 as follows:
> > >
> > > Before the paragraph beginning "Parties to a contract", insert
> > > the
> > > following paragraph:
> > >
> > > A player generally CAN become a party to an existing
> > > contract by
> > > announcement. However, if the contract explicitly limits the
> > > persons who can become party to itself, any person not
> > > fulfilling those restrictions CANNOT become a party to the
> > > contract. Before the creation of a contract, if a person
> > > could
> > > not, in the hypothetical where the contract already exists,
> > > become party to the contract, e is not counted as
> > > consenting to
> > > the agreement for the purposes of the previous paragraph,
> > > even
> > > if e has agreed to be party to the contract.
> > >
> > > [Comment: The goal is to resolve the
Re: DIS: Re: BUS: [proposal] Contract party fixes
What about the "For the purposes of this rule, agreement includes both
consent and agreement specified by contract"? That pretty clearly says
that if the contract species it, consent isn't necessary.
-Aris
On Sun, Jul 28, 2019 at 12:16 PM Kerim Aydin wrote:
>
>
> Actually, I think your proposal may be broken. If a contract (once created
> with 2 people) explicitly allows a third person to join without the consent
> of the existing parties, it's not clear if your proposed text overrides that
> or if "agreeing to the contract that allows other people to join later
> without further consent" constitutes the needed agreement.
>
> E.g. There's a contract between X and Y, and the text of the contract says
> "Z CAN join by announcement." Y says "I don't agree to Z joining."
> We don't have good rules to cover that, given that "consent" is something
> that can be withdrawn (or at least has been held to be withdrawable).
>
> The current version is enabling ("CAN if") and this version is preventing
> ("CANNOT unless") and that changes the weight of how giving agreement is
> treated, and the relative precedence of past versus current consent.
>
> -G.
>
> On 7/28/2019 12:02 PM, Aris Merchant wrote:
> > Okay, I agree that definitely sounds better in the long run. That
> > being said, there isn't any reason to retract my proposal right now,
> > so I'm not going to.
> >
> >
> > -Aris
> >
> > On Sun, Jul 28, 2019 at 11:57 AM Kerim Aydin wrote:
> >>
> >>
> >> I've been working on a major contract re-write for the last week or so
> >> based on what we've found/discussed - I'll publish a proto tomorrow-ish.
> >>
> >> I don't think we can bolt on to the existing I think it's just better
> >> to do a complete re-write.
> >>
> >> Rough outline:
> >>
> >> - Better defines agreements as a whole, and explicitly defines
> >> several type of agreement: The rules, pledges, private contracts, and
> >> public contract (and makes it clear that "the rules" don't fall into
> >> the other categories).
> >>
> >> - Some formalization of the bootstrap procedure - a person "tenders
> >> an offer" consisting of a body of text, to which other parties agree,
> >> but they can't agree if the text doesn't let them join. Some other
> >> formalities added (e.g. an offer lasts 1 week by default, or until
> >> withdrawn, etc.)
> >>
> >> - Fixes some of the Consent issues that have been raised.
> >>
> >> - Makes it so private contracts can't ENABLE people to do stuff or hold any
> >> currency, etc (no CANs, acts-on-behalf). A private contract only binds
> >> actions through SHALLs. Only parties to a private contract can point the
> >> finger at other parties; non-parties lack standing to do that.
> >>
> >> - Public contracts have the various abilities that contracts have now
> >> (act-on-behalf, CAN hold and support currency transfers, etc.) All
> >> changes to a public contract must be published to take effect, the
> >> full text must be provided
> >>
> >> - Does this by tying public contracts to regulations, and the
> >> promulgation thereof.
> >>
> >> =G.
> >>
> >> On 7/28/2019 11:41 AM, Jason Cobb wrote:
> >>> I already withdrew my original proposal, so the first clause is a no-op.
> >>>
> >>> Jason Cobb
> >>>
> >>> On 7/28/19 2:13 PM, Aris Merchant wrote:
> On Tue, Jul 23, 2019 at 12:14 PM Jason Cobb
> wrote:
> > I submit the following proposal
> >
> > Title: Limited-party contracts
> >
> > AI: 2.5
> >
> > Text:
> >
> > {
> >
> > Amend Rule 1742 as follows:
> >
> > Before the paragraph beginning "Parties to a contract", insert the
> > following paragraph:
> >
> > A player generally CAN become a party to an existing contract
> > by
> > announcement. However, if the contract explicitly limits the
> > persons who can become party to itself, any person not
> > fulfilling those restrictions CANNOT become a party to the
> > contract. Before the creation of a contract, if a person could
> > not, in the hypothetical where the contract already exists,
> > become party to the contract, e is not counted as consenting
> > to
> > the agreement for the purposes of the previous paragraph, even
> > if e has agreed to be party to the contract.
> >
> > [Comment: The goal is to resolve the bug that G. recently showed (with
> > the contract that states that it is impossible to join). This would
> > prevent such a contract by ensuring that it could never reach the two
> > parties required to create it. This also gives force to clauses that
> > purport to limit the set of parties.]
> >
> > }
> I'm sorry, but this is phrased in a vastly more complicated way than
> it needs to be. It's inelegant to add an entire paragraph to add a
> single, simple condition (you can't I submit the following
DIS: A dropped proposal
Attn. H. Promotor, G.: This proposal appears to have been dropped: https://mailman.agoranomic.org/cgi-bin/mailman/private/agora-business/2019-July/040851.html I think this has been ratified out of existence, since it was never distributed, and wasn't ever included in the proposal pool. I just remembered this now because I saw some changes that conflict with it. I don't know if it's game custom to point this out or not, so I'm airing on the side of letting people know. -- Jason Cobb
Re: DIS: Re: BUS: [proposal] Contract party fixes
Actually, I think your proposal may be broken. If a contract (once created
with 2 people) explicitly allows a third person to join without the consent
of the existing parties, it's not clear if your proposed text overrides that
or if "agreeing to the contract that allows other people to join later
without further consent" constitutes the needed agreement.
E.g. There's a contract between X and Y, and the text of the contract says
"Z CAN join by announcement." Y says "I don't agree to Z joining."
We don't have good rules to cover that, given that "consent" is something
that can be withdrawn (or at least has been held to be withdrawable).
The current version is enabling ("CAN if") and this version is preventing
("CANNOT unless") and that changes the weight of how giving agreement is
treated, and the relative precedence of past versus current consent.
-G.
On 7/28/2019 12:02 PM, Aris Merchant wrote:
Okay, I agree that definitely sounds better in the long run. That
being said, there isn't any reason to retract my proposal right now,
so I'm not going to.
-Aris
On Sun, Jul 28, 2019 at 11:57 AM Kerim Aydin wrote:
I've been working on a major contract re-write for the last week or so
based on what we've found/discussed - I'll publish a proto tomorrow-ish.
I don't think we can bolt on to the existing I think it's just better
to do a complete re-write.
Rough outline:
- Better defines agreements as a whole, and explicitly defines
several type of agreement: The rules, pledges, private contracts, and
public contract (and makes it clear that "the rules" don't fall into
the other categories).
- Some formalization of the bootstrap procedure - a person "tenders
an offer" consisting of a body of text, to which other parties agree,
but they can't agree if the text doesn't let them join. Some other
formalities added (e.g. an offer lasts 1 week by default, or until
withdrawn, etc.)
- Fixes some of the Consent issues that have been raised.
- Makes it so private contracts can't ENABLE people to do stuff or hold any
currency, etc (no CANs, acts-on-behalf). A private contract only binds
actions through SHALLs. Only parties to a private contract can point the
finger at other parties; non-parties lack standing to do that.
- Public contracts have the various abilities that contracts have now
(act-on-behalf, CAN hold and support currency transfers, etc.) All
changes to a public contract must be published to take effect, the
full text must be provided
- Does this by tying public contracts to regulations, and the
promulgation thereof.
=G.
On 7/28/2019 11:41 AM, Jason Cobb wrote:
I already withdrew my original proposal, so the first clause is a no-op.
Jason Cobb
On 7/28/19 2:13 PM, Aris Merchant wrote:
On Tue, Jul 23, 2019 at 12:14 PM Jason Cobb wrote:
I submit the following proposal
Title: Limited-party contracts
AI: 2.5
Text:
{
Amend Rule 1742 as follows:
Before the paragraph beginning "Parties to a contract", insert the
following paragraph:
A player generally CAN become a party to an existing contract by
announcement. However, if the contract explicitly limits the
persons who can become party to itself, any person not
fulfilling those restrictions CANNOT become a party to the
contract. Before the creation of a contract, if a person could
not, in the hypothetical where the contract already exists,
become party to the contract, e is not counted as consenting to
the agreement for the purposes of the previous paragraph, even
if e has agreed to be party to the contract.
[Comment: The goal is to resolve the bug that G. recently showed (with
the contract that states that it is impossible to join). This would
prevent such a contract by ensuring that it could never reach the two
parties required to create it. This also gives force to clauses that
purport to limit the set of parties.]
}
I'm sorry, but this is phrased in a vastly more complicated way than
it needs to be. It's inelegant to add an entire paragraph to add a
single, simple condition (you can't I submit the following proposal.
-Aris
---
Title: Contractual Delimitation
Adoption index: 2.5
Author: Aris
Co-authors: Jason Cobb
If a proposal entitled "Limited-party contracts" has passed in the last
month, undo the effects of that proposal.
Amend Rule 1742, "Contracts", by changing the text
"It is IMPOSSIBLE for a person to become a party to a contract without
eir agreement."
to read
"It is IMPOSSIBLE for a person to become a party to a contract without
both eir agreement and the agreement of all other persons who are or would
be parties to that contract.
Re: DIS: Re: BUS: [proposal] Contract party fixes
Okay, I agree that definitely sounds better in the long run. That
being said, there isn't any reason to retract my proposal right now,
so I'm not going to.
-Aris
On Sun, Jul 28, 2019 at 11:57 AM Kerim Aydin wrote:
>
>
> I've been working on a major contract re-write for the last week or so
> based on what we've found/discussed - I'll publish a proto tomorrow-ish.
>
> I don't think we can bolt on to the existing I think it's just better
> to do a complete re-write.
>
> Rough outline:
>
> - Better defines agreements as a whole, and explicitly defines
> several type of agreement: The rules, pledges, private contracts, and
> public contract (and makes it clear that "the rules" don't fall into
> the other categories).
>
> - Some formalization of the bootstrap procedure - a person "tenders
> an offer" consisting of a body of text, to which other parties agree,
> but they can't agree if the text doesn't let them join. Some other
> formalities added (e.g. an offer lasts 1 week by default, or until
> withdrawn, etc.)
>
> - Fixes some of the Consent issues that have been raised.
>
> - Makes it so private contracts can't ENABLE people to do stuff or hold any
> currency, etc (no CANs, acts-on-behalf). A private contract only binds
> actions through SHALLs. Only parties to a private contract can point the
> finger at other parties; non-parties lack standing to do that.
>
> - Public contracts have the various abilities that contracts have now
> (act-on-behalf, CAN hold and support currency transfers, etc.) All
> changes to a public contract must be published to take effect, the
> full text must be provided
>
> - Does this by tying public contracts to regulations, and the
> promulgation thereof.
>
> =G.
>
> On 7/28/2019 11:41 AM, Jason Cobb wrote:
> > I already withdrew my original proposal, so the first clause is a no-op.
> >
> > Jason Cobb
> >
> > On 7/28/19 2:13 PM, Aris Merchant wrote:
> >> On Tue, Jul 23, 2019 at 12:14 PM Jason Cobb wrote:
> >>> I submit the following proposal
> >>>
> >>> Title: Limited-party contracts
> >>>
> >>> AI: 2.5
> >>>
> >>> Text:
> >>>
> >>> {
> >>>
> >>> Amend Rule 1742 as follows:
> >>>
> >>> Before the paragraph beginning "Parties to a contract", insert the
> >>> following paragraph:
> >>>
> >>> A player generally CAN become a party to an existing contract by
> >>> announcement. However, if the contract explicitly limits the
> >>> persons who can become party to itself, any person not
> >>> fulfilling those restrictions CANNOT become a party to the
> >>> contract. Before the creation of a contract, if a person could
> >>> not, in the hypothetical where the contract already exists,
> >>> become party to the contract, e is not counted as consenting to
> >>> the agreement for the purposes of the previous paragraph, even
> >>> if e has agreed to be party to the contract.
> >>>
> >>> [Comment: The goal is to resolve the bug that G. recently showed (with
> >>> the contract that states that it is impossible to join). This would
> >>> prevent such a contract by ensuring that it could never reach the two
> >>> parties required to create it. This also gives force to clauses that
> >>> purport to limit the set of parties.]
> >>>
> >>> }
> >> I'm sorry, but this is phrased in a vastly more complicated way than
> >> it needs to be. It's inelegant to add an entire paragraph to add a
> >> single, simple condition (you can't I submit the following proposal.
> >>
> >> -Aris
> >>
> >> ---
> >> Title: Contractual Delimitation
> >> Adoption index: 2.5
> >> Author: Aris
> >> Co-authors: Jason Cobb
> >>
> >> If a proposal entitled "Limited-party contracts" has passed in the last
> >> month, undo the effects of that proposal.
> >>
> >> Amend Rule 1742, "Contracts", by changing the text
> >>"It is IMPOSSIBLE for a person to become a party to a contract without
> >>eir agreement."
> >>
> >> to read
> >>"It is IMPOSSIBLE for a person to become a party to a contract without
> >>both eir agreement and the agreement of all other persons who are or
> >> would
> >>be parties to that contract.
Re: DIS: Re: BUS: [proposal] Contract party fixes
I've been working on a major contract re-write for the last week or so
based on what we've found/discussed - I'll publish a proto tomorrow-ish.
I don't think we can bolt on to the existing I think it's just better
to do a complete re-write.
Rough outline:
- Better defines agreements as a whole, and explicitly defines
several type of agreement: The rules, pledges, private contracts, and
public contract (and makes it clear that "the rules" don't fall into
the other categories).
- Some formalization of the bootstrap procedure - a person "tenders
an offer" consisting of a body of text, to which other parties agree,
but they can't agree if the text doesn't let them join. Some other
formalities added (e.g. an offer lasts 1 week by default, or until
withdrawn, etc.)
- Fixes some of the Consent issues that have been raised.
- Makes it so private contracts can't ENABLE people to do stuff or hold any
currency, etc (no CANs, acts-on-behalf). A private contract only binds
actions through SHALLs. Only parties to a private contract can point the
finger at other parties; non-parties lack standing to do that.
- Public contracts have the various abilities that contracts have now
(act-on-behalf, CAN hold and support currency transfers, etc.) All
changes to a public contract must be published to take effect, the
full text must be provided
- Does this by tying public contracts to regulations, and the
promulgation thereof.
=G.
On 7/28/2019 11:41 AM, Jason Cobb wrote:
I already withdrew my original proposal, so the first clause is a no-op.
Jason Cobb
On 7/28/19 2:13 PM, Aris Merchant wrote:
On Tue, Jul 23, 2019 at 12:14 PM Jason Cobb wrote:
I submit the following proposal
Title: Limited-party contracts
AI: 2.5
Text:
{
Amend Rule 1742 as follows:
Before the paragraph beginning "Parties to a contract", insert the
following paragraph:
A player generally CAN become a party to an existing contract by
announcement. However, if the contract explicitly limits the
persons who can become party to itself, any person not
fulfilling those restrictions CANNOT become a party to the
contract. Before the creation of a contract, if a person could
not, in the hypothetical where the contract already exists,
become party to the contract, e is not counted as consenting to
the agreement for the purposes of the previous paragraph, even
if e has agreed to be party to the contract.
[Comment: The goal is to resolve the bug that G. recently showed (with
the contract that states that it is impossible to join). This would
prevent such a contract by ensuring that it could never reach the two
parties required to create it. This also gives force to clauses that
purport to limit the set of parties.]
}
I'm sorry, but this is phrased in a vastly more complicated way than
it needs to be. It's inelegant to add an entire paragraph to add a
single, simple condition (you can't I submit the following proposal.
-Aris
---
Title: Contractual Delimitation
Adoption index: 2.5
Author: Aris
Co-authors: Jason Cobb
If a proposal entitled "Limited-party contracts" has passed in the last
month, undo the effects of that proposal.
Amend Rule 1742, "Contracts", by changing the text
"It is IMPOSSIBLE for a person to become a party to a contract without
eir agreement."
to read
"It is IMPOSSIBLE for a person to become a party to a contract without
both eir agreement and the agreement of all other persons who are or would
be parties to that contract.
DIS: Re: BUS: [proposal] Contract party fixes
...which proposal in the affixed message? :P
(I know the one you mean but I don't think it's unambiguous enough to satisfy
R478.)
-twg
‐‐‐ Original Message ‐‐‐
On Sunday, July 28, 2019 6:18 PM, Aris Merchant
wrote:
> Oops, I sent that half typed. If I haven't submitted the proposal in
> the affixed message, I do so.
>
> -Aris
>
> On Sun, Jul 28, 2019 at 11:13 AM Aris Merchant
> thoughtsoflifeandligh...@gmail.com wrote:
>
> > On Tue, Jul 23, 2019 at 12:14 PM Jason Cobb jason.e.c...@gmail.com wrote:
> >
> > > I submit the following proposal
> > > Title: Limited-party contracts
> > > AI: 2.5
> > > Text:
> > > {
> > > Amend Rule 1742 as follows:
> > >
> > > Before the paragraph beginning "Parties to a contract", insert the
> > > following paragraph:
> > >
> > > A player generally CAN become a party to an existing contract by
> > > announcement. However, if the contract explicitly limits the
> > > persons who can become party to itself, any person not
> > > fulfilling those restrictions CANNOT become a party to the
> > > contract. Before the creation of a contract, if a person could
> > > not, in the hypothetical where the contract already exists,
> > > become party to the contract, e is not counted as consenting to
> > > the agreement for the purposes of the previous paragraph, even
> > > if e has agreed to be party to the contract.
> > >
> > >
> > > [Comment: The goal is to resolve the bug that G. recently showed (with
> > > the contract that states that it is impossible to join). This would
> > > prevent such a contract by ensuring that it could never reach the two
> > > parties required to create it. This also gives force to clauses that
> > > purport to limit the set of parties.]
> > > }
> >
> > I'm sorry, but this is phrased in a vastly more complicated way than
> > it needs to be. It's inelegant to add an entire paragraph to add a
> > single, simple condition (you can't I submit the following proposal.
> > -Aris
> >
> > Title: Contractual Delimitation
> > Adoption index: 2.5
> > Author: Aris
> > Co-authors: Jason Cobb
> > If a proposal entitled "Limited-party contracts" has passed in the last
> > month, undo the effects of that proposal.
> > Amend Rule 1742, "Contracts", by changing the text
> > "It is IMPOSSIBLE for a person to become a party to a contract without
> > eir agreement."
> > to read
> > "It is IMPOSSIBLE for a person to become a party to a contract without
> > both eir agreement and the agreement of all other persons who are or would
> > be parties to that contract.
DIS: Re: BUS: Proposal: Increased transparency
On Sunday, July 28, 2019 6:09 PM, Edward Murphy wrote: > Proposal: Increased transparency > (AI = 3) > > Amend Rule 2438 (Ribbons) by replacing the sections for the relevant > types of ribbons with the following sections: > > Green (G): While the holder of an elected office has held it > continuously for 30 days, and has not failed to perform any duties > of that office within the appropriate time limits during those 30 > days, that person qualifies for a Green Ribbon. > > Magenta (M): When, during Agora's Birthday, a person publicly > acknowledges it, that person qualifies for a Magenta Ribbon. > > Transparent (T): A person qualifies for a Transparent Ribbon while > the number of other types of Ribbon that that person qualifies for > and/or was awarded within the previous 7 days is at least 5. I don't think any of these do what you want them to: - As far as I can tell, the change to the green doesn't affect anything. What were you trying to do? - Jason Cobb covered the magenta one. - The change to the transparent one means that gray ribbons and all white ribbons now count towards it, but means that red, orange, cyan, blue, ultraviolet, violet and indigo ribbons _don't_ count if the person already possesses them (because earning them a second time doesn't induce qualification). Try "qualifies for, earned and/or was awarded". -twg
DIS: Re: BUS: Proposal: Increased transparency
On 7/28/19 2:09 PM, Edward Murphy wrote: Magenta (M): When, during Agora's Birthday, a person publicly acknowledges it, that person qualifies for a Magenta Ribbon. This would mean that a person could never claim a Magenta Ribbon (except in the same message as acknowledgment, maybe (?)). Qualification is a continuous state, so this would mean that they qualify for an instant, and then instantly cease qualifying. If you were to write "that person earns a Magenta Ribbon", then they would qualify for a week, and could claim it in that time. Jason Cobb
DIS: Re: BUS: [proposal] Contract party fixes
I already withdrew my original proposal, so the first clause is a no-op.
Jason Cobb
On 7/28/19 2:13 PM, Aris Merchant wrote:
On Tue, Jul 23, 2019 at 12:14 PM Jason Cobb wrote:
I submit the following proposal
Title: Limited-party contracts
AI: 2.5
Text:
{
Amend Rule 1742 as follows:
Before the paragraph beginning "Parties to a contract", insert the
following paragraph:
A player generally CAN become a party to an existing contract by
announcement. However, if the contract explicitly limits the
persons who can become party to itself, any person not
fulfilling those restrictions CANNOT become a party to the
contract. Before the creation of a contract, if a person could
not, in the hypothetical where the contract already exists,
become party to the contract, e is not counted as consenting to
the agreement for the purposes of the previous paragraph, even
if e has agreed to be party to the contract.
[Comment: The goal is to resolve the bug that G. recently showed (with
the contract that states that it is impossible to join). This would
prevent such a contract by ensuring that it could never reach the two
parties required to create it. This also gives force to clauses that
purport to limit the set of parties.]
}
I'm sorry, but this is phrased in a vastly more complicated way than
it needs to be. It's inelegant to add an entire paragraph to add a
single, simple condition (you can't I submit the following proposal.
-Aris
---
Title: Contractual Delimitation
Adoption index: 2.5
Author: Aris
Co-authors: Jason Cobb
If a proposal entitled "Limited-party contracts" has passed in the last
month, undo the effects of that proposal.
Amend Rule 1742, "Contracts", by changing the text
"It is IMPOSSIBLE for a person to become a party to a contract without
eir agreement."
to read
"It is IMPOSSIBLE for a person to become a party to a contract without
both eir agreement and the agreement of all other persons who are or would
be parties to that contract.
DIS: Re: BUS: Proposal: Three-dimensional space
You say "(0, +1)" when I think you mean "(-1, 0, +1)" -Aris On Sun, Jul 28, 2019 at 10:56 AM Edward Murphy wrote: > > Proposal: Three-dimensional space > (AI = 1) > > Amend Rule 2588 (Sectors) to read: > >Sectors are entities. Each Sector has an ID number, which is an >ordered list of three coordinates, each of which is one of >(0, +1). There is one Sector for each such list. These ID >numbers are ordered by their first coordinate, with ties broken >by the second, then the third. > >If no Spaceship is in a particular Sector, then that Sector is >"empty"; otherwise it is "occupied". > >Two Sectors are "adjacent" if one of their coordinates differ by >exactly 1 and their others are the same. > > Repeal Rule 2589 (Galaxy Maintenance). > > Move spaceships to Sectors as follows, based on their owners: > > (-1, -1, -1) omd > (-1, -1, 0) Aris > (-1, -1, +1) Gaelan > (-1, 0, -1) G. > (-1, 0, 0) Cuddle Beam > (-1, 0, +1) Trigon > (-1, +1, -1) Murphy > (-1, +1, 0) R. Lee > (-1, +1, +1) ATMunn > ( 0, -1, -1) twg > ( 0, -1, 0) D. Margaux > ( 0, -1, +1) Baron von Vaderham > ( 0, 0, -1) Falsifian > ( 0, 0, 0) Bernie > ( 0, 0, +1) Rance > ( 0, +1, -1) o > ( 0, +1, 0) Jason Cobb > ( 0, +1, +1) Walker > (+1, -1, -1) nch > (+1, -1, 0) PSS > (+1, -1, +1) Corona > (+1, 0, -1) L > (+1, 0, 0) Hālian > (+1, 0, +1) Jacob Arduino > (+1, +1, -1) Telnaior > (+1, +1, 0) any other non-zombies > (+1, +1, +1) any other zombies > >
Re: DIS: Re: BUS: Space Rebel Uprising
It does, nch currently is not a player. To get around this, Falsifian has submitted a proposal to re-register em. Jason Cobb On 7/28/19 1:25 PM, Edward Murphy wrote: I deregister. I register. How does this not fall afoul of Rule 869's 30-day wait?
DIS: Re: BUS: Space Rebel Uprising
I deregister. I register. How does this not fall afoul of Rule 869's 30-day wait?
