> Fundamentally broken sounds like a bit of a stretch. A process that annoys people based on nothing but the fact that they happened to be the last one touching a file *is* fundamentally broken. This is not how anyone should look for reviewers, neither manually nor automatically.
Here is a thought experiment: We could send review requests to the *least* active users that are still around, but *never* touched a file. The positive effects of such an approach include: * More people get familiar with the code. * Knowledge gets spread more evenly. * Bottlenecks and bus factors get reduced. * These people probably have more time. * Review requests are spread more evenly. * Workload is spread more evenly. Still sounds like a bad idea? Sure, because it is. Now tell me: How is it more clever to do the *opposite* and dump review requests on people that have to much workload already? At this point I don't care any more if we are talking about a fully automated process or a suggest button. Both are targeting the wrong people. > it was probably working quite well for our less-trafficked repositories. What is the difference between being the last one fixing a typo in a low-traffic vs. high-traffic repository? In both cases it's the wrong person. Thiemo _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
