That Planning Suite, live on Rinkeby

Earn some spice, control the universe

Ready to join Dune and earn some spice?

Autark was initially funded via an Aragon Nest grant in April 2018 to develop That Planning Suite: an application suite for Aragon that provides payout, budgeting, and collaboration tools to enable efficient pathways toward allocating governance-enabling tokens to open source project contributors.

In January 2019, we got approved as a Flock team in Aragon Network Vote #1, and one of our primary focuses has been getting The Planning Suite (TPS) into a stage to launch onto Rinkeby — and at last that day has come!

I haven’t slept for 24 hours, so installation instructions will come in the next 1–2 days after we clean up our docs, repos, and other things… But while you patiently wait you can try to interact with the Dune DAO, which has our five apps, or read up below on the general functionality and other notes.

That Planning Suite is a collection of five apps for the Aragon platform that has the following functionality:

• Projects is integrated with Github and allows organizations to allocate tokens or ETH against multiple issues in a single action with the possibility to require DAO approval before funding is allocated. Additionally, Issue Curation proposals can be created via the Projects app, which are forwarded to the Dot Voting app to collectively determine project priorities.
• With Rewards, you can distribute payments to token holders based on the number of tokens one has earned in a specific cycle of time (one-time reward) or based on the total tokens one holds (dividend).
• Dot Voting* is used to cast votes for Allocation or Issue Curation proposals. Members can vote on how to distribute an allocation across distinct entities or prioritize a list of Github issues by specifying a percentage of votes per option.
• Allocations is used to propose a financial allocation meant to be distributed to multiple parties or options. Proposals are forwarded to the Dot Voting app for an organization to collectively determine the distribution of funds. The percentage of the allocation amount distributed to each party is determined based on the results of the Dot Vote.
• The Address Book is for maintaining a list of Ethereum addresses mapped to human-readable names, on-chain. The Address Book will enable a more user-friendly way to access and review common addresses a DAO uses for Allocations and Dot Voting.

Many of the apps are interconnected and are recommended to be installed as an entire suite to maximize decision-making powers for your organization.

* Trigger warning: Not to be confused with Polka-DOT Voting. See: https://en.wikipedia.org/wiki/Dot-voting.

Projects

Projects is integrated with Github and allows organizations to allocate tokens or ETH against multiple issues in a single action, with the possibility to require DAO approval before funding is allocated. Additionally, Issue Curation proposals can be created via the Projects app, which are forwarded to the Dot Voting app to collectively determine project priorities.

How to use it

• Once you have authorized Github, you can create a “New Project” which is essentially a Github repo. When you connect a repo with your organization, anyone else who accesses your DAO’s projects app and authorizes Github will see the repos you have connected.
• On the Issues tab, you can select multiple issues and then either choose “Curate Issues” or “Fund Issues” from the actions menu.
• On the Settings tab, you can set defaults and parameters used for calculating how many tokens are allocated to issue funding proposals, which is calculated based on: # hours * base rate * experience level
• Use Aragon’s Permissions system to restrict who can add repos, remove repos, fund issues, approve work, etc. Review the limitations below before deciding to give the Voting app power over these roles.

Note: while the Projects app is currently integrated with Github, we don’t see this as always being the case. We plan to roll out features as they are demanded, and eventually integrate with Pando for a more fully decentralized solution.

Limitations

• If funding issues requires a DAO vote for approval, the Voting app will have little context on the proposed funding amounts unless the description for the funding proposal contains a link that outlines the funding per issue (although this would have to be trusted). This is due to current limitations in the type of data that can be forwarded to the voting app.
• If funding issues requires a DAO vote for approval, the Projects app does not have any knowledge on the issues that were selected for potential funding until the vote is approved. This is due to a current limitation with how Aragon works.
• Even though it is integrated with Github, we do not have a Github bot for Github.com that comments if an issue has been funded by the organization. The way our system is implemented is catered more towards DAO members that want to help contribute to its tasks.
• If authorizing Github is slow or finicky, please let us know.

Future

• It is a must to ultimately develop a solution that will provide more context to both the Voting and Projects apps of Funding proposals that have yet to be approved. There are various technical limitations that need to be overcome and we intend to contribute to the solutions as part of our Cross Application UX Efforts.
• An item on our near-term roadmap which was in our original Flock proposal is implementing a way to fund project issues with non-transferable tokens.
• We want to provide the ability to review the results of issue curation proposals within the Projects app, making it easier to take action on these priority lists by generating funding proposals.
• We want to eventually release a Projects app that can be used for general task management, which doesn’t require Github, has kanban, and discussion with all data stored on IPFS.
• We want to make it easier for people who are working on a Project’s issues to see what is assigned to them and to have notifications when due dates are approaching.

Rewards

With Rewards, you can distribute payments to token holders based on the number of tokens one has earned in a specific cycle of time (one-time reward) or based on the total tokens one holds (dividend).

• One-time, or Merit Rewards, are determined based on how many tokens a token holder has earned compared to other holders, in a specific time period.
• Dividends are determined based on the percentage of token supply an address holds.

Rewards is our freshest app, hasn’t been thoroughly tested, and still has a few missing aspects like radspec and validation messaging.

How to use it

• To create a reward, select the “New Reward” action, which will open up a panel to specify details such as the reward type, amount, reference asset and cycle.
• Token holders that meet the condition of the reward (e.g. having a balance in a specific period) will be able to claim rewards in the “My Rewards” tab once the end date of the reward is reached (this is estimated based on an average block time of 15 seconds).

Dot Voting

Dot Voting is used to cast votes for Allocation or Issue Curation proposals. Members can vote on how to distribute an allocation across distinct entities or prioritize a list of Github issues by specifying a percentage of votes per option.

How to use it

• The Dot Voting app is configured to a single token which ultimately determines who has the privilege to vote.
• Voting weight on a proposal is based on the token balance when the proposal was created.
• The Dot Voting is useful once a user has created an Allocation proposal or an Issue Curation proposal, as Dot Votes cannot be created from within the app (we did not include this feature since the Survey app serves that purpose).

Future

• We plan on improving the slider interaction so it’s less difficult to vote with your last couple dots, and to incorporate better math utilities to work out kinks with decimal precision.
• We are thinking more about how the general user experience of Voting in the Aragon ecosystem can be improved. It may make more sense to eventually build toward a monolithic Voting app where users can vote in different ways, vs. three apps like Voting, Dot Voting, Surveys. Once multi-contract applications are possible within Aragon, it will be much cleaner to support such experiences.

Address Book

The Address Book is for maintaining a list of Ethereum addresses mapped to human-readable names, on-chain. The Address Book will enable a more user-friendly way to access and review common addresses a DAO uses for Allocations and Dot Voting.

How to use it

• Create a New Entity by specifying a name, Ethereum address and type (individual, organization, project)
• Remove an entity by selecting the “Remove Entity” option in the context menu for the entry

Custom Labels vs. Address Book

In Aragon’s 0.7 Bella release, a “custom labels” system has been released which allows a user to specify names for Ethereum addresses. This functionality is not to be confused with the Address Book. The custom labels system is a local system, meaning that the rest of the organization is not aware of what an individual has entered for a given entry.

Future

• An API is under development for the Aragon platform which will allow every app within Aragon that uses the <IdentityBadge> component for Ethereum addresses to render data from an external data source such as an app like the Address Book. Once this is released, Address Book entries can be useful outside the context of Allocations and Dot Voting.
• We want to eventually provide support for search, sort, and the ability to maintain additional context around entities.

Allocations

Allocations is used to propose a financial allocation meant to be distributed to multiple parties or options. Proposals are forwarded to the Dot Voting app for an organization to collectively determine the distribution of funds. The percentage of the allocation amount distributed to each party is determined based on the results of the Dot Vote.

How to use it

• An account needs to be created via the “New Account” button before proposing an Allocation. Accounts are used to categorize allocation types that occur frequently.
• To propose an allocation, choose the “New Allocation” action from the Account’s context menu.
• In the New Allocation panel, enter an allocation amount which can be drawn from the ETH held in the account, or any of the token’s in your Organization’s vault.

Tips

• Use the Address Book to manage Ethereum addresses you will be sending regular allocations to. Once you have added entries to your address book, you can select “Use address book for options” in the New Allocation panel to select the recipients.
• If categorizing by Account isn’t useful to you, feel free to create a “General” account and create your allocations from this account.

Use cases

• Your organization is determining how to allocate a predefined amount of funds to child organizations or departments. (If the child organizations are also part of Aragon, input the organization’s vault address in your Address Book)
• Your organization has ongoing work areas that aren’t necessarily specific project issues that can be individually funded (e.g. participating on the forum, taking meeting notes, more general contributions). These contributors can be subjects of Allocation proposals meant to give back to community members that contribute in a noticeable manner (and usually on a voluntary basis).

Limitations

• There is a current limitation with how Accounts currently function. An “Account” can hold ETH, but it can transfer tokens that are in the organization’s vault (yet not the Vault’s ETH). This can also be a bit confusing for the user experience.
• Due to these limitations, if tokens are sent to the Account address they will not be accessible.

Future

Before launching to mainnet, we would like to resolve the above limitations. To do so, we plan on enhancing how accounts work so the user experience is more intuitive. One possible solution is:

• Instead of accounts holding/receiving ETH, they will instead function more as budget controls for specific initiatives.
• Accounts will have the following properties:

— Name (e.g. Community Funding Initiative)

— Budget cycle (e.g. Monthly)

— Budget amount (e.g. 4,000 DAI/month)

• All accounts will withdraw from the vault and cannot be individually funded. Updating the budget will be protected by an organization role.
• Accounts cards will display amount spent and budget remaining per cycle.

Another possible solution, which may make the experience even smoother, is enhancing the current Finance app within Aragon to provide segmenting capital by accounts. Autark’s initial application development approach was to develop new apps, but now that we are a Flock team and have had a year to reflect, we think that this is a use case where the experience would be more seamless if both single party and multi-party financial allocations were managed in a unified app.

Special thanks to:

Luke Duncan for testing That Planning Suite on Rinkeby before anyone else and finding interesting bugs.

Brett Sun for his thorough code reviews (I’m sure more are coming).

Aragon Nest for giving us our wings.

Aragon One for building a pretty killer SDK.

ANT holders for funding AGP-19.

INFURA for making it really easy to pin our hashes.

Stay tuned for more in the coming days on how to start adding our apps to your Aragon DAOs…

Image credit: John Schoenherr