Aragon Org Unit Tree

[Darya]

Hello everyone,

We’ve been musing on Aragon ecosystem organization as a concept and come up with an idea of the Org Unit tree. We’d be really grateful for feedback. In case similar ideas have been highlighted or worked on before, please let us know.

Issue

1. In a large organization (30+ members) the majority of members have to participate in every vote, irrespective of its scale and significance.
2. Since all members are peers, they can equally cast votes in votings not related to their expertise (e.g. techies can participate in marketing-related voting and vice versa)
3. Organization activities are not decomposed, there is no division into teams and units.
4. Organization efficiency may go down due to the above stated problems.

Proposal

We suggest decomposing the current organization structure in a form of an Organizational Unit (OU) tree, thus making it endlessly scalable. The OU structure would be applicable to relevant future DAOs.

Each unit will be able to interact with its instances of the existing Aragon applications. For example, a unit will have its own budget and act accordingly. Budgeting will be a transfer of funds from the Finance app of the parent OU to the subsidiary Finance apps according to the standard Aragon rules, i.e. via decision of the parent OU head. Voting takes place if the parent OU head is a committee (there is a separate MiniMeToken and Voting). If the parent OU head is one person, he makes the transfer himself.

Such approach will immediately solve issues 1, 2 and 3, as there’ll be a separate committee to manage each unit and handle specific issues it is experienced in.

Narrowing the circle of voters could increase decision-making efficiency. In particular, one person can lead a child OU and there is no need to vote at all (e.g. small routine tasks or non-costly service payments). This would maximize efficiency and solve problem 4.

DAO Contracts

• Kernel - one, rights - root OU
• ACL - one, rights - root OU
• OU tree
  • Each OU in the tree has its own set of necessary contracts
    • OU contract
    • Vault
    • Finance
    • MiniMeToken (optional)
    • TokenManager (optional)
    • Voting (optional)
    • …
  • Leaves are created and deleted dynamically

OU

Roles

• SETTINGS_ROLE - controls the main settings
• MANAGE_SUB_OU_ROLE - management of child OUs (creating, changing their basic settings, deleting)

Basic settings

• OU head - sole address / committee (has its own token and voting)
• ability to create child OUs - bool
• ability to transfer committee tokens - bool
• ability to divide committee tokens - bool
• OU name - string

OU Actions

• management of child OUs (creating, changing basic settings, deleting)
• access to OU resources, with corresponding access control

Default configuration for root OU creation

All rights are transferred to the voting committee of the root OU members, as it is in the organization at the moment.

Default configuration for child OU creation

Rights are distributed as follows:

• SETTINGS_ROLE - parent OU
• OU contract update - parent OU
• OU contract rights control - parent OU
• act on behalf of OU - OU head
• managing OU applications, except for the OU itself - OU head
• OU application rights management, except for the OU itself - OU head

Technical details

Since OUs can be created and deleted dynamically, current DAO and application set templates should be adapted for a dynamic call, otherwise dynamic analogues should be written.
Also, you will need to adapt Dapp interface core to navigate an OU tree organization.

[burrrata]

This is really cool! Thanks for putting this together and sharing

Why is this thread tagged with the AGP label?

[Darya]

This may be a non-relevant tag.

We’d love to receive some feedback on this idea before moving on with it. There’s a lot of AGPs, development initiatives and changes in the ecosystem, and we may be missing something alike (hopefully not).

[LouisGrx]

Hey there! Using a parent Aragon Org and sub-Aragon Orgs you can somewhat divide an organization in teams and units. By deploying multiple voting app instances you can have different sets of members voting on different things under different rules. Some voting apps may use membership-tokens, other may use reputation tokens…

It looks like part of the Issues you mention can be solved with the current state of Aragon orgs.

Could you please explain in concrete terms how the experience would change using the OU tree solution?

[Darya]

@LouisGrx @burrrata Could you elaborate your thoughts and share the links to the corresponding docs?

Basing on what we have seen and studied before [e.g. https://hack.aragon.org/docs/], we assume that

1. you can’t appoint One person as a OU head,
2. you can’t change the head of the child OU
3. there’s no OU tree and simple navigation for the org structure

[LouisGrx]

Hey! I’m sorry I just don’t really understand the proposition and what an OU tree is concretely

[stellarmagnet]

I really really really love this proposal and 100% think we need this type of architecture in Aragon (or something similar that meets the basic user requirements). This is very dear to Autark’s heart and AGP-73 was written in such a way where we want to work towards making this happen (check out the Research topic for Expanding Finance). There are so many possible approaches that need to be researched.

Some of my early whiteboard sketches from our June offsite:

Some of what I’m adding to this reply is also what I responded to in the question actually just came up in Autark’s chat today:

is there a way that I can create “departments”, “sub-groups” within Open Enterprise, where group of people can manage their own dept funds and decisions, or viceversa a way for each Open Enterprise to opt-in and become part of a wider decisional network?

My response was partly that there are a couple ways to approach departments today, but it basically involves installing the apps into your DAO for each department (including the core ones), essentially mapping the governance to a particular token (which represents a department). The problem is that this can become a cumbersome process and cluttered UX as soon as you approach 3+ departments (or as this thread names “organizational units”).

One example to provide support that this Org Unit proposal can improve UX, is when you think about something like Autark’s Projects app or the core Finance app, which have so many permissions (10 for Projects, 5 for Finance). Right now you have to sign 15 transactions to give a single person “master” privileges for both apps. Rearchitecting with Org Units, you only have to sign one (if I understand this correctly).

There are may be other ways to approach this that don’t require completely rearchitecting things, such as bundling permission updates (kind of similar to how a template can set as many permissions that the EVM allows). Enabling bulk permission updates and enhancing the UI to represent that “master privilege” more may help get us there, but it still won’t be as clean as more native support for such a feature and this doesn’t quite solve the problem entirely (still need to install multiple apps that don’t have much knowledge of each other).

Another possible approach is parent & child DAOs, but this again requires a lot of technical thought and considerations to deliver the most optimal UX.

This permission system that is proposed in this thread is similar to how traditional enterprise software suites such as Oracle and SAP work today. We’re not quite there yet in Aragon, but it will be important eventually if we want Aragon to support managing companies that have hierarchies, or ones that have autonomous pods/departments (like holacracies or cooperatives with empowered committees), or cities and large-scale projects like solving global challenges or building space agencies ( ).

@lkngtn has been filing issues for Open Enterprise that represent the frame of thought that we need more granular permission controls that don’t require adding multiple apps:

• https://github.com/AutarkLabs/open-enterprise/issues/1645
• https://github.com/AutarkLabs/open-enterprise/issues/1644

Thus, I think there seems to be sufficient demand for such a feature set that it should be prioritized soon. This is something Autark will have more time to work on in Q1 2020 and we would love to do more user research and requirements gathering around it.

I urge everyone else who finds this topic intriguing to perhaps start adding your ideas to this thread, and then hopefully it can facilitate broader discussion with other technical experts (cc: @jorge @sohkai @osarrouy), so we can develop a concrete product development plan and determine the most appropriate team to take on different aspects of the project (if other teams buy in to its importance).

Maybe this is something where some supplementary Nest grants or sub-contracts can help out too, but I think that can be determined after more discussion, if it’s deemed important enough.

[Darya]

@stellarmagnet, thank you for the feedback. It’s great there are thoughts and approches along the same lines.

Right now you have to sign 15 transactions to give a single person “master” privileges for both apps. Rearchitecting with Org Units, you only have to sign one (if I understand this correctly).

Yes, this is default behaviour. Like almost all the permisssions are granted to Voting, we would grant them the Org unit head in our case. If the head is not a committee but one person, then it’s easier to grant and use the permissions.
This, however, does not cancel the fact that permissions can be separately granted to smb else (this would again involve signing a bunch of transactions). On the whole, the approach to permission management should be also reviewed and worked on.

Re the org structure as such, we believe that an organization should have different options to choose from and use. If the one we are suggesting could be of use, we would love to proceed.