Change Details

##Description Currently the triggering of implementation-ordering updates is too conservative. That is, some situations that should trigger reordering, such as creation of a new implementation, are not doing so. Make it more "aggressive" by triggering the update when //any //result comes back live, rather than //all //results coming back live, as it is now. This should be done in conjunction with T330698, to help maintain a balanced strategy (so that reordering only occurs when it's well justified). **Desired behavior/Acceptance criteria** * [ ] Creation of a new implementation or a new tester should consistently trigger implementation-ordering. Note: this doesn't necessarily mean that Z8K4 will always be rewritten, but log messages should be checked to make sure that a new ordering is //considered //in each case. --- ## Completion checklist * [ ] Before closing this task, review one by one the checklist available here: https://www.mediawiki.org/wiki/Abstract_Wikipedia_team/Definition_of_Done#Front-end_Task/Bug_Completion_Checklist

##Description Currently the triggering of implementation-ordering updates is too conservative. That is, some situations that should trigger reordering, such as creation of a new implementation, are not doing so. Make it more "aggressive" by triggering the update when //any //result comes back live, rather than //all //results coming back live, as it is now. This should be done in conjunction with T330698, to help maintain a balanced strategy (so that reordering only occurs when it's well justified). This is a specific solution that could be applied to T330956, but let's keep T330956 open for further possible revisiting, after launch **Desired behavior/Acceptance criteria** * [ ] Creation of a new implementation or a new tester should consistently trigger implementation-ordering. Note: this doesn't necessarily mean that Z8K4 will always be rewritten, but log messages should be checked to make sure that a new ordering is //considered //in each case. --- ## Completion checklist * [ ] Before closing this task, review one by one the checklist available here: https://www.mediawiki.org/wiki/Abstract_Wikipedia_team/Definition_of_Done#Front-end_Task/Bug_Completion_Checklist

##Description Currently the triggering of implementation-ordering updates is too conservative. That is, some situations that should trigger reordering, such as creation of a new implementation, are not doing so. Make it more "aggressive" by triggering the update when //any //result comes back live, rather than //all //results coming back live, as it is now. This should be done in conjunction with T330698, to help maintain a balanced strategy (so that reordering only occurs when it's well justified). This is a specific solution that could be applied to T330956, but let's keep T330956 open for further possible revisiting, after launch **Desired behavior/Acceptance criteria** * [ ] Creation of a new implementation or a new tester should consistently trigger implementation-ordering. Note: this doesn't necessarily mean that Z8K4 will always be rewritten, but log messages should be checked to make sure that a new ordering is //considered //in each case. --- ## Completion checklist * [ ] Before closing this task, review one by one the checklist available here: https://www.mediawiki.org/wiki/Abstract_Wikipedia_team/Definition_of_Done#Front-end_Task/Bug_Completion_Checklist