Re: DIS: [Proto] a fix for proposals that depend on other proposals passing

2019-01-13 Thread Kerim Aydin




On 1/13/2019 6:33 PM, Aris Merchant wrote:

I think that dependency should be a CANNOT for the Assesor, rather than a
SHALL NOT, because it ensures that any mistake isn’t legally binding. The
resolution of a proposal is self-ratifying in any case, so it won’t inject
long term uncertainty.


Making it a CANNOT would be a power-3 thing again, to overrule R208 and/or
106.  (If you think about it, it would be a security hole if you could apply
a CANNOT at power-1, because that would mean someone could scam in a power-1
"a proposal CANNOT be resolved unless I say so" rule).



Re: DIS: [Proto] a fix for proposals that depend on other proposals passing

2019-01-13 Thread Aris Merchant
On Sun, Jan 13, 2019 at 4:52 PM Kerim Aydin  wrote:

>
> On 1/13/2019 3:42 PM, ais...@alumni.bham.ac.uk wrote:> Also, a "this
> proposal does not work unless" needs a pretty high power,
>  > which feels like it shouldn't be necessary for this. You might be able
>  > to get away with defining "this proposal is dependent on proposal X" to
>  > mean "this proposal can only pass if proposal X passes", but even
>  > that's on shaky ground if the proposal outpowers the rule.
>
> A proposal has to take effect to apply its definitions (if it's defined
> as a "dependent proposal" internally, that definition clause wouldn't
> take effect if the proposal doesn't).  How about allowing the proposal to
> "take effect" as a whole, but stating that the clauses contained within
> don't make further changes, e.g.:
>   If a Proposal clearly and explicitly states it is a dependent
> proposal,
>   no other clauses in the proposal are applied if its dependencies have
>   not taken effect.
>
> This works (maybe?) because R106 explicitly defers to other rules to figure
> out which individual changes are applied:
>  Except as prohibited by other rules, a proposal that
>takes effect CAN and does, as part of its effect, apply the
>changes that it specifies.
>
> and the fact that, once the proposal takes effect as a whole, it has the
> power as an instrument to nullify the rest of its clauses from being
> applied (it uses the proposal's power to do so, not any rule's power).
>
> For safety and cleanliness, it should be phrased as a free definition
(i.e. “For a proposal to depend on another proposal means for it to take
effect if and only if...”). This would make the rule one long definition,
which the proposal would be applying against itself. In other words, it
would act solely as shorthand for the existing way we do things. The one
tricky bit is the section on deferred resolution, because you have to say
something like “If a proposal states that it depends on another proposal,
it cannot be resolved unless...”.

I think that dependency should be a CANNOT for the Assesor, rather than a
SHALL NOT, because it ensures that any mistake isn’t legally binding. The
resolution of a proposal is self-ratifying in any case, so it won’t inject
long term uncertainty.

-Aris


Re: DIS: [Proto] a fix for proposals that depend on other proposals passing

2019-01-13 Thread Kerim Aydin



On 1/13/2019 3:42 PM, ais...@alumni.bham.ac.uk wrote:> Also, a "this 
proposal does not work unless" needs a pretty high power,

> which feels like it shouldn't be necessary for this. You might be able
> to get away with defining "this proposal is dependent on proposal X" to
> mean "this proposal can only pass if proposal X passes", but even
> that's on shaky ground if the proposal outpowers the rule.

A proposal has to take effect to apply its definitions (if it's defined
as a "dependent proposal" internally, that definition clause wouldn't
take effect if the proposal doesn't).  How about allowing the proposal to
"take effect" as a whole, but stating that the clauses contained within
don't make further changes, e.g.:
 If a Proposal clearly and explicitly states it is a dependent proposal,
 no other clauses in the proposal are applied if its dependencies have
 not taken effect.

This works (maybe?) because R106 explicitly defers to other rules to figure
out which individual changes are applied:
Except as prohibited by other rules, a proposal that
  takes effect CAN and does, as part of its effect, apply the
  changes that it specifies.

and the fact that, once the proposal takes effect as a whole, it has the
power as an instrument to nullify the rest of its clauses from being
applied (it uses the proposal's power to do so, not any rule's power).



Re: DIS: [Proto] a fix for proposals that depend on other proposals passing

2019-01-13 Thread ais...@alumni.bham.ac.uk
On Sun, 2019-01-13 at 16:25 -0700, Reuben Staley wrote:
> Please submit revision ideas for this proto-proposal. I'm pretty sure
> it works this way, but I know there are other ways to do it. Also the
> wording is terrible.

Should be a SHALL NOT on the promotor for resolving proposals out of
order.

Also, a "this proposal does not work unless" needs a pretty high power,
which feels like it shouldn't be necessary for this. You might be able
to get away with defining "this proposal is dependent on proposal X" to
mean "this proposal can only pass if proposal X passes", but even
that's on shaky ground if the proposal outpowers the rule.

-- 
ais523



Re: DIS: [Proto] a fix for proposals that depend on other proposals passing

2019-01-13 Thread Aris Merchant
I very much like the basic idea, although I'd question how often
simple dependencies come up. It's still good as a starting point for
future work though. Fixes follow.

You need to handle indirect dependency cycles. You need to specify
what happens in the case of a dependency cycle (I'd go with every
proposal in the cycle fails to have an effect, since they're clearly
broken; you should also make sure that the resolution order
requirement doesn't apply in this case). You need to specify what
happens if a proposal declares a dependency on a non-existent proposal
(this can be handled with the previous case, using some kind of
catch-all). You need to make REJECTED "an
outcome other than ADOPTED", because FAILED QUORUM or any other
non-ADOPTED outcome still makes it fail.


-Aris

On Sun, Jan 13, 2019 at 3:24 PM Reuben Staley  wrote:
>
> Please submit revision ideas for this proto-proposal. I'm pretty sure it
> works this way, but I know there are other ways to do it. Also the
> wording is terrible.
>
> Title: Dependent Proposals Draft
> Author: Trigon
> Coauthors:
>
> Create a rule entitled "Dependent Proposals" with the text:
>
>If a proposal's text states that it is dependent on one or more
>proposals, it is considered a dependent proposal. The dependencies
>of a dependent proposal are any proposals it is dependent on.
>
>Dependent proposals must be resolved after all of their
>dependencies. Two proposals cannot have each other listed as
>dependencies.
>
>If one or more dependencies of a dependent proposal have the
>outcome REJECTED, then the dependent proposal has no effect.
>
> --
> Trigon


DIS: [Proto] a fix for proposals that depend on other proposals passing

2019-01-13 Thread Reuben Staley
Please submit revision ideas for this proto-proposal. I'm pretty sure it 
works this way, but I know there are other ways to do it. Also the 
wording is terrible.


Title: Dependent Proposals Draft
Author: Trigon
Coauthors:

Create a rule entitled "Dependent Proposals" with the text:

  If a proposal's text states that it is dependent on one or more
  proposals, it is considered a dependent proposal. The dependencies
  of a dependent proposal are any proposals it is dependent on.

  Dependent proposals must be resolved after all of their
  dependencies. Two proposals cannot have each other listed as
  dependencies.

  If one or more dependencies of a dependent proposal have the
  outcome REJECTED, then the dependent proposal has no effect.

--
Trigon