Create Roadmap.md #360
Create Roadmap.md #360
Conversation
Open for discussion
Roadmap.md
Outdated
| ## Long-term | ||
|
|
||
| - Types (use Flow or Typescript) because it will allow us to catch more "errors" at compile time, having commands silently fail without noticing (like [this](https://github.com/aragon/aragon-cli/pull/334#discussion_r248659171)) less often. Using Typescript is also great for intellisense support (having auto-completion from IDEs) and refactoring | ||
| - Improve smart contract tooling using new Ethereum dev tools from 0x: |
There was a problem hiding this comment.
Brett: I wouldn't say these are necessarily within the scope of the CLI, but we can explore if replacing truffle makes sense in the CLI (probably doesn't, but we can upgrade to v5) and solidity-coverage in the boilerplates (really hoping this is possible).
There was a problem hiding this comment.
I Been researching about this and the tools are framework agnostic so they can be configure with truffle if we want to keep using it. Here is a basic example: https://github.com/0xProject/dev-tools-truffle-example
Roadmap.md
Outdated
| - `[sol-profiler](https://sol-profiler.com)`: Gas profiling for Solidity | ||
| - `[sol-compiler](https://sol-compiler.com)`: Solidity compilation | ||
|
|
||
| We plan to prioritize `sol-trace` and to look into the benefits that the others tools could have on the developer experience and decide whether to work on that *short-term*. |
There was a problem hiding this comment.
Brett: I'd wait until 0xProject/0x-monorepo#1520 is fixed, otherwise asking devs to spin up a geth node to do this is a bit cumbersome (i.e. I wouldn't bother until I had a failing test that was difficult debug by itself)
Roadmap.md
Outdated
|
|
||
| We plan to prioritize `sol-trace` and to look into the benefits that the others tools could have on the developer experience and decide whether to work on that *short-term*. | ||
|
|
||
| - Identify contracts like the `MiniMeTokenFactory` which do not need to be deployed every time, but rather reused, and publish them to `aragonpm.eth` (just like the `dao-kits`) |
There was a problem hiding this comment.
Brett: Ohh good idea, do we publish this every time on aragon run? We should just hardcode an address in aragen like we do with the root ENS.
Roadmap.md
Outdated
| - Wizard onboarding 🧙♂️ | ||
| - The goal of this tool will be to help new users create a custom DAO | ||
| - "Import" the onboarding of the multisig and democracy kits from the ui client | ||
| - Improve UX for installing "core" apps (e.g.: TokenManager, Voting, etc.), because currently is a bit tricky as you have to check what arguments the `initialize` function takes from the app's contract and pass them with `--app-init-args`, e.g.: `dao install [dao-address] voting --app-init-args 0x00000001 600000000000000000 250000000000000000 604800`. We should do this, instead of the users, so they can see what are the needed parameters with `--help` or `--interactive`. For example `dao install voting --help` could return `dao install voting [dao-address] [token-address] [support-required] [quorum] [vote-time]` |
There was a problem hiding this comment.
Brett: We should be able to do get the initialize function's params from the artifact.json if it's published onto an aragonPM instance
Roadmap.md
Outdated
|
|
||
| - Active on the different dev-related aragon.chat channels. We aim to respond within one day and to allocate ~1 hour each day to debug issues like [this](https://github.com/aragon/aragon-react-kit-boilerplate/issues/19), help people deploy to testnets, etc. | ||
| - Aragen maintenance | ||
| - Prioritize this roadmap |
There was a problem hiding this comment.
Brett: My thinking on priorities:
- Set up some smoke tests with E2E testing (1-2 weeks)
- Short term bug fixes and items (2-4 weeks)
- Docs restructuring (1 week)
- Monorepo refactor?
- Interactive wizards
- Transition to TS
- Other long-term items
May also be good to speak with Autark to see if they have any lingering pains with the CLI (there's one issue with stopping IPFS that's solved by sleeping, but would be good if we didn't end the process until we knew that IPFS was stopped). I don't foresee too many items that A1 will need in the next two to three months which Luke hasn't already brought up.
There was a problem hiding this comment.
Daniel: Thanks a lot for the feedback!!
Is there an issue for that ipfs behavior?
What do you think about open PRs?
@sohkai
There was a problem hiding this comment.
@0x6431346e There's no issue for it yet, but can be easily tested by going between this commit and the one before it: AutarkLabs/open-enterprise@e3178eb.
As for open PRs, hopefully those can go with 1 and 2 :).
Updates after feedback
Open for discussion