Change Details

In order to determine how frequently blocked users attempt to edit (but are prevented) please add a form of tracking that captures how many edit attempts occur. We do not need to capture and PII for this — just a raw number of how many edit attempts per hour are rejected. On desktop and mobile we could add event logging, but we will also want to measure how frequently API edits are blocked. We will probably want to know a split by device type: desktop, mobile, and API. This can be split in other ways, such as "editor warned before they edited" and "editor warned when they attempt to publish."

In order to determine how frequently blocked users attempt to edit (but are prevented) please add a method of tracking that captures how many edit attempts occur. We do not need to capture any personally identifiable information (e.g. username, IP address, etc.) for this — just a raw number of how many edit attempts per hour are rejected. On desktop and mobile we could add event logging, but we will also want to measure how frequently API edits are blocked. We will probably want to know a split by device type: desktop, mobile, and API. This can be split in other ways, such as "editor warned before they edited" and "editor warned when they attempt to publish." The requirements are flexible and open to changing as we learn more during development. ---- ===Requirements * A report of "hourly blocked edits" is available (can be on demand via query, no UI or automated delivery is needed) * The report is broken into desktop, mobile, and API edits (or a similar breakdown) * The circumstances of how this data is logged is documented, including any known limitations.

In order to determine how frequently blocked users attempt to edit (but are prevented) please add a formmethod of tracking that captures how many edit attempts occur. We do not need to capture any personally identifiable information (e.g. username, IP address, We do not need to capture and PIIetc.) for this — just a raw number of how many edit attempts per hour are rejected. On desktop and mobile we could add event logging, but we will also want to measure how frequently API edits are blocked. We will probably want to know a split by device type: desktop, mobile, and API. This can be split in other ways, such as "editor warned before they edited" and "editor warned when they attempt to publish." The requirements are flexible and open to changing as we learn more during development. ---- ===Requirements * A report of "hourly blocked edits" is available (can be on demand via query, no UI or automated delivery is needed) * The report is broken into desktop, mobile, and API edits (or a similar breakdown) * The circumstances of how this data is logged is documented, including any known limitations.