On 2014-09-21 09:51, Pine W wrote: 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