-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Community Management] Implement nb of members graph (backend) #11152
Comments
@John-44 in the description I wrote "Only the owner node needs to aggregate that data", but I want to confirm if that's correct. Should Admins also show the graph? If so, they'll have to aggregate the data too (simpler than sharing the data over the network IMO) |
@jrainville this graph should be visible to all Admins and TokenMasters of the community (they all have access to the community's admin area), in addition to the Owner. I suppose the way to do this would be for the Control Node to aggregate the data, but this data would also then need to be sent to Admins and TokenMasters so that they can access the data when the Control Node is offline. It's fine in the data only extends to the last date the Control Node was online e.g. if the Control Node has been offline for 7 days, the Admins and TokenMasters should only see the data up until the point he Control Node went off line (in this scenario the data the Admins and TokenMasters would see would end 7 days in the past) |
@jrainville Is it planned for messenger team to implement it end-to-end? |
As discussed with @alexandraB99 , as was planning for our team to do it end to end, but since it seems you're already doing part of the Overview page and are willing to help, then yes, I'll agree to the help. If you can first start by finding which types of graphs are available in the component for now, it will help decide which of the three graphs we'll do. Then, you can create a new issue to do a mocked UI. Thanks. |
@jrainville We have out of the box support for Here's the supported chart types: https://www.chartjs.org/docs/2.9.4/charts/ |
We decided to go with the Messages per month graph, since we already have all the data available. We'll just need a query to get it |
UI task: #11440 |
* feat: proposal for collecting community metrics status-im/status-desktop#11152 * feat: collecting community message metrics with test * feat: implement both strategies for fetching community metrics * fix: review fixes * fix: calc counts for timestamps
Description
This task is to implement one of the graphs in the Owner's Commnity Overview view.
You have to do ONE of the three graphs. Choose the simplest one.
There is:
Nb of Members over time
Messages per month
Control node uptime
Design https://www.figma.com/file/17fc13UBFvInrLgNUKJJg5/Kuba%E2%8E%9CDesktop?type=design&node-id=29648-618516&t=iOq5Q8V0ftXMj4qM-0
Again, choose only one of the three, the simplest one. The graph component should already exist, ask the Wallet team where it is, how it works and what type of data it supports. If we only support line graphs for example, then we'd better do the number of members.
We currently do not store any historical data, so you'll need to implement that in status-go. The Owner, TokenMaster admins and Admins all have access to this information.
The best way to do it would be for the Control to aggregate the data and share it with the admins.
Of course, no personal data needs to be saved, only numbers and dates.
Also, ignore the bottom of the graph, it is not part of the scope. (the part where you can select the time frame to choose)
If doing the top part (time selector for 1H, 1D, 7D, etc) is also harder and/or not supported by the current component, do not do it.
The goal of this task is to populate the Overview screen so it's not as empty, while keeping it as simple as possible
Acceptance Criteria
The text was updated successfully, but these errors were encountered: