On 2014-09-21 09:51, Pine W wrote:
Thanks, but I'm looking for something that is more
specific to MediaWiki
and that commits development teams to specific, standardized, and
transparently measured quality metrics as products advance or regress in
their path to production release.
Yes I would be interested to know about that, too. In case there are
none yet:
Any ideas what those metrics should be?
The only really useful one I can come up is open bugs that are marked
with keyword "code-update-regression" after a certain amount of time of
it being available for public testing. (Currently there are 60 of those,
not all of them on Wikimedia sites:
https://bugzilla.wikimedia.org/buglist.cgi?keywords=code-update-regression&…
)
These are more for software maintenance quality than directly for end
user quality:
Code coverage of unit tests over a certain percentage.
Amount of use cases (or user stories) that have integration tests that
can be run directly against an unmodified installation over a certain
percentage.
Perhaps certain limits on metrics generated by tools like phpdepend.
Perhaps being clean of certain phpmd or PHP_CodeSniffer tests failing.
Is there interest in committing to only deploying in production if any
metrics are met?
(Obviously there needs to be a way to have a grace period for code that
was already on the way to deployment before that was decided.) For the
software quality metrics it probably makes sense to already enforce them
before merge instead of before deployment.
I know requiring unit tests was discussed in the past, anyone remembers
where and what the result was?
--
Regards,
Jan Zerebecki