Change Details

In {T274325}, we discussed some ideas for quality gates for "add a link", which would be rules that slowed or stopped contributors who are adding many damaging edits to the wiki. We have not needed to implement any of them yet for "add a link". But adding images to articles is a highly impactful and visible edit. That means that a user who is doing a bad job could cause a lot of damage quickly through "add an image". We've seen this through the Wikipedia Pages Wanting Photos campaign, in which most users were being productive, but some generated many weak edits. Discussions at English Wikipedia [[ https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Archive335##WPWP_#WPWPARK | here ]] led that community to limit participants to 25 of these edits per day -- a blunt way to limit a user who is moving quickly. For "add an image", we've had ideas that range from simple to sophisticated. With each of these ideas, we would either stop the users from doing the task, try to re-onboard them, or suggest different tasks. * Quantity: limit participants to a certain number of edits per day. * Reverts: limit participants who have had too many reverts to this task type. * Speed: limit participants based on the average time they're spending on each edit being too low. * Ratio: limit participants based on them answering "yes" or "no" more often than is expected from the algorithm. In Iteration 1, we'll do the simple "quantity" gate, with this rule: **Users may not open a 26th suggestion after having submitted "yes" or "no" responses on 25 suggestions in that day.** * Though both "yes" and "no" count, "skip" does not. * The "day" period should be defined as midnight-to-midnight in the user's timezone. After midnight, it resets. In terms of user experience: * We need to decide what the user sees in the post-edit dialog after they complete their 25th suggestion that day ({T290789}). * We need to decide what happens in the suggested edits feed if the user is viewing it and the difficulty filters after their 25th suggestion that day. Other points: * If trivial, we would like to have the //option// to apply this same logic to "add a link" and the other unstructured task types. * Parameters around this quality gate should become part of community configuration. ** For which task types the gate is active. ** What threshold it should use for number of edits.

In {T274325}, we discussed some ideas for quality gates for "add a link", which would be rules that slowed or stopped contributors who are adding many damaging edits to the wiki. We have not needed to implement any of them yet for "add a link". But adding images to articles is a highly impactful and visible edit. That means that a user who is doing a bad job could cause a lot of damage quickly through "add an image". We've seen this through the Wikipedia Pages Wanting Photos campaign, in which most users were being productive, but some generated many weak edits. Discussions at English Wikipedia [[ https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Archive335##WPWP_#WPWPARK | here ]] led that community to limit participants to 25 of these edits per day -- a blunt way to limit a user who is moving quickly. For "add an image", we've had ideas that range from simple to sophisticated. With each of these ideas, we would either stop the users from doing the task, try to re-onboard them, or suggest different tasks. * Quantity: limit participants to a certain number of edits per day. * Reverts: limit participants who have had too many reverts to this task type. * Speed: limit participants based on the average time they're spending on each edit being too low. * Ratio: limit participants based on them answering "yes" or "no" more often than is expected from the algorithm. In Iteration 1, we'll do the simple "quantity" gate, with this rule: **Users may not open a 26th suggestion after having submitted "yes" or "no" responses on 25 suggestions in that day.** * Though both "yes" and "no" count, "skip" does not. * The "day" period should be defined as midnight-to-midnight in the user's timezone. After midnight, it resets. In terms of user experience, we need to decide... * ...what the user sees in the post-edit dialog after they complete their 25th suggestion that day ({T290789}). * ...what happens in the suggested edits feed if the user is viewing it and the difficulty filters after their 25th suggestion that day. * ...what happens when the user has multiple tasks opens in multiple tabs, and tries to save a task after reaching their quota in an another tab. * ...what happens when the user has a tasks open in a tabs, and the homepage open in another, and tries to select an image task after reaching their quota in an another tab. Other points: * If trivial, we would like to have the //option// to apply this same logic to "add a link" and the other unstructured task types. * Parameters around this quality gate should become part of community configuration. ** For which task types the gate is active. ** What threshold it should use for number of edits.

In {T274325}, we discussed some ideas for quality gates for "add a link", which would be rules that slowed or stopped contributors who are adding many damaging edits to the wiki. We have not needed to implement any of them yet for "add a link". But adding images to articles is a highly impactful and visible edit. That means that a user who is doing a bad job could cause a lot of damage quickly through "add an image". We've seen this through the Wikipedia Pages Wanting Photos campaign, in which most users were being productive, but some generated many weak edits. Discussions at English Wikipedia [[ https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Archive335##WPWP_#WPWPARK | here ]] led that community to limit participants to 25 of these edits per day -- a blunt way to limit a user who is moving quickly. For "add an image", we've had ideas that range from simple to sophisticated. With each of these ideas, we would either stop the users from doing the task, try to re-onboard them, or suggest different tasks. * Quantity: limit participants to a certain number of edits per day. * Reverts: limit participants who have had too many reverts to this task type. * Speed: limit participants based on the average time they're spending on each edit being too low. * Ratio: limit participants based on them answering "yes" or "no" more often than is expected from the algorithm. In Iteration 1, we'll do the simple "quantity" gate, with this rule: **Users may not open a 26th suggestion after having submitted "yes" or "no" responses on 25 suggestions in that day.** * Though both "yes" and "no" count, "skip" does not. * The "day" period should be defined as midnight-to-midnight in the user's timezone. After midnight, it resets. In terms of user experience:, we need to decide... * We need to decide * ...what the user sees in the post-edit dialog after they complete their 25th suggestion that day ({T290789}). * We need to decide * ...what happens in the suggested edits feed if the user is viewing it and the difficulty filters after their 25th suggestion that day. * ...what happens when the user has multiple tasks opens in multiple tabs, and tries to save a task after reaching their quota in an another tab. * ...what happens when the user has a tasks open in a tabs, and the homepage open in another, and tries to select an image task after reaching their quota in an another tab. Other points: * If trivial, we would like to have the //option// to apply this same logic to "add a link" and the other unstructured task types. * Parameters around this quality gate should become part of community configuration. ** For which task types the gate is active. ** What threshold it should use for number of edits.