Change Details

There are a few concerns in this task. From an instrumentation perspective, we will log information about number of rejected / approved / skipped link suggestions when a user makes an edit. At a more granular level, it would be useful to know which links were rejected. First, so that the algorithm could be improved. And second, from a product perspective, if two users via a suggested edits article and both of them reject link recommendation 1, then user three comes to that article, we probably know that we don't want to show them link recommendation 1.

There are a few concerns in this task. From an instrumentation perspective, we will log information about number of rejected / approved / skipped link suggestions when a user makes an edit. At a more granular level, it would be useful to know which links were rejected so that the algorithm can be improved. The rejected link and the rejection reason will only need to be stored in EventLogging, because the software will not need those details in order to show the user anything. The software just needs to be able to know //how many// links were rejected by the user in a given article. The only exception is the edit summary (T269657), which shows an accounting of which links the user rejected and skipped. For the first version of "add a link", we do not need to worry about showing a second user a link suggestion that was rejected by a previous user. We will rely on the small number of users and large number of articles to minimize collisions. This is something we //will// want to analyze and decide whether to address in the future, so we should plan to be able to query how many articles get re-suggested after receiving rejected links.

There are a few concerns in this task. From an instrumentation perspective, we will log information about number of rejected / approved / skipped link suggestions when a user makes an edit. At a more granular level, it would be useful to know which links were rejected. so that the algorithm can be improved. The rejected link and the rejection reason will only need to be stored in EventLogging, Firstbecause the software will not need those details in order to show the user anything. The software just needs to be able to know //how many// links were rejected by the user in a given article. The only exception is the edit summary (T269657), so thatwhich shows an accounting of which links the algorithm could be improved. And seconduser rejected and skipped. For the first version of "add a link", from a product perspective, if two users via a suggested edits article and both of them reject link recommendation 1, then user three comes to that articlwe do not need to worry about showing a second user a link suggestion that was rejected by a previous user. We will rely on the small number of users and large number of articles to minimize collisions. This is something we //will// want to analyze and decide whether to address in the future, we probably know that we don't want to show them link recommendation 1so we should plan to be able to query how many articles get re-suggested after receiving rejected links.