Page MenuHomePhabricator

Define a code health metrics reporting approach/strategy
Open, NormalPublic


Having metrics is one thing, but without them having visibility it's mostly pointless. We need to define an approach to making sure the metrics are visible/accessible to various users.

We'll need to capture some of the users/use cases. This will allow us to investigate different options.

For example, developers would benefit from metric information during their development activities at the change level. One approach would be to have the CI provide metrics/feedback upon commit.

Other users may be engineering managers who are perhaps more interested in overall trend of a repo.

User/Use Cases:

  • Developer: In-flight feedback regarding code health upon commit. Upon committing a change, the developer should be made aware of code health for their changes plus.
  • Code Steward: Overall code health for the extension, service, module that the Code Steward is responsible for. The code metrics will likely initially consumed from Code Steward dashboard that includes non-code health metrics.
  • Engineering Manager: Trending and baseline code health metrics to measure impact of improvement initiatives.
  • Release Review Process: Those involved in the review process for initial deployments to production. They will need to check status of code health pre-deployment.