Re: DIS: Re: BUS: Re: OFF: [Promotor] Distribution of Proposals 8253-8264
On Sun, Oct 27, 2019 at 9:46 PM Aris Merchant wrote: > Oh, also, well you’re at it, could you change “correctly identified” to > “correctly and publicly identified” so that no one, like, hides the fact > that they’ve identified it and then still claims they’ve invalidated the > decision? I just submitted a longer proposal that effectively does that, though I'm not sure how it'll be received. It replaces the clause with a form of self-ratification. It also uses the wording "the notice must clearly specify" rather than "lacks a clear specification". I think that helps with your concern a little: the thing that has to be clear changes from 'some part of the notice' to the notice itself, so you can no longer say that "this thing is perfectly clear if extracted from the notice and read in isolation". I'm keeping this proposal around as well because the other one may not pass. However, I'm not convinced that "unobfuscated" is different enough from "clear" to make a difference. I'll think about the wording some more.
Re: DIS: Re: BUS: Re: OFF: [Promotor] Distribution of Proposals 8253-8264
On Sun, Oct 27, 2019 at 9:41 PM Aris Merchant <
thoughtsoflifeandligh...@gmail.com> wrote:
> On Sun, Oct 27, 2019 at 9:31 PM omd wrote:
>
> > On Sat, Oct 26, 2019 at 11:31 PM Aris Merchant
> > wrote:
> > > 8265 twg, [3] 3.0 [4]
> >
> > FOR.
> >
> > Proposal: Where's my clarity requirement? (AI=3)
> > {
> > Amend Rule 107 (Initiating Agoran Decisions) by replacing:
> >
> > This notice is invalid if it lacks any of the following
> > information, and the lack is correctly identified within one
> > week after the notice is published:
> >
> > with:
> >
> > This notice is invalid if it lacks a clear specification of any
> > of the following information, and the lack is correctly
> > identified within one week after the notice is published:
> > }
>
>
>
> > I’m not convinced that this is unclear. It’s obfuscated and hidden, but
> hiding something and obfuscating it doesn’t make it unclear. Also, I’d like
> to point out that this is a one off situation and is highly unlikely to
> ever come up again. That said, if you actually want your change to be
> helpful, a better standard might be “unobfuscated” or perhaps “clear and
> unobfuscated”.
>
> -Aris
>
Oh, also, well you’re at it, could you change “correctly identified” to
“correctly and publicly identified” so that no one, like, hides the fact
that they’ve identified it and then still claims they’ve invalidated the
decision?
-Aris
DIS: Re: BUS: Re: OFF: [Promotor] Distribution of Proposals 8253-8264
On Sun, Oct 27, 2019 at 9:31 PM omd wrote:
> On Sat, Oct 26, 2019 at 11:31 PM Aris Merchant
> wrote:
> > 8265 twg, [3] 3.0 [4]
>
> FOR.
>
> Proposal: Where's my clarity requirement? (AI=3)
> {
> Amend Rule 107 (Initiating Agoran Decisions) by replacing:
>
> This notice is invalid if it lacks any of the following
> information, and the lack is correctly identified within one
> week after the notice is published:
>
> with:
>
> This notice is invalid if it lacks a clear specification of any
> of the following information, and the lack is correctly
> identified within one week after the notice is published:
> }
> I’m not convinced that this is unclear. It’s obfuscated and hidden, but
hiding something and obfuscating it doesn’t make it unclear. Also, I’d like
to point out that this is a one off situation and is highly unlikely to
ever come up again. That said, if you actually want your change to be
helpful, a better standard might be “unobfuscated” or perhaps “clear and
unobfuscated”.
-Aris
Re: DIS: ATTN omd / Distributor (was Re: jobs)
On Sat, Oct 26, 2019 at 5:48 PM James Cook wrote: > Our H. Distributor tried in June to enable from-address-rewriting for > messages with this problem, but I'm not sure it worked. See for > example my 2019-07-01 message to the discussion list [0]. > > omd, do you have any insight on what is going on? > > [0] > https://mailman.agoranomic.org/cgi-bin/mailman/private/agora-discussion/2019-July/054651.html Well, protonmail.com has p=quarantine, and Mailman is set to munge >From for both p=quarantine and p=reject, so it should be rewriting From... yet it isn't. Hmm. *sigh* I see. From munging is performed by the SpamDetect pass, and I had manually disabled that pass because – according to a comment I left at the time – it caused Python errors related to Unicode handling. So it never actually took effect. I just re-enabled the pass, and also upgraded Mailman to the tip of the 2.1 branch just in case it fixes the Unicode issue. If it doesn't, the list might start dropping messages fitting whatever pattern was triggering the issue in the past, in which case I'll have to actually find the bug and fix it. For now, though... I just sent a test message from a ProtonMail account, and From rewriting now seems to be working.
Re: DIS: ATTN omd / Distributor (was Re: jobs)
Thanks for looking into it! Original Message On Oct 27, 2019, 7:15 PM, omd wrote: > On Sat, Oct 26, 2019 at 5:48 PM James Cook wrote: >> Our H. Distributor tried in June to enable from-address-rewriting for >> messages with this problem, but I'm not sure it worked. See for >> example my 2019-07-01 message to the discussion list [0]. >> >> omd, do you have any insight on what is going on? >> >> [0] >> https://mailman.agoranomic.org/cgi-bin/mailman/private/agora-discussion/2019-July/054651.html > > Well, protonmail.com has p=quarantine, and Mailman is set to munge > From for both p=quarantine and p=reject, so it should be rewriting > From... yet it isn't. Hmm. > > *sigh* I see. From munging is performed by the SpamDetect pass, and I > had manually disabled that pass because – according to a comment I > left at the time – it caused Python errors related to Unicode > handling. So it never actually took effect. > > I just re-enabled the pass, and also upgraded Mailman to the tip of > the 2.1 branch just in case it fixes the Unicode issue. If it > doesn't, the list might start dropping messages fitting whatever > pattern was triggering the issue in the past, in which case I'll have > to actually find the bug and fix it. > > For now, though... I just sent a test message from a ProtonMail > account, and From rewriting now seems to be working.
DIS: test
test Sent with [ProtonMail](https://protonmail.com) Secure Email.
Re: DIS: Re: BUS: Re: OFF: [Promotor] Distribution of Proposals 8253-8264
On 10/27/2019 12:36 PM, Aris Merchant wrote: On Sun, Oct 27, 2019 at 12:32 PM Kerim Aydin wrote: On 10/26/2019 11:30 PM, Aris Merchant wrote: 8265 twg, [3] 3.0 [4] I vote AGAINST 8265, and act on behalf of Rance to vote AGAINST. First, the text was not included with the distribution. While it has been previously published in a way that *probably* satisfies the notice period, I do not feel comfortable voting for it in this manner where it is distributed without its text. Second, the fact that there is neither a descriptive title (to go looking for its text) nor a proposal text makes me wonder if it passes any of the tests of clearly indicating the matter being voted on. Would a player who hadn't been following along with proposal drafts have any reasonable idea how to find the proposal text, or know what's being referenced at all? Third, from my memory of the text (I'm not inclined to go searching), I'm sorry, it was fun and cute at power-1, but when you get to the point when you need so many exceptions and power-3 to make it work, I'm not comfortable with it. It’s in there, it’s just deliberately obfuscated (specifically, it’s in the middle of the list and the ID is obfuscated by having underscores between each number). I was wondering if someone was going to object to that, but I implemented those changes during the draft stage and I figured someone would have objected then if it were considered problematic. I jumped to the end because I was concerned about this proposal in the first place, I wasn't sure if I was going to go PRESENT or AGAINST (for the third reason I gave). I think the deliberate obfuscation has made up my mind here to stick with AGAINST. Sorry.
Re: DIS: Re: BUS: Re: OFF: [Promotor] Distribution of Proposals 8253-8264
On 10/27/2019 12:42 PM, Aris Merchant wrote: On Sun, Oct 27, 2019 at 12:40 PM Kerim Aydin wrote: On 10/26/2019 11:44 PM, Aris Merchant wrote: CoE: The proposal pool wasn't empty. Accepted. Revision: At 23:00 UTC on October 26, the proposal pool contained only the listed proposals. CoE on the Proposal Pool: several proposals were submitted that I don't see listed nor distributed (Emerald ribbons, Deputisation fix, Glitter are three). Apologies if I'm missing them. Hmm. So what I was trying to say there was that at 23:00 UTC on the 26th, none of those other proposals had yet been submitted. I think that should work, given that we’ve conventionally allowed backdated reports so long as the time specified is still in the current week? Yah the issue is that the original report had a firm 27-Oct date, I don't think you can revise the later report by producing an earlier one. Saying "I revise this report by stating that it was correct a week ago before some unspecified changes happened" doesn't really revise that particular report, otherwise an officer could reply to every CoE by just producing a past report. -G.
DIS: Re: BUS: Re: OFF: [Promotor] Distribution of Proposals 8253-8264
On Sun, Oct 27, 2019 at 12:40 PM Kerim Aydin wrote: > > On 10/26/2019 11:44 PM, Aris Merchant wrote: > > CoE: The proposal pool wasn't empty. > > > > Accepted. Revision: At 23:00 UTC on October 26, the proposal pool > > contained only the listed proposals. > > CoE on the Proposal Pool: several proposals were submitted that I don't > see listed nor distributed (Emerald ribbons, Deputisation fix, Glitter are > three). Apologies if I'm missing them. Hmm. So what I was trying to say there was that at 23:00 UTC on the 26th, none of those other proposals had yet been submitted. I think that should work, given that we’ve conventionally allowed backdated reports so long as the time specified is still in the current week? -Aris > >
Re: DIS: Re: OFF: [Promotor] Distribution of Proposals 8253-8264
‐‐‐ Original Message ‐‐‐ On Sunday, October 27, 2019 2:50 AM, Gaelan Steele wrote: > Votes inline. > NttPF
DIS: Re: OFF: [Promotor] Distribution of Proposals 8253-8264
Votes inline.
Gaelan
> On Oct 26, 2019, at 11:31 PM, Aris Merchant
> wrote:
>
> I hereby distribute each listed proposal, initiating the Agoran
> Decision of whether to adopt it, and removing it from the proposal
> pool. For this decision, the vote collector is the Assessor, the
> quorum is 5, the voting method is AI-majority, and the valid
> options are FOR and AGAINST (PRESENT is also a valid vote, as are
> conditional votes).
>
> ID Author(s)AITitle
> ---
> 8253 Murphy, G., Jason Cobb 2.0 Clarify salary
FOR.
> 8254 Jason Cobb 3.0 Anything is POSSIBLE
FOR
> 8255 Jason Cobb 3.0 Possibly-Indeterminate Switches
FOR
> 8256 Murphy, Gaelan 2.0 Yes, Prime Minister
AGAINST
> 8257 Murphy, Gaelan, G. 2.0 The Fat Director
CONDITIONAL: if proposal 8259 has been, or would be if resolved at the same
time as 8257, resolved as ADOPTED, AGAINST. Otherwise, FOR. [my apologies to
the H. assessor]
> 8258 Jason Cobb 2.0 Elections Fix
FOR.
> 8259 Gaelan, Jason Cobb 1.0 [1]
ENDORSE the current ADoP, or FOR if there isn’t one or e doesn’t vote. [Thanks
for bringing that up, Aris. I don’t think the load would be too big—most of the
time, it should be nonexistent because we should still be patching rules to
properly track their switches. The office created by this rule is intentionally
imposed, so the only way for its holder to get rid of it is to fix the rule.
Even if we do have some of these switches lying around for a bit, it’ll at most
be an extra office or two to track, which doesn’t seem like much. That being
said, I’ve never been ADoP, so I’m leaving this up to em.]
> 8260 G. 1.0 The Low Zombie
AGAINST per Aris.
> 8261 G. 3.0 The High Zombie
FOR. Seems harmless enough.
> 8262 G. 1.0 trick candles
AGAINST per Aris
> 8263 nch 3.0 Persistent
FOR
> 8264 nch 1.0 [2]
AGAINST per earlier discussion
> 8265 twg, [3] 3.0 [4]
FOR
>
>
> [1] "Clean up your own mess, without making a bigger one"
> [2] "Encouraging Democracy Through Capitalism or Who Pays Subs Full
> Wages Anyway"
> [3] Murphy, Aris, Jason Cobb
> [4] The empty string, aka ""
>
> The proposal pool is currently empty.
>
> The full text of the aforementioned proposal(s) is included below.
>
> //
> ID: 8253
> Title: Clarify salary
> Adoption index: 2.0
> Author: Murphy
> Co-authors: G., Jason Cobb
>
>
> Amend Rule 2559 (Paydays) by replacing this text:
>
> 2. For each office, if a single player held that office for 16 or
> more days in the previous month and no unforgivable fines were
> levied on em for eir conduct in that office during that time,
> that player earns 5 coins.
>
> with this text:
>
> 2. For each office, if a single player held that office for 16 or
> more days in the previous month and no unforgivable fines were
> levied on em during that month for eir conduct in that office,
> that player earns 5 coins.
>
> [Legislates based on the judgement of CFJ 3774, but also covers edge
> cases like "do something in late September, get dinged for it in early
> October": you still earn your salary for September, but forfeit it for
> October. Covering corner cases like "exit office in early October,
> no October salary to forfeit, impose fine/debt against September salary"
> is left as an exercise for future proposal authors.]
>
> //
> ID: 8254
> Title: Anything is POSSIBLE
> Adoption index: 3.0
> Author: Jason Cobb
> Co-authors:
>
>
> Amend Rule 2152 ("Mother, May I?") by replacing the text "CAN:" with the
> text "CAN, POSSIBLE:".
>
> ["POSSIBLE" is used in the Rules right now, but is never defined; this
> defines it.]
>
> //
> ID: 8255
> Title: Possibly-Indeterminate Switches
> Adoption index: 3.0
> Author: Jason Cobb
> Co-authors:
>
>
> Amend Rule 2162 ("Switches") by replacing the paragraph beginning "If an
> action or set of actions" with the following:
>
> If a type of switch is not explicitly designated as
> possibly-indeterminate by the rule that defines it, and if an action
> or set of actions would cause the value of an instance of that type
> of switch to become indeterminate, that instance instead takes on
> its last determinate and possible value, if any, otherwise it takes
> on its default value.
>
> [Provides an escape hatch so that rules can allow their switches to have
> indeterminate values. This has come up in protos by both me and
> Falsifian. It is useful to have these possibly-indeterminate properties
> be switches, since switches have useful
