clearer policy mechanisms

[benoitpointet]

A Policy that grants or constrains authority applies in all Sub-Circles as well, recursively, unless otherwise stated. A Policy that changes a default rule or process in the Constitution applies only within the Circle that holds the Policy, or, if explicitly stated, within all Sub-Circles as well, recursively. In the latter case, a Sub-Circle may still override that Policy via one of its own, unless explicitly forbidden in the original Policy.

This explains in a cumbersome manners when policies are cascading — aka applying to sub-circles as well — and/or overridable. I have hope this can be simplified. I don't really see why the default behaviour is so entangled.

Proposal: make policies cascading and overridable by default, thus simplifying the understanding of this construct, and making them far-reaching yet open constructs:

Policies cascade by default: a Policy applies within the Circle holding it and all its Sub-Circles, unless the Policy itself states differently. When cascading, a Policy may be overriden by another Policy within a Sub-Circle, unless the former forbids it.

[brianjrobertson]

I don't think that makes sense. I believe in the vast majority of cases where a policy is used to override a default rule or process, the intent is for it to only apply in the circle with the policy. So the change you're suggesting would require extra language be added to the vast majority of that type of policy, where the current version only requires language added in the small minority of cases where the intent really is a cascading change. On top of that, the change proposed would likely break many current policies in orgs upgrading from v4.1 to v5.0, where they're assuming that the policy only applies in the circle itself.

If you think I'm wrong, I'd love to see some data: if you go look at all of this kind of policy in an org (or two or three), what percentage of them do seem to intend (or make more sense) applied only to the circle itself vs. cascading? If the data contradicts my belief that the vast majority are likely the former, then I'd probably make this change.

[benoitpointet]

I believe in the vast majority of cases where a policy is used to override a default rule or process, the intent is for it to only apply in the circle with the policy. I have indeed encountered a fair share of those.

So the change you're suggesting would require extra language to be added to the vast majority of that type of policy … Herein lies my real tension, following the principle "explicit over implicit", that last paragraph of 4.2.1 calls for omissions and misunderstandings, assumed behaviour of policies.

And what do you do with a policy that both override a default rule and constrains authority? Does it cascade by default? Is it overridable by default?

So I would even call for more expliciteness, and something like :

A policy must always precise whether it applies recursively to Sub-Circles and whether those Sub-Circles may override it with another Policy.

An advantage of this proposal would lie in the software being able to enforce this when proposing policies and when reading "a role's span of authority".

Another advantage would be that orgs migrating from v4.1 to v5 would be forced to review (circle by circle) all their policies and clarify whether they cascade and/or are overridable.

[brianjrobertson]

Uh oh, this strikes me as a really good point I hadn't considered, and a potential nasty ambiguity:

And what do you do with a policy that both override a default rule and constrains authority? Does it cascade by default? Is it overridable by default?

I'm not sure what to do about it though, because I'm still feeling solid in the thoughts I shared above as well. Hmm... I'll reflect further, and if anyone has any new ideas or potential solutions to consider as well, please do share.

[rebeccabrover]

I’d have to give this more of a think. One thing it does surface for me is the complexity of the language here. In particularly, I think recursively needs a simpler and more translatable alternative like repeat.

[chrcowan]

Hmmm...interesting point Benoit. Although maybe the ambiguity can be solved through other means. The phrase, "A Policy that changes a default rule or process in the Constitution..." could maybe be clarified to include something about how these opportunities to change are called out in the constitution, like the tactical meeting process. Not sure that would help. As it is, it's workable to me.

I'll just add I don't like, "A policy must always precise whether it applies recursively to Sub-Circles and whether those Sub-Circles may override it with another Policy" just because that adds burden to every policy.

[brianjrobertson]

I've reflected on this a bunch and I'm not sure what to do about it, or if it's really even all that big of a problem; I think the current text is still the best option, even though there is a case where it's ambiguous and problematic. So, instead of trying to address this constitutionally, I'm going to leave it for software tools to resolve; e.g. GlassFrog could have a flag on policy edit to require a Secretary to specify whether its a rule change or a constraint on authority, with sub-options then to specify whether it cascades or not - that would force users who want different treatment for each part to simply split the policy into two, and it would totally remove any potential ambiguity if they didn't.