Change Details

Per {T184069}, we were planning to start enabling the constraint violation gadget to all logged-in users, by enabling it for all users whose username starts with **Z** on **March 1st** for a start. But now that caching has been delayed yet again (see T184812), we might have to postpone this. According to [Special:GadgetUsage](https://www.wikidata.org/wiki/Special:GadgetUsage), //checkConstraints// is currently used by 238 active users. And according to [this query](https://quarry.wmflabs.org/query/25099), there are 235 active users (have edited in the last 30 days) whose user name starts with Z. So it looks like if we don’t enable caching, we can expect roughly twice the load from //wbcheckconstraints// API requests. I feel like this could still be okay, as long as we get caching in place before Y (229) and X (114) join the party. But on the other hand, if there’s another problem with caching, pausing the rollout while it’s in progress is probably worse than just delaying it as a whole… Thoughts?

Per {T184069}, we were planning to start enabling the constraint violation gadget to all logged-in users, by enabling it for all users whose username starts with **Z** on **March 1st** for a start. But now that caching has been delayed yet again (see T184812), we might have to postpone this. According to [Special:GadgetUsage](https://www.wikidata.org/wiki/Special:GadgetUsage), //checkConstraints// is currently used by 238 active users. And according to [this query](https://quarry.wmflabs.org/query/25099), there are 235 active users (have edited in the last 30 days) whose user name starts with Z. So it looks like if we don’t enable caching, we can expect roughly twice the load from //wbcheckconstraints// API requests for the first week of the rollout. I feel like this could still be okay, as long as we get caching in place before Y (229) and X (114) join the party a week later. But on the other hand, if there’s another problem with caching, pausing the rollout while it’s in progress is probably worse than just delaying it as a whole… Thoughts?

Per {T184069}, we were planning to start enabling the constraint violation gadget to all logged-in users, by enabling it for all users whose username starts with **Z** on **March 1st** for a start. But now that caching has been delayed yet again (see T184812), we might have to postpone this. According to [Special:GadgetUsage](https://www.wikidata.org/wiki/Special:GadgetUsage), //checkConstraints// is currently used by 238 active users. And according to [this query](https://quarry.wmflabs.org/query/25099), there are 235 active users (have edited in the last 30 days) whose user name starts with Z. So it looks like if we don’t enable caching, we can expect roughly twice the load from //wbcheckconstraints// API requests for the first week of the rollout. I feel like this could still be okay, as long as we get caching in place before Y (229) and X (114) join the party a week later. But on the other hand, if there’s another problem with caching, pausing the rollout while it’s in progress is probably worse than just delaying it as a whole… Thoughts?