Code Health Group/projects/Code Health Metrics/meeting notes/20180921


Code Health Metrics Working Group - 20180921

Attendees: JR, Guillaume, Piotr, Željko


Next Steps:

* What are our next steps?

** Zeljko: try sonarQube?

** Guillaume: need to define what we want to measure and how we want to report out the findings.

*** JR: Different audiences different ways to report.

*** Guillaume: have the metrics show up in gerrit.

Criteria for a tool (out of the box support or easy to add ourselves):

* supports the languages / stacks that we use (PHP, JS, scala, java, ...)

* supports reporting metrics over time

* supports collecting metric on changes, not on the whole code base

* integrate with gerrit, at least as a bot commenting on task, ideally as a reviewer, leaving comments per file / line   

* Existing Code Metrics

** in place

** attempted

* Prospective Code Metrics

** Simplicity

*** Cyclomatic Complexity / Cognitive Complexity (per method / class)

*** Unit test branch coverage (implies a good identification of unit tests vs larger tests, max time per test is a possible way)

** Readability

*** various linters

** Testability

*** Mutation coverage (not strictly about testability, but about quality of tests)

** Buildability

** ?Maintainability/Operability?

*** Tech Debt Ratio

Approach to working as a group:

* although we may come to some conclusions during our sync up meetings, we felt it made more sense to finalize our decisions async, that way if people aren't able to make the meeting, they can be part of the discussion and decision making process.  We will track/communicate decisions via the Code Health Metrics wiki page.  

* we will work mostly async using our meetings to sync up and work through things that require synchronous problem solving.  We will have another meeting next week and then decide the cadence we want in the future and during of the meeting (stay at 60 min or reduce to 30).  

* we will start actively using code health mailing list as well as Code Health Metrics IRC channel.  

* we will use Phab project to manage our activities and track discussions accordingly.

Pending Decisions:

* We think that Unit Test Branch Coverage is a good first metric.  Valuable metric that most would agree is important.  Kunal, please share your thoughts.

Q: Do we need metrics in every Code Health area?


*JR: to create Phab project/board/etc...

* pick a tool (,,,, phpmd...)

* pick a metric (branch coverage...)

* pick a repository (core, reading web...)

* pick a reporting strategy (bot leaving a comment in gerrit...)

* JR will add all members of the working group to the mailing list

* Piotr will create IRC channel (#wikimedia-codehealth?)