For initial github integration we need a way to handle Oauth and interact with issues. We need at a minimum the ability to list issues, and edit issues.

When running coverage in travis I'm getting the following error:

Running: truffle test  
(this can take a few seconds)...
Error: Could not find @aragon/os/contracts/apps/AragonApp.sol from any sources; imported from /home/travis/build/Giveth/planning-app/apps/range-voting/coverageEnv/contracts/RangeVoting.sol
    at /home/travis/build/Giveth/planning-app/node_modules/truffle/build/cli.bundled.js:63855:23
    at /home/travis/build/Giveth/planning-app/node_modules/truffle/build/cli.bundled.js:166927:16
    at next (/home/travis/build/Giveth/planning-app/node_modules/truffle/build/cli.bundled.js:179668:18)
    at /home/travis/build/Giveth/planning-app/node_modules/truffle/build/cli.bundled.js:63843:7
    at /home/travis/build/Giveth/planning-app/node_modules/truffle/build/cli.bundled.js:203406:5
    at /home/travis/build/Giveth/planning-app/node_modules/truffle/build/cli.bundled.js:179573:16
    at replenish (/home/travis/build/Giveth/planning-app/node_modules/truffle/build/cli.bundled.js:166897:25)
    at iterateeCallback (/home/travis/build/Giveth/planning-app/node_modules/truffle/build/cli.bundled.js:166887:17)
    at /home/travis/build/Giveth/planning-app/node_modules/truffle/build/cli.bundled.js:166927:16
    at ReadFileContext.callback (/home/travis/build/Giveth/planning-app/node_modules/truffle/build/cli.bundled.js:203402:14)
Cleaning up...

Issue is to get it so that - TASK=coverage can be added to the travis.yml file.

See the UI work here #37

This epic encompasses the issues related to allocating bounties to issues in a bulk-fashion.

Members of the DAO will be able to create a standard Yes/No vote for a bulk-bounty allocation. They would multi-select issues in the Issues tab, select the Allocate Bounties button and then map the associated bounty sizes.

A Manage Bounty Values / Settings UI will be utilized to associate bounty sizes with token amounts.

Review specs

https://github.com/aragon/aragonOS/blob/docs/docs/aragonOS.md#7-aragon-app-development-guide

Token holders will be able to prioritize Github issues. New Issue Curation votes are launched via the Tools tab, assuming the user has gone through the range wizard and created the issue curation voting module.

Review spec

Here is an initial starting point for a basic registry. This contract needs to be adapted and turned into a full Aragon app (with a barebones UI) that supports the input fields in the invision.
https://github.com/aragonlabs/registry/blob/master/contracts/RegistryApp.sol
https://projects.invisionapp.com/d/main#/console/14049654/292530913/preview

For this use case we need to store:
Name, Address, and type.
For type I would use an enum, the key for the registry entry should still be a bytes32(this will be a hash of the name) and then the address is an address.

For the general app strucutre I would follow along with the general structure of the tutorial. https://hack.aragon.org/docs/tutorial.html
Just a simple text entry field that emulates the side-panel should be fine for a starting point.

Pretty self explanatory, should have tests along with it.

This epic relates to a series of tickets for implementing the Payout Engine. The scope entails fine-tuning the front-end to be inline with the designs, in addition to integrating into the blockchain utilizing aragon.js.

To understand the payout engine, first become familiar with the range voting wizard specs, as the range wizard is the tool used to create a payout engine tool/app, which spawns payout engine votes.

Review the payout engine specs after the range voting specs.

In order to get the smart contracts talking to the UI all we need is a simple file that simply listens to the events we defined and builds our application state

This task covers creating the event listeners and ensuring that transactions can be initiated in the UI, and the appropriate events are caught and added to the front ends state.

Review specs

We need an icon that looks similar to add:
https://ui.aragon.one/icons/

It should be a grey circle with an x. Used for removing options in range voting applications, during the "create" flow. But this will likely be used across many other aspects of Aragon apps.

• #717171
• 22px by 22px
• svg

Can use this for now: https://www.dropbox.com/s/g8g8w75vcbehr9l/remove.svg?dl=0

Within the current structure of the aragon application we need the ability to interact directly with the github API. Ideally, this would happen through and event based intermediary much as aragon.js is handling web3 transactions.

This is where we actually need to pass the data out of the contract. It will be necessary to bundle all of the candidate data into bytes and pass them out this way. Full testing should also be written. This should be towards the end of the work on RangeVoting when we've got a lot of design done for the PayoutEngine contract.

Need ability to:

• see what the current results are
• see how I voted
• change my vote

In the Planning app, an Issues tab will display all open issues for projects that belong to the DAO.

Review specs

Any research needed to figure out the best approach for non-web3 based middleware for our application and the initial setup of getting the non-web3 based middleware to handle rxjs based state changes from the AragonUI should be handled in this issue. More clarity on this task is needed but once this task is completed there should be an initial javascript file outline for the full epic and a clearly documented design pattern for all non-web3 state handling.

In order to get the smart contracts talking to the UI all we need is a simple file that simply listens to the events we defined and builds our application state

This task covers creating the event listeners and ensuring that transactions can be initiated in the UI, and the appropriate events are caught and added to the front ends state.

In order to get contributors started, we need to develop the README.md so that there are sufficient directions to get the application running and then layout a CONTRIBUTORS.md file that outlines the expectations of all pull requests and general guidelines for contributors.

Implement the function and write the tests. Main difference with our implementation is we use an array for support values. Some testing on the maximum depth of our candidate array should also be done here and we should impose a limit to make sure we don't run into situations where it's impossible to vote. That would be like.. really lame.

This should be handled by implementating the _vote function.

The Overview tab of the Planning app is where the user can connect a Github repo, which generates a “Project” within Aragon.

Review specs

A lot of the functions are unchanged from their implementations in the original voting application. For this issue mainly just port over and groom the tests from the aragon-apps repository. I like the way Chai reads, open to opinions on how we're going to write tests. If we don't conform to the way Aragon does it this task is more complicated but as long as we're using a consistent approach I don't really care what it is.

The MVP design of the Planning App to support the first sprint.

For now, after the user goes through the "Range Vote Wizard" (#18), the new voting object created by the user will be displayed on the Planning App landing page. As we iterate through the sprint, this Planning app will have tabs and additional features.

Icon for the left panel: https://www.dropbox.com/s/buaf4zst55u0fqk/planning.svg?dl=0

See here for the spec/design: https://docs.google.com/document/d/1_GWvbtQSfrXkGxktUAHZ8ONaL1M4JJhUkzPi-GVQbic/edit#heading=h.e2a4np1958gd

Currently there's an issue with mixed line endings in Solium, if we fix this problem we can update to the newest version of solium.

duaraghav8/Ethlint#173

This requires that solium issue 173 gets cleared.

Translate the UML diagram into an interface for the range voting smart contract and then comment all the functions.

Create New Payout

Execute Payout Vote

Both functions should return data.

getVote simply splits all of the data elements out of a vote struct and returns the individual values.
* param: _voteId The ID of the Vote struct in the votes array

getVoterState allows a user to get the vote weights for a given voter.
* param: _voteId The ID of the Vote struct in the votes array.
* param: _voter The voter whose weights will be returned

This issue should be accompanied by tests.

This epic handles all the smart contract design work for the PayoutEngine component.

The basic idea with the payout engine is to be able to take in a payment (in tokens or ether) and then distribute it out to a series of addresses. We use the RangeVote in our use case to “set” the distribution. Since this is going to be a single application we’ll need to have an array of different payouts. Each payout will have an ID that relates to a single payout. In order to work with the RangeVote all we need to do is connect an ACL role to the function that “sets” a payout. We also need a way to put funds into a payout. It would be possible to setup the PayoutEngine so that you could “pre-load” it but for the initial use case all we need is to create a pass through. The user story looks something like this:

A DAO creates initiated a distributed payout which forwards a vote to RangeVote to determine how a budget will be set.

Depending on how the vote is setup elligible voters will cast their votes. Once the vote expires somebody can call the external function executeVote()

The RangeVote will call _executeVote() which calls runScript passing the results of the vote as input to runScript

The PayoutEngine needs to have a function that receives the runScript input.

Once the payout distribution has been set there needs to be a way to authorize the PayoutEngine to distribute ether or tokens based on the distribution that was previously set.

For ERC20 this means that there needs to be a push/pull mechanism. For Ether, ERC777 and ERC721 this can all be handled in a single function.

There are still some questions with how the vault is going to be handled in it’s final form so we should watch the repo and circle back on this. To start we’ll implement just the Ether functions. The other implementations should be pretty close to the ether implementation.

So our functions will look like this:

function startPayout(string[] _candidateKeys, address[] _candidateAddresses, string _metadata ) external auth(START_PAYOUT_ROLE) returns(uint256 payoutId)

This is the function that setups who the candidates will be, and where the funds will go for the payout. This is where the payout object needs to be created in the payouts array.

function setDistribution(uint256 _payoutId, string[] _candidateKeys, uint256[] _supports) external auth(SET_DISTRIBUTION_ROLE)

This is the function that the RangeVote will call. It doesn’t need to be called by a RangeVote but for our use case the “SET_DISTRIBUTION_ROLE” will be given to the RangeVote.

function runPayout(uint256 _payoutId) external payable

This function is how a payout is used. When ether is fed into the runPayout function it’s sent out based on the distribution that’s been set.

In order to get those functions to do their thaaaaang we’ll need the following data structures:

struct Payout{
	string[] candidateKeys,
	address[] candidate addresses,
uint256[] supports
}

Payout[] payouts

All in all I think this will be a pretty straight forward contract. It does something simple and it does it in the most versatile way possible. Additional runPayout functions will need to be added for different token types but again this needs to wait on the vote.

We need a basic UML diagram for the range voting application.

This should be fairly straightforward. Since it's a single contract we just need one class diagram. As we build more of the class diagrams we will begin to aggregate them into a single UML diagram. We can also include the Aragon elements we're interacting with in that chart but this isn't a priority.

We can use https://www.draw.io/ unless somebody has something else they prefer. I've used https://sketchboard.io/ as well but personally prefer draw.io but will go with whatever people prefer. Open to other suggestions as well.

https://www.draw.io/?state=%7B%22ids%22:%5B%2218AeUPYwlAFtiO43ZmjwJTluWyS4aqnvY%22%5D,%22action%22:%22open%22,%22userId%22:%22115872595772615656010%22%7D#G18AeUPYwlAFtiO43ZmjwJTluWyS4aqnvY

This is an incredibly simple one, almost all of the code will be the same as the standard voting application. Should also have full tests (which can also be ported).

The front-end of the range voting wizard needs to be trued up to match the designs.

Review specs

canExecute is used to check that the participation has been met and the vote has reached its end before the execute function is called.
* param _voteId: The ID of the Vote which would be executed.
* return True if the vote is eligible for execution.

_minParticipationPct is percentage of voters that must participate in a vote for it to succeed (expressed as a 10^18 percentage, (eg 10^16 = 1%, 10^18 = 100%)

This issue should be accompanied by tests.

This UI component will be needed for range voting applications.

A user should be able to click a "+" icon to add options.

A user should be able to click an "x" icon to remove previously added options.

The repo should follow the same sub-directory structure used in the aragon apps repo, this will also require changes to the npm run scripts and the travis integration flow. This task should be completed before we setup and start on the Payout Engine application.

There is also cleanup needed in porting the test-helper scripts over from the range-voting/test folder over to the shared folder. In addition the evm script helper needs to be added back into the test-helpers.

https://github.com/lerna/lerna

If somebody else wants to do this that would be awesome as I have no idea what I'm doing.

function startPayout(string[] _candidateKeys, address[] _candidateAddresses, string _metadata ) external auth(START_PAYOUT_ROLE) returns(uint256 payoutId)
This is the function that setups who the candidates will be, and where the funds will go for the payout. This is where the payout object needs to be created in the payouts array.

The tools tab is part of the planning app, and where the range voting objects live.

Review specs

The purpose of the range voting wizard is for the user to create a range voting object (such as the payout engine) but for the user to only enter some of the more "complicated" parameters once. Then later the stakeholders can utilize an instance of the range vote without having to enter the same data every time.

To be completed:

• How many transactions does one need to sign to deploy the new range voting object
• Ability to name the voting object. This will then add the voting object to the DAO's "planning tool box" for reuse, without having to go through the wizard. (or should it get added to "apps"?)
• Alternate designs when the user selects non-token transfer outcome (e.g. skip the address/name screen)
• Come up with better strings / helper text / labels / descriptions
• Incorporate the quorum requirements from quazia's spec

Refer to this for the latest specs & designs: https://docs.google.com/document/d/1_GWvbtQSfrXkGxktUAHZ8ONaL1M4JJhUkzPi-GVQbic/edit#heading=h.tg1pdihqii7a

Work Completed

• Create react folder structure and sort out needed dependencies.
• Set up npm i -> npm start workflow so new devs can easily start contributing to the front end
• Create start page that displays aragon-ui components, illustrating that the react and aragon-ui libs and deps are installed and running correctly.
• Write a readme laying out the installation instructions and the component design guidelines

Testing Needed

1. Pull the branch
2. Follow the README in the range-voting/app folder and ensure contribution guidelines are comprehensible
   2a. run npm i and npm start from the range-voting/app directory.
3. Your default browser should pop up displaying an aragon-ui app bar component containing a login button