RC/metrics proposed

This is an extract of the email recieved from SOSCO on metrics:

levels of defects currently open/being raised/being closed per component per time period T (NB will all defect fixes correspond to a Bugzilla entry, or will it be possible to submit fixes without a defect report?)
# of lines of code changed per time period T
time taken for submissions to be accepted into the codeline
defect turnaround times
test code coverage stats
test results (at all levels, from what testing has been done on each defect fix or contribution, to package- and system-wide tests) (Related question: will the SF test team be writing system tests, or will they just be running whatever tests have been contributed by the community?)
setup + run time for tests, plus hw or sw dependencies needed to run the tests
predictions of the size of code changes planned for any Symbian^N release
known and planned BC breaks
static analysis results
build results
KPIs stats - speed and memory (ROM/RAM) performance
Stability metrics (mean time between crashes)
quality reports from package owners

This is a list from Philippe Lemoine as posted on the SF developer's forum

code: code churn
build time => measure and track how long it takes to build, in order to set a long term goal to have several build a day
integrated contributions => activity monitoring
build success rate => input control
dev env installation at developper side => KPI
rejected contributions => input control, likely focused on "rebase" quality
test time => availability time of dev env
test system uptime => make sure testing can happen whenever needed
test execution time
test results pass rate => quality of contributions
test coverage => quality

Comments