-
Notifications
You must be signed in to change notification settings - Fork 17
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
Feature: Ensure we have opt-out metrics for all of our projects #105
Comments
Great to see this initiative. For web-ui, will we able to differentiate between https://webui.ipfs.io/ and the webui that is bundled in Kubo? |
I hadn't planned to do that work with this initiative but I'll add an item under webui. See ipfs/ipfs-webui#2074 |
@SgtPooki @tinytb : a few thoughts before this rolls out to more places:
|
@BigLep @tinytb @SgtPooki any chance we could get https://check.ipfs.network/ (https://github.com/ipfs-shipyard/ipfs-check) added to the list of things we should have metrics for? Metrics here could be frontend, backend or both but generally serving the same point of showing how these resources are being used. |
Answered in ipfs/public-gateway-checker#309 (comment) but #125 has the most up to date information. Regarding metrics breakdown. We will also be moving to more of a modal view (see #340). These updates will be in effect before adding to other projects (except companion, but companion will have a breakdown)
Absolutely.
This is a great callout but may not be in for initial launch. We need to tread carefully with metrics we send about usage not related specifically to the app, and ensure things are in place to prevent tracking pageUrls with(or without) CIDs, so that's my main focus for initial opt-out metrics release with companion. I'll create a section in the metrics collection notion doc (link will be provided in #125 shortly) to address this. The most difficult problem is getting opt-out metrics in place and ensuring users are aware of our changes. Once that is done, modifying the type of metrics we send can be done fairly easily; though it will still require updating documentation about metrics sent for that project. |
Do you have a countly account? We don't technically own ipfs-check (though maybe we should) and so if no one on our team will be viewing the metrics and generating reports it won't benefit us much. I will add it to the list but my primary focus is getting metrics for the following ignite team projects:
And then ensuring desktop & webui are switched to opt-out. |
@SgtPooki : I'll read/watch #125 as it sounds like that's where more of the action is on specifics. I do think we should add IPFS Check (and pl-diagnose) to the list and just use Ignite's account. You could say that the "owners" should do it, but they don't really have team ownership. Getting the metrics in place heps give clarity on whether we should invest more in them, and if we invest it likely makes sense for it to happen in Ignite (accompanied with increasedresourcing or adjusting other priorities). They can be lower on the list, but given diagnostic tools are the kind of things we believe users across implementations find valuable (and that they reduce the burden on core maintainers) taking the 1-2 days to measure usage I think is worth it. |
note that telemetry documentation is merged and #125 closed. Please open an issue on ignite-metrics if there or questions/comments! |
re-arranged priority of projects according to ipfs-shipyard/ignite-metrics#32 (comment), and removed ipfs-share-files cc @tinytb |
In order to get metrics applied to our non-vital projects, I'm going to move forward with enabling the metrics and creating a backlog task for adding the UI treatment (toggle UI) to those projects. This will help us prioritize getting the numbers we need, while still allowing users to opt out (instructions should be provided in the backlog tacks for adding the toggles). |
PR is out for adding telemetry to starmap project: pln-planning-tools/Starmap#272, but dependent upon some updates to ignite-metrics |
Status update: A Dashboard with existing metrics can be found at https://pl-strflt.notion.site/IPFS-Ignite-Metrics-Dashboard-dee2ada6225e4e01a172673496851210 There is a callouts section on the dashboard page to indicate the current state, but here is a recap:
This comment will also be added into the description |
📣 All IPFS Ignite team projects have opt-out metrics added, and are released. We’re still waiting on updates to ipfs-companion in the chrome store, but ipfs-companion has a new release: https://github.com/ipfs/ipfs-companion/releases/tag/v2.21.0 and is currently available via firefox. ipfs-webui has been released - https://github.com/ipfs/ipfs-webui/releases/tag/v2.22.0 we're waiting on Kubo to merge update of latest webui version: ipfs/kubo#9597 What metrics don't we have yet?
When will we have all of our metrics?
|
status update:
|
marking this as blocked because the only remaining action item is to confirm that the ipfs-webui-kubo metrics are showing properly once a kubo release is made: ipfs/kubo#9502 |
we're getting metrics from kubo webui now: https://countly.ipfs.tech/dashboard#/63c596762a7760344a6b2cfd/. Something is up with metrics in countly though.. when I just logged in they prompted me for 2FA, so i'm assuming the authentication for the robot client needs something as well |
eta: 2023-01-31
Follow #125 for a list of the metrics that should be implemented within each project.
Tasks
The text was updated successfully, but these errors were encountered: