Skip to content

Develop plan for metrics on the utility/impact of boxo #203

@BigLep

Description

@BigLep

Done Criteria

There is a credible plan for how we'd measure the utility and impact of go-libipfs, especially compared to the previous status quo of many smaller repos

Why Important

This endeavor of consolidating repos (#196 ) is not free by any means. @ipfs/kubo-maintainers hypothesize it will:

  1. Make it easier for users to create tailored IPFS solutions because there is a set of dependencies that all work together with working examples.
  2. Reduce maintenance burden for maintainers because they can make important refactors that have been cost-prohibitive in the past due to the repo sprawl

This should be verified.

Notes

The work of setting these metrics up will likely occur in other issues.

At the minimum, metrics that we'd want to see as a result of this:

  1. Number and derivative of dependent projects on go-libipfs vs. the set of ipfs/go-* repos that have been copied in.
  2. Number and derivative of meaningful contributors to go-libipfs vs. the set of ipfs/go-* repos that have been copied in.
  3. Issue / PR response and resolution times in go-libipfs vs. the set of ipfs/go-* repos that have been copied in
  4. Reduction in average time for a PR to be merged.
  5. Increase in release cycle frequency.
  6. Code coverage % increase

The ipfs/ecoystem-dashboard will likely be relevant here.

Metadata

Metadata

Assignees

No one assigned

    Labels

    topic/project-managementItems related to organizing and managing this project well.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions