As outlined in T183927#3894206, while the initial default value of the status parameter of the wbcheckconstraints action is the backwards-compatible '*', we want to do the breaking change to switch it to violation|warning|bad-parameters soon.
|mediawiki/extensions/WikibaseQualityConstraints : wmf/1.31.0-wmf.22||Change status parameter default to cacheable value|
|mediawiki/extensions/WikibaseQualityConstraints : master||Change status parameter default to cacheable value|
This doesn’t feel like something that should be configurable in the extension, so I really don’t feel like going through the whole dance of adding a configuration variable, changing its value in wmf-config, changing its default value, and finally removing it from wmf-config again. Instead, I’d like to do this as a simple code change.
Proposed timeline: On Wednesday, Wikidata moves forward on the deployment train. On Thursday or Friday, we merge a code change that changes the default value for status into master. On Monday, assuming nothing bad happened to the train, we backport that onto the currently deployed branch during SWAT. And next Wednesday, the train moves forward again and includes the non-backported version of the change. This way, we can promise users a single date when this breaking change will happen even if the train has to be stopped or reverted (in which case we just go back from the non-backported version to the backported version, but both branches still contain the change).
@Ladsgroup does that sound okay? (Note that we haven’t announced the breaking change yet – if we do that next Monday, then the above events could happen 2018-02-21–2018-02-28, but we might also need to wait a week longer.)