bitdao-io / bitdao-governance Goto Github PK

Bug Description

When a user has a 0 bit balance and has 0 tokens delegated to them, the Buy Bit modal should appear

Steps to Reproduce

1. Connect to the website with a user with 0 bit and no bit delegated to them

Current Behaviour

Getting Started Modal appears

Expected Behaviour

Buy Bit modal should appear

##Additional Information

Feature Description

Currently, the delegate page and landing page are split across repos and each has their corresponding web stack.

As part of our strategy to coalesce towards a unified web stack, determine next steps towards achieving a simplified tech stack, e.g., vue vs react, if mui, no react alone.

Voting Modal should not persist if user delegates their balance to the 0 address (IE undelegates). Persist the "Getting Started" view instead.

Feature Description

Web3 related code is sprinkled into the front end. This leads to challenges wrt testing and reuse.
One way to resolve is to start separating the js code into its own file within the repo, towards the eventual goal of building a javascript helper library for the smart contract we implement.

Code looks like the following:

const receipt = contracts.methods.delegate(address).send({ from: accounts, gas: 300000 }).on("transactionHash", async (txhash: string) =>

Once the web3 code is separated, it'll be easier to work on issues like #45.

Bug Description

The "Getting Started" modal that is supposed to show only when a connected address has a BIT balance and has not delegated their BIT persists.

Steps to Reproduce

1. Connect to the site with an account containing 0 bit ("Buy BIT" modal showing is a prerequisite)
2. Switch the connected account to an account holding a BIT balance that has delegated their BIT

Current Behaviour

Getting started modal persists

Expected Behaviour

Delegation modal should appear

Feature Description

Currently when connecting to accounts on the delegation page the initially loading modal is not necessarily the one relevant to a users situation. To fix this, I propose a "loading modal" that is used as a stand-in while awaiting all calls for on-chain data to return so that any information displayed is always relevant to the user.

Additional Information

Relevant to #32

1. voting wallet rows ("Bit Balance", "Delegating To", "Current Votes") should be the same size with centered text

2. voting columns should be equally spaced.

3. bit logo next to balance too large - resize down to text size and use HD icon.

Feature Description

On every push and PR merge, we should execute all tests and builds.

Additional Information

Actions:

    - name: Build
      run: npm run build
    - name: Test
      run: npm test

Feature Description

Currently, web3 code is embedded into the front end. Even after separating web3 code into their own library (see #46), there's a need to make UI components available for fast POCs.

In order to componentize web3-related UI components, it's essential to provide a data specification for devs to know how to instantiate the components for inclusion into their POC.

Write up detailed (inputs/outputs) of components to a level of detail that non-front-end engineers can develop POCs.

Examples of components that require such a data specification include:

• leaderboard
• delegation selection (eventually extended with support for ens and other identity providers)
• token counts (bit tokens, delegations, and related derivatives, e.g., fungible bond tokens)

Feature Description

• click on voter to see page for voting history, or voter profile
• we can add achievements or gamification after

Feature Description

As the project grows is a need to split the code in small functions and components to later add small tests we can run on PRs.
(Based on #61 new changes)

• create component using useAddressEns ens domain based on an address
• create components using useEnsAddress to display current address based on an ens domain
• Split useWeb3Modal and abstract provider , account, network and expose the data with import and reuse it on components.
• Create component "loading" (I will provide gif, svg or css to display)
• Add loading component to the waiting actions.
• move each contract method to it own file with better fallback errors.
• Split governance page with small components and reduce the logic.

(next task) When it get done we can jump into creating test + exploring better ways to test Web3 rpc code.

Additional Information

Bug Description

the site doesn't support mobile, so I cannot use it with metamaks mobile or other wallets browsers.

Steps to Reproduce

1. open the site on an small screen
2. Alert: "switch to desktop" or if you resize cut modals on the UI

Current Behaviour

no support for diff screens

Expected Behaviour

Mobile is supported and UI scales for diff sizes
##Additional Information

I believe using main is better because it is a clearer and more common identifier in software.

Feature Description

The current delegate page works with BitDAO's current governance mechanism.

UX improvements are sorely needed. For example, in addition to delegation, which is a required step to vote, users that hold BIT tokens should easily choose who they delegate to (e.g., autopopulate leader address, ens support).

To improve the current state, write a flow for each of:

1. how a user currently interacts with the delegate page
2. improved approach
3. approximate future approach

These flow diagrams will also be informative for asset generative including design, front ends, and UI/JS components.

For the time being, these flows are intended from a UX perspective and somewhat distinct from low-level integrations (e.g., smart contracts).

Feature Description

• add some cool illustrations, doesn't need to stick with the current boring brand (use new fonts, styles etc...) maybe just keep the footer the same as bitdao.io main-page
• little bit more explanation that you need to delegate your votes before you have voting power. Maybe one sentence with a hover over. I think a lot of users still don't get this.

Bug Description

When connecting an account that has already delegated their BIT to the site, the Getting Started modal appears for a few seconds before updating to the Voting Wallet/Delegation modal

Steps to Reproduce

1. Connect to delegation page with an address containing BIT that has already delegated their BIT

Current Behaviour

Getting started modal appears (~2 seconds) then updates to the Voting Wallet modal

Expected Behaviour

Should display Voting Wallet/Delegation modal immediately

Additional Information

This probably has something to do with the ordering of the checks/response time. May be better to have a standin loading animation while waiting to get all information from the chain.

Feature Description

Currently, hex is displayed for addresses, making it hard to identify who an address belongs to, or to choose an identity.

This issue should address two proposed changes:

• show ens names instead of addresses, e.g., leaderboard
• allow ens name entry instead of an address on the delegate page

Perhaps a more compact approach makes sense towards the above:

• js function that, when supplied with an address, returns the ens name
• js function that, when supplies with an ens name, returns the address

Although there may be existing libraries for the above proposed js functions, we need to ensure that the address type/format matches the one currently in use.

If a user lands on the page with 0 BIT in their wallet. Instead of the voting modal, we should display a modal linking to the sushi pool to buy bit (in the style of the getting started modal)

Link to bit-sushi pool: https://app.sushi.com/add/ETH/0x1A4b46696b2bB4794Eb3D4c26f1c55F9170fa4C5

Bug Description

https://bitdao.io/ is not redirecting and certificate is not covering it.

Steps to Reproduce

go to https://bitdao.io/

Current Behaviour

Expected Behaviour

Site load and is secured
##Additional Information

Feature Description

Why?

mui been show to be very painful to work with, as the objective of a framework is to reduce the dev time, after a few days working it it showed to be the opposite, migrated to the last version but the approach to override styles we use is not working and we actually doesn't want that styles, for other side, is a big framework and not point all that work to just use 1% of what it offers. In general doesn't seems to be the tool we need.

Why tailwind?

On their docs they wrote a lot of arguments but the main one to me is utility first and being js framework agnostic.
In that way we can use always the same base for all the projects, create components that look the same no matter if we use react, vue, or anything/nothing.

But we can create our own

Yes we can, but doesn't mean we should, at least not for now. Creating your own css framework is great, but is a really big time consuming and also mostly need to be based on components button that makes part of modal, on a page, etc as for now we don't have nothing specific, no point to do it and tailwind as utility first will match any present and future needs. To work with a team there is the need to have docs also, so mostly the creating of a css framework is a blocker for others to work on the project.

Enough, tell me how

• Install tailwind
• migrate page to use tailwind
• split into smaller components (related #46)
• remove mui
• start with tests

The way I'm planning do the styles of components is creating an easy way to change colors to match subdaos branding, In that way if a new DAO want to just for the project change some colors and his own delegate page will be an small amount of work to setup.

Additional Information

Feature Description

Currently, when metamask publishes a new release, it's up to domain experts to read release notes and then identify whether the release will be problematic with our dapp (delegation).

Problems that have arisen due to metamask release to date include:

• changes in fee structure (e.g., EIP1559)
• breaking changes with hardware wallets (e.g., Trezor)

To solve this, I propose we integrate e2e integration testing with metamask, and also with the hardware wallet provider libraries that metamask works with.

Relevant properties to consider:

• While Selenium is an approach that seems to work in some cases, it relies on UI integration testing that's challenging (e.g., needs to access paths without good identifiers), which isn't what we want to test for.
• Our core need is to test the metamask (js) library with our js-based actions to access smart contract functionality of the BitDAO token.
• This proposal focuses on integrating the metamask js library into an e2e testing framework that calls the relevant metamask functions directly in code.
• The testing framework can be automated to perform tests against the latest 5-10 published releases of metamask (which will include rc versions, final versions, and also some of the past versions).
• Since some of the BitDAO documentation refers to use of the etherscan API, any issues arising during tests from this framework may forewarn dependence on the etherscan approach (assuming that the web3 libraries they use aren't similarly affected).

Relevant links to the metamask library:
https://github.com/MetaMask/metamask-extension/blob/develop/app/scripts/metamask-controller.js
https://github.com/MetaMask/metamask-storybook/blob/master/scripts/metamask-controller.test.js
https://github.com/MetaMask/eth-trezor-keyring
https://github.com/MetaMask/eth-ledger-bridge-keyring

Some links to Selenium-based approaches:
https://github.com/pctripsesp/metamask_bruteforce/blob/main/metamask_bruteforce.py
https://github.com/hongphuc5497/metamask-selenium/blob/main/index.js

Feature Description

This issue is simply a follow up task to update the web code to use the the version digital asset (SVG) repo for building of static pages.

Depends on #48

Feature Description

As recommended by metamask docs https://docs.metamask.io/guide/provider-migration.html#replacing-window-web3 and because we use ethers.js on our template, the best way to go is to use ethers.js in every project to avoid any issues.

one of the main vantages is the native support to ENS https://docs.ethers.io/v5/api/providers/provider/#Provider--ens-methods

Additional Information

related to #57

Bug Description

Blue border sometimes appears around the delegation modal.

Steps to Reproduce

1. Connect to delegation page with an address containing BIT that has already delegated their BIT
2. Click the edit icon

Current Behaviour

Delegation modal pops up with blue border around it (see screenshot in additional information)

Expected Behaviour

Delegation modal should pop up without blue border

##Additional Information

Feature Description

Currently, addresses on the leaderboard are displayed in hex, which makes it hard to identify recognizable individuals that a user may choose to delegate to.

I propose integrating the following identity providers (ordered by decreasing priority):

• ENS
• Uniswap Sybil
• 3box
• DID (TBD)
• Our own identitiy captures (TBD)

Feature Description

Currently, non-code assets (e.g., SVG files, logos, fonts) are sprinkled across projects. E.g., the landing page includes the digital assets, while the delegate page references an S3 bucket (managed by a different team).

In order to establish improved control over our digital assets, place all non-code digital assets in their own repo and version the repo.

This will allow more stable development, testing, and deployment as we produce releases. Products that rely on these assets can then be upgraded at their corresponding pace.

In addition to this repo, this issue also affects the landing page repo.
https://github.com/bitdao-io/bitdao-interface

Feature Description

• click next pages or show more (currently only shows 15)
• button to export all (plus additional meta data like voting history)

Feature Description

Delegate list could be improved to be more user friendly, some of the proposals:

• Integrate blockies for the addresses (helps to identify the row and address better)
• Add a "copy to clipboard" button next to the address, Today is impossible to copy an address to delegate as are shorten, the only way is opening the console.
• Loading states, when fetching data from api or chain a loading state will be helpful to indicate to the user the action worked is just taking more time.
• Inform the user if on the wrong network.
• column "votes" seems confusing, looking like is that the amount of votes a user did, maybe percentages is better than amount of tokens to understand the real "vote power"

Additional Information

Feature Description

• Currently it only counts delegated Votes and not BIT balance
• Allowing both will have complications of double counting
• Research advanced strategy which counts: 1) if you have delegated then your vote power is 0; 2) sum of delegated voting power and existing BIT balance (if not delegated); 3) based on block-height to prevent double voting and vote manipulation.

Bug Description

network is never set, then if you change the network in the wallet the page doesn't update with the new network

Steps to Reproduce

1. connect wallet
2. change from/to mainnet/rinkeby
3. UI doesn't change stay the last data

Current Behaviour

network is not being checked on change

Expected Behaviour

if you change the network the UI need to verify it and recheck tokens for delegation, also if network doesn't match environment need to tell the user to pick the right network

##Additional Information

Bug Description

The landing page currently shows a bar chart for each coin, which is filled to the coin's percentage of the treasury. However, the multiple charts don't make sense, and the coin percentages mean that some charts are filled very little.

This issue proposes having a single bar chart (or an alternative chart) with all coins filled (with diff colours/styles/labels) so that 100% of the chart is filled.

Steps to Reproduce

Current Behaviour

Expected Behaviour

##Additional Information

Feature Description

Currently, we have access to a thegraph service that serves the leaderboard on the delegate page, and relatedly the number of bits that a user has (if this isn't the case, then another issue describing the current architecture should be created).

In order to establish systems that provide information that support upcoming features/products, we should setup our own web3 data feeds.

• Remove person icon from addresses
• add separator between rank and address
• Round fractional delegations to 2 significant digits
• Reduce vertical padding on rank rows