The session discussed and tried to answer the question: – What metrics are relevant for Qt Contributors?
- Different stakeholders will consume metrics from different places
- Contributors would benefit from metrics when committing, so for example links from Gerrit to pages showing how the commit would affect Qt. Also test results would be useful.
- Contributors would also benefit from test coverage metrics, to show where test coverage is lacking. Either on a general level or on commit level, showing coverage for the code to be checked in.
- Static analysis metrics / comments would also be useful on a commit level.
- Static analysis such as spell checking would be useful for Qt Creator code, for example capitalization checks for dialogs
- Metrics on a general level (such as a metrics page) should include: test coverage per platform, most used parts of the code, most changed files, bugs in components / files
- Get/present usage stats for a set of Qt apps, to show which parts of the code is being used most. Can be useful for Approvers, to help them know importance of performance when reviewing for example
- Integration / release managers would be interested in trends on quality, to help them explain why contributions don’t get “accepted”
- For people optimizing for different platforms, performance metrics on different platform configurations might be useful.
- Social metrics -> Nbr contributors, nbr commits / time, changed parts of Qt / time, top ten contributors
- Start collecting common reasons for contributions being rejected, collect and publish those to help contributors get their code into Qt.
Let’s follow up using http://lists.qt.nokia.com/mailman/listinfo/qt-metrics-feedback