Holacracy-constitution: Allow cross-circles to control domains

[matthewgilliland]

In 1.3.5, we see "A Circle created this way has no Super-Circle and no Domains, and may change its own Purpose or Accountabilities via a Policy."

Does that mean it _can't_ have a domain or simply that it has none by default? It seems like domains (even if not handed down from any super-circle) might be useful in some cases.

[brianjrobertson]

The challenge here is: where would the circle get the domain? It presumably can't just decide it has one itself. If one of the linked-in roles grants the circle one of its domains, then there's really no effect, because the linked-in role still holds the domain as well, and thus no other roles in the circle can impact it (it's effectively already delegated). I suppose the circle could add policies to then limit this effective delegation or authorize impact to the domain... but couldn't it do this anyway? I guess that depends how it's interpreted.

Perhaps the best answer here is to _automatically_ grant a circle created this way all domains of any role linked into the circle? At first, that has exactly zero effect for the reason given above, but does make it super clear that the circle can then add policies to effectively govern the domains of any roles linked in (which should still be safe, since those roles will object or just leave the circle if a proposed policy will cause harm to their domain).

Thoughts?

[lflfm]

I think the circle shouldn't be granted the domains automatically because it may give the false impression that the policies are not needed and that the other roles will get free access to the domains of each-others roles.

It makes more sense to me that the cross-circle could inherit domains from the circles of any participating roles via Role policy. The description of a role policy could perhaps be tweaked slightly to allow this: _"A Role may also contain “Policies”, which are grants or constraints of authority, or special rules that apply to operations within that Role"_ could be extended to something like _"...within that Role's capacity"_.
Further, if a circle does not wish a specific domain to be shareable outside the circle (including cross-circles), they could just set a circle policy restricting domain sharing via role policies.

[leword]

It presumably can't just decide it has one itself.

I'm not sure about this. Of course it can't commandeer some other pre-existing domain. But I'm thinking about the case of creation of new property. As some role filler in the circle (maybe Circle-Lead? do we have that in this scenario?) I go create a new github repo and write some new code. Can't the circle just decide it has domain over that repo/code?

[lflfm]

I go create a new github repo and write some new code. Can't the circle just decide it has domain over that repo/code?

Yes, it can, except when one of the following is true:
a. there is a policy in this or any level of super-circle that restricts or prohibits this in any way
b. the GitHub account is a domain that some other circle or role owns
Do note that you may create tensions if there is a domain/policy governing "social media accounts" or similar where they may interpret GitHub to be one (or not).
We are talking about normal circles in this case; which is not what the original post is about - a cross-circle has no super-circle so which policies apply to it? 🤔🤷‍
And then there's always the problem: when the cross-circle is dissolved, who inherits its domains if it has any? I'd pound on my suggestion to tweak the Role Policy description to extend the possibility of granting rules to "that role's capacity" instead of just "within that role"... this way the role is allowed to share any domains that it can touch while retaining ownership.

[brianjrobertson]

@lflfm That language tweak isn't needed to achieve what you're suggesting here; "within that role" only applies to the clause about "special rules", where this would be a "grant of authority", which is not limited by the "within that role" clause. So, what you're saying is already possible, and would be the default approach to achieve the same result if we don't allow a cross-circle to get a domain.

@leword In the current text of v5.0 beta (and in v4.1), no, a circle can not just decide it has domain over something it creates. I've wondered for years now whether this should be allowed, but I haven't found any concrete cases yet where it's useful/needed...

Overall, I'm leaning towards keeping the current approach and not allowing domains on cross-circles, given that a role linked in can always choose to grant the circle access to its domains. Although @leword has opened the question for me of whether this cross-circle construct is the thing that makes the claiming-domain approach actually useful, so I'm pondering that more still...

[chrcowan]

I think you leave it as is. I was going to try and make an argument that the starting sentence should be clearer on the fact that a role can grant that circle its domains, but I don't actually think that's needed.

[matthewgilliland]

In the current text of v5.0 beta (and in v4.1), no, a circle can not just decide it has domain over something it creates. I've wondered for years now whether this should be allowed, but I haven't found any concrete cases yet where it's useful/needed...

@brianjrobertson I agree that it doesn't make sense for the circle to autocratically decide it has domain over something relative to the whole organization, but even at H1 now we have domains that aren't passed down from supercircles and are quite useful; there's one in the Marketing circle, for example, where a role in that circle has a domain over a system, and even though it's only effective relative to the other roles in that circle, it does the needed job because the only roles with access to the system are in that circle.

I think the case @leword brings up is another example where that would likely be both sufficient and useful.

[brianjrobertson]

@matthewgilliland What you describe there is still allowed in v5 beta - you can still define a Domain within a circle that isn't on the circle itself, as long as it's only relevant within the circle; the example you gave sounds like it meets that criteria and thus would be allowed. So, I'm not sure that's relevant to the main question in this thread: should we allow domains to get added to the circle itself, and if so, how/where do they come from?

[brianjrobertson]

I figured out how to enable this gracefully, while improving overall design cohesion.