# DAOhaus Planning (7/11/22)

## Scope Update

- We need time to figure out Core UI items and whether we can get it done within 6 weeks is a good question we should drive from
- How do we want to prioritize things moving into next phase?

## General RFP Proposal Response

- Why does this language specifically not include user facing documentation? The docs we've been writing should be user-facing as we're writing it for our community of users and devs
- What are we considering *tested* and *well-documented* at this point?
- Up to us to determine what testing should be -- working with the larger group (QA team) to determine our coverage
- Do we also want test coverage (such as with Jest)?
- Some of the packages have Jest coverage (SDK) but for most of our apps we'll largely focus on QA testing

## Shipping v3

### Contracts

- Wanting to potentially switch to Foundry which would impact our tests and impact the timeline for the code being ready
- New contract deployed on Goerli
- Deploy scripts are ready
- Would we be able to have the contrcts audited and redeployed within 6 weeks?
- Focus on teams that are within the Moloch Mystics budget
- Should also have some folks battletest the contracts since we may run into things we'd want to change after we begin real-world testing
- Setting up real-world tests should be a priority, but this may be difficult without a full UI
- Could potentially do some light real-world testing via the CLI
- Contract and subgraph work is essentially done other than these real-world battletesting points and MM can look into an audit that fits their budget
- Follow up with MM if they'll cover the costs and then we can follow up with the auditors (2 week lead + 2 week audit + 1 week to make changes + 1 week to deploy) to make the MCON release
- Will need to make users aware that contracts may change and deployed DAOs may disappear depending on changes
- Is there anything we need to be aware of when we change to a self-hosted version of our Subgraph?
- Not specifically a public release yet but this is something to be aware of in 2023 when they sunset the hosted version
- We'll address this when we move toward a full public release after our beta
- Moving off hosted Subgraph services can be part of a second RFP process

### Haus Infrastructure v1

- What additional work needs to be done?
- Subgraph node can be removed as we're deprioritizing this
- As we're building out some of the UI we may want to deprioritize any optimizations that could create a centralization around DH services and infrastructure
- Ceramic is also in flux right now -- they're making large changes to their architecture
- Do we want to deprioritize this and move down the road given that this is the case?
- Can we tap into the new architecture now or do we need to wait?
- Can keep our infrastructure fairly minimal during this stage and only make crucial changes when needed
- We do have some ability to not make DH completely dependent on Ceramic but we may also want to take time to reassess some features to determine how necessary this is, and we can then either potentially cut or deprioritize features that directly rely on Ceramic
- Could we potentially use Poster metadata in certain places we thought we could use Ceramic? Won't have the same feature parity but we could maybe use this for now
- Next step is to go through our other items and see what relies on our infrastructure -- next decision point is the pros/cons of what we want to keep
- Likely will be a larger discussion since we need to look into Core UI features
- Docs on how to spin it up (maybe we keep the docs fairly general)

### Haus Libraries v1

- Do we need to iterate and improve our libraries?
- Iterating on the data fetching SDK and in our commons package since these will always be improving
- How are we considering our feature libraries such as TxBuilder in this? Do we want to think about these as being internal tooling?
- If we build them we should share and release them
- What new feature packages would we want to add? Things will also evolve as we continue to build and dogfood our development
- Every package will be iterated on throughout the buiding process
- What do we want to do with the component library?
- There are a lot of new components added to the roadmap leading into Core UI
- There are a lot of new tickets here (not many details added yet) but we have a better idea of what we need to build to get to the finish line
- Could do a similar process for the SDK, but Commons come up as we build
- Since the feature packages are going to be in our monorepo anyway we should continue to publish and deploy these (and document them) for others to use
- We need to document our ops around deployment and managing our versioning
- Make sure that we capture that all of this is represented -- what do we want to do with our release notes? What's our plan for this now that things are published?
- Create a wiki page for how we are currently managing versions to not break the deployments

## v2

- Release Nomad
- Support third-party boosts coming in from partners and DevRel stream
- Continue to work toward decentralizing the infrastructure
- Replace Airtable with Poster metadata
- How much of a distraction is this from v3 development?
- This does take cycles away from v3 but it's likely not something we can avoid doing
- What about building this onto v3 and then applying the learners back to v2?
- Can we survive the 2 months of burn and move devs to v3 to work on this there? Set up Poster in v3 and then do "surgery" on v2 with more insight?
- Worry that we'd be kicking the can down the road and we currently have momentum here
- Potentially we could move this work to v3 and then have a future RFP for *Decentralizing v2* since v3 seems to be the larger deliverable
- This decision may be a bit more streamlined after we review Core UI scope
- What does DevRel have in their pipeline that would impact v2 in this workstream?
- How do these new boosts impact v2 maintenance?
- Third-parties make the forms/transactions and then core team wire the boosts up into the app which would allow for more granular QA processes

### DAOhaus Apps

- What remains for Summon and Hub beyond the QA pieces we need to resolve?
- More around Hub related to Explore that we need to consider
- Need to scope Core UI and determine what we want to work on
-

## Documentation Site

- Separate initiatives -- are we going to be needed to help with the website development in this cycle?
- What would the timing of the website build be? Would make sense to have a new site *before* MCON but this would impact other things such as dev resources and time
- What additional support is needed for the v3 product docs?
- What is the minimally viable deliverable?
- Having a standalone docs site would be a stand-in for our products

### What's left with Hub Explore

- Remove the Explore section and put the Search into the menu instead of being part of the Hub app
- Should we remove Explore entirely for this release? Would we be providing the best explore UX for this? Also we'd be needing to centralize a bit more to accomplish this
- Search in the nav would be scoped to a user's DAOs but do we need this feature
- Do we want to provide a place for folks to come to DH or would they need to be given a link to a specific DAO
- Could have a *Discover* section where folks indicate via metadata that they'd want their DAOs to be discovered
- Would only require the metadata editing within Core UI
- Could add a search that returns results directly from Subgraph that would then display
- Would return all of this with some simple pagination
- Would only be data that would be available on the Subgraph -- return a few DAOs
- Would need to query across networks and wouldn't necessarily know how many items we'd be returning
- Each search would be scoped to a network (search by contract address or name)
- Explore is a place where folks find DAOs but is this important to the *beta*
- Potentially could also partner with folks in the ecosystem to develop a good Explore experience that we don't need to deliver, but we've been planning on this for awhile
- Could be a good test case for this with our libraries -- spin up a React app and use our SDK to do a "Google search of DAOs"

## Core UI Feature Mapping

- https://www.figma.com/file/9lCwprCNaoAmUDmiMQpFEA/DAOhaus-v3?node-id=5522%3A113968

- Reviewing the Core UI designs and also the larger Discovery process?
- What are the core features we want to include in beta?
- Proposal Details is one of the biggest changes from v2
- All basic proposal information and contract details
- Proposal Status Card: variations based on each status
- Dropdown would include additional information such as who sponsored it
- Settings is a large page but it's a lot of information that's repeated
- Could remove the Proposal Favorites card for now
- Update Settings -> takes to the governance page
- Activity Log may not be necessary for the first release
- Mostly focusing on Proposals UX and UI at this point

### Features

- Hub: Some level of Explore
- Simple search with links to the DAO's UI
- Hub: Profile page PR is up which was the core remaining feature
- Hub: Dragons should develop QA plan to triage the items that have already been identified
- Which of these are UX decisions and which are quick fixes?
- Hub: Search your own DAOs
- Global Nav: Every app would use the DAO switcher dropdown so we need to revisit this
- Implementing this without the Search is a must, but the Search will be pretty useful to have since it's feature parity with how folks use v2
- What other options do we have given some of Radix's limitations?
- Having a Search bar as part of a dropdown is an unfamiliar pattern -- opening a modal may be a better option

### Core Features

- Prioritizing *which* proposals we want to work on first
- Data Display Cards and Tables are core patterns
- Determine effective component library elements that we could reuse
- How do we want to handle tables in mobile? Are we wanting to use the pattern of Cards only for mobile? If so, we'd want to build some factories to handle this
- Do we want to just rely on horizontal scrolling?
- If we scope this to just the table that would work fine for the initial release
- Should we remove the *Vaults* for now and link to the DAO's Safe instead?

### Home

- Tokens are the amount in circulation -- anything that we can grab from the Subgraph (such as symbol and name) since these won't be on something like Coingecko
- Home page is a good place to start and will move us toward building components we've already identified (Indicator for example)

### Proposals

- Spam Filter could be a click to open Modal
- Proposal won't go through if it doesn't pass the spam filter -- things won't show up in spam since it won't even pass, so may not need this
- Searching and Filtering
- Identify what we're searching and filtering on -- we've been aligning on things that we can get from querying the Subgraph so we don't need to rely on extra data caching
- Identify these and align on what we'd want to include in the Proposals page
- Pagination
- Do we want to play with infinite scroll? do we want to do a *Show More*?
- Proposal Types
- 5 core DAO proposals -- do we need to include a Guild Kick proposal?
- Not often used but seems to be a main proposal type that would be used
- Could we abstract this into a proposal that changes shares <-> loot?
- *Adjust Shares and Loot*
- Shamans:
- Can remove from the proposal list and rely on this being in the Proposal Favorites/Shaman section
- Rage on the proposal Types List:
- Multicall -- how do we handle this?
- Multicall and WalletConnect would be the 2 most important to include
- These would allow a DAO to do anything
- May not be apparent to a user that these are able to do anything so we may want to prioritize more direct, straightforward proposal types
- What would we want to prioritize?
- The pre-built basics and multicall was decided based on the overall implementation lift and what folks have used traditionally
- People are used to using the WallectConnect with Gnosis so there would be more benefit to this right away
- Proscriptive, pre-built proposals would help folks get up and running quickly
- If we're going to invest time in Multicall we should focus on doing it thoroughly and allowing folks to build + save + share themselves
- Do we want a simple MVP multicall?
- We should dive a bit deeper on this to determine the UX implications
- **Proposal Details**
- Nothing too different in this
- So many elements that are repeatable, so there is a lot of potential for adding things to the design system and component library
- Difficult to crunch the action data per proposal that needs to be turned into readable UI -- it is a lot if we have to do it multiple times
- If the factory is there and we know it works we could do this
- If we add a title and description to everything (make this mandatory) we have a human-centered idea of what folks are voting on and give them a way to verify
- Never made custom proposal details pages based on the proposal type in v2, but we may want to consider this since each proposal type UI is different
- If we end up having this be a single proposal type this would definitely be streamlined
- What do we still need?
- Gov Settings
- Request Membership/Join (on homepage)
- Funding request (in vault)
- Challenge of not having a modal is that we'll need to think of all the things on each button -- will these be customizable?
- Things that were previously hardcoded would be interchangeable
- Having users do Multicall for every single proposal may be difficult UX for folks who are not powerusers
- Superusers (targetting 10% instead of 1%) as a distinction here
- Getting back into Proposal Types but not the same UI
- Include warnings when users are doing something that can impact Governance or other critical settings
- For initial release we won't include certain proposal types like Disperse but folks can add them in as boosts
- If we're going to use multicall for everything folks may not enjoy using the platform since it'll become quite difficult

### Shamans Form

- Would be manually adding these since we don't have a factory yet
- Form may completely change when we have additional information

### Next Steps

- We have changes for *Vaults*
- How can we make lists as repeatable as possible so that we can build factories for them?
- Individual Profile pages will look toward some of the Hub patterns
- How do we want to handle Rage Quit? This is an important feature we need to represent (how/where does a user initiate a RQ)
- Think more about the form builders
- Review the list during the component library sync and then identify the next steps for each of the issues we want to create components for
- We may be ready to start scaffolding the Core UI app