Proposal: delay on autokarma pushes #6020
Description
There's a couple of ongoing discussions - 1, 2 - around some recent problematic updates. Those got me thinking about some potential adjustments to the autopush system.
I proposed a simple one separately. This is a bit more complex, but I think might also be helpful.
My initial thought was a relatively simple flat 'floor time' for autokarma pushes. An update would no longer always be immediately pushed stable on reaching its autokarma threshold; we'd also have a minimum time it had to be in u-t. This would be much shorter than the minimum wait without reaching the autokarma threshold. My initial thought was 24 hours, but the update I cited in the other proposal makes a case for 36 or 48. This would not apply to manual pushes, so we'd still be able to shove hotfixes through quickly with the policy minimum karma.
I think this wouldn't be too hard to implement - we'd just have to move the karma autopush to happen in the same celery task as the autotime push, instead of happening as part of comment creation. In the standalone script that task runs, as well as checking for updates that had reached autotime, we'd check for updates that had reached autopush and also been in testing for the 'floor time' we decided on.
A more complex idea I had later was to have a sort of 'sliding scale' approach. e.g. the default autokarma approach could be one where it starts at 7 for all updates, then be reduced by 1 every day, and we could even allow updates to customize the starting value and 'slide factor' (within the constraints of the policy minimum requirements, of course). But that might be over-egging the pudding, and is probably more complex to implement overall.