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 <[email protected]> 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
