Per T342189, experienced volunteers need a way to see all of the published edits an Edit Check was presented within and all of the Edit Check that were activated within said edit.
This way, volunteers can name patterns common among false positives and low quality/disruptive edits and propose revisions to counteract these trends.
This task involves investigating the viability of storing/layering on additional metadata within edit tags T324733 introduced, and other tags like it in the future.
The broader idea here is that if the approach this task is investigating proves viable, we could use the combination of edit tags and the metadata we can store "within" them to "compose" a view like Special:AbuseLog.
Open questions
- 1. What – if any – limitations exist on what data (size, format, etc.) can be stored/associated with an edit tag?
- 2. Assuming this data storage approach can "house" the data needed to build a view like the one T342189 describes, what – if any – performance considerations should we be aware of before moving forward with implementation?
- 3. What – if any – adjustment(s) will we make to how Edit Check-related tags are flagged to ensure Edit Check tags don't "bleed" between discrete edits/edit sessions?
- See more in T373690#10119831.
Done
- Answers to all Open questions are documented above