Skip to content

Q3 2018 Team Update

Yalda Mousavinia edited this page Jul 26, 2018 · 4 revisions

That Planning Suite: Revamped

Whenever we starting working on the Planning app (see original Nest white paper), we assumed that we would be able to build a single Aragon app using multiple interconnected contracts, which would be able to to spawn additional contracts within it. Smart contract development occurred independently without fully taking in the intricacies of the aragon.js architecture, and we didn’t become aware of this technical limitation until very late into our first Milestone.

To accommodate for this challenge, instead of making a single app with a very large smart contract, we had to make design sacrifices and develop a new architecture composed of six total apps (Allocations, Range Voting, Projects, Rewards, Consensus, and Address Book) which we are now calling That Planning Suite.

  • Projects App: Github and Gitcoin integration to pull in issues from the DAO’s github repost. Includes issue curation features and ability to create a Yes/No vote that assigns bulk-bounties to multiple issues.
  • Allocations App: Create new allocations where ETH/tokens can be sent to multiple recipients, and the amount per recipient is based on a range vote. Also includes informational votes that do not transfer value. (This will support the previously name Payout Engine, Dynamic Payout features in this spec)
  • Range Voting App: Perform a range vote on new allocation votes from the Allocations app. (This will support the voting aspect of the previously defined Payout Engine feature in this spec)
  • Address Book App: Ability to maintain a list of Ethereum addresses mapped to human-readable names. These do not have to be members of the DAO’s but can for example be external contractors, grantees, projects, other multisigs, etc. Address book entries will be added after a passing vote from Voting app. Ideally, throughout Aragon it should be able to autocomplete from the address book to fully satisfy the feature, but a clipboard functionality within the Address Book app will provide a temporary solution until autocomplete can become integrated by reading another app. (This will support the Fixed payout feature in this spec.)
  • Rewards App: Distributes 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).
  • Consensus App: An app for consensus-based decision making, especially when it comes to estimating the bounty values of multiple tasks or also to come to consensus on a single value such as a salary or grant amount. (This will support the Bulk Bounties / On-Chain Estimates aka “Planning Poker” features. This may also potentially be supported by an enhancement to the Projects App, without a new app, and will be researched further.)

Roadmap

Based on this architecture, it is going to result in an estimated slip of 16 weeks total and we are requesting additional funding for 8 weeks. This adds an additional 6 week Milestone between 1 & 3, and 2 more weeks to the final close-out milestone. (We are not requesting additional funding for this Milestone 1 delay).

Milestone 1 - 18? weeks [+8]

  • Range Voting App
  • Allocations App v1
  • Projects App (Front-end + Github integration)
  • Kit for Range Voting + Allocations
  • Testnet Deployment: Range Voting App, Allocations App (v1)

Note: The completion of what we call the “Projects App” now needs to partially move out of milestone. Due to the hurdles we ran into, it was impossible to finish this in a reasonable time.

Milestone 2 - 6 weeks [+6]

  • Projects App (Smart contracts integration + finish remaining)
  • Address Book App
  • Allocations App v2
    • Enhanced to include Dynamic Payout allocation type
  • Enhanced kit to add new apps
  • Testnet Deployment: Planning Suite to date

Milestone 3 - 6 weeks

  • Rewards App
  • Consensus App (Front-end)
  • Enhanced kit to add new apps
  • Testnet Deployment: Planning Suite to date

Milestone 4 - 6 weeks

  • Consensus App (Smart Contracts & Integration)
  • Clean up front-end bugs / make pixel perfect all apps
  • Enhanced kit to add new apps
  • Testnet Deployment: Planning Suite to date

Milestone 5 - 6 weeks [+2]

  • Finalize Planning Suite
    • Comprehensive Scenario Testing
    • Fine tune the kit that deploys all apps in the suite
    • Testnet Deployment: Entire Planning Suite
  • Clean up, true up, bug fixes, bug bounties
  • Mainnet Deployment: Entire Planning Suite
  • Enhancement Plan for Decentralized Git Cross-Compatibility (Document)
    • This impacts two apps in our suite (Consensus, Projects)

What We Have Learned

  1. Estimating timelines is hard, especially when estimating how long it will take to build complex, user-facing apps with cross-app forwarding, on top of a new dapp framework.
  2. The architecture of the Aragon wrapper should be enhanced. We had to make user experience sacrifices to work within the architecture. (It will be hard to build products that are adopted en masse unless we ensure that technical architectures can optimize for both security and UX in parallel.)
  3. We should have talked to the Aragon team earlier on when we were making the technical assumptions for how to approach the smart contract design.
  4. We previously were going to use a points system in planning our tasks, so we can distribute 20% of our monthly budget to part-time contributors. But we realized that this method of building software can only work if there is more wiggle room in a development schedule to set aside time to really estimate the effort involved in each tasks, and if we have a really good understanding of how to estimate the effort. Considering learning a new dapp framework and our schedule delays, after a few weeks of using points planning, we transformed into part-timers providing weekly reports of how many hours they worked and did payouts based on that. We think the points method of planning can still work, but that it is probably not best to use when working on projects with tight schedules.
Clone this wiki locally