-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementation Plan: Content moderation metrics #3760
Conversation
Full-stack documentation: https://docs.openverse.org/_preview/3760 Please note that GitHub pages takes a little time to deploy newly pushed code, if the links above don't work or you see old versions, wait 5 minutes and try again. You can check the GitHub pages deployment action list to see the current status of the deployments. New files ➕: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good enough to ask for reviews now.
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Outdated
Show resolved
Hide resolved
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Outdated
Show resolved
Hide resolved
Just a heads up @dhruvkb, from the PR description:
|
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Outdated
Show resolved
Hide resolved
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Outdated
Show resolved
Hide resolved
Drafting for a short bit to address potential changes from #3760 (comment) and determine reviewers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excited for this -- having just worked on the bulk moderation decisions IP I'm immediately thinking this will be so useful for maintainers in those bulk moderation use cases, in addition to being useful for moderators :)
My questions largely relate to the way the ModerationDecision and MediaReport models have been changed in previous IPs as part of this milestone, which I think complicates some of the events and metrics described here. The IP describing ModerationDecision and updates to the Report model has been approved, and the Bulk Moderation IP which extends the decision model is about to be approved, so I think the models are solid at this point.
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Show resolved
Hide resolved
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Show resolved
Hide resolved
- number of decisions (time-series, real-time) | ||
<!-- TODO: - per media type (time-series, real-time) --> | ||
- number of resolutions (time-series, real-time) | ||
<!-- TODO: - per media type (time-series, real-time) --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should these TODOs be added in, or do you mean to suggest that they wouldn't be added in the first pass but later?
I imagine that a lot (if not all) of these metrics would be useful to break down by media type, violation type, and even provider/creator/source. Particularly in the deferred metrics, maybe the Django views could support filters along those lines? In that case it might be helpful to include all metrics in the Django views, even those which have time-series on the cloudwatch dashboards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The distinction between media types was kept as a TODO because I was still understanding their implementation. Since the report and decision models are already separated by media type all metrics we want to know can be broken down on that basis.
For the real-time metrics we can construct dashboard graphs specific to our needs but I'm not sure if Cloudwatch allows us to dig into the metrics and apply more specific filters.
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Outdated
Show resolved
Hide resolved
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Outdated
Show resolved
Hide resolved
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Outdated
Show resolved
Hide resolved
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Show resolved
Hide resolved
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Outdated
Show resolved
Hide resolved
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Show resolved
Hide resolved
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Outdated
Show resolved
Hide resolved
Based on the medium urgency of this PR, the following reviewers are being gently reminded to review this PR: @AetherUnbound Excluding weekend1 days, this PR was ready for review 4 day(s) ago. PRs labelled with medium urgency are expected to be reviewed within 4 weekday(s)2. @dhruvkb, if this PR is not ready for a review, please draft it to prevent reviewers from getting further unnecessary pings. Footnotes
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fantastic, and very clear! I have a few points of clarification, but generally this seems straightforward 😄 I'm very excited for this and I'm glad we could fit it in with existing tools so easily!
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Show resolved
Hide resolved
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Show resolved
Hide resolved
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Outdated
Show resolved
Hide resolved
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Outdated
Show resolved
Hide resolved
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Outdated
Show resolved
Hide resolved
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Outdated
Show resolved
Hide resolved
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Madison Swain-Bowden <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The updates look fantastic @dhruvkb! Very thorough and the code samples are excellent.
# accuracy of reports | ||
# =================== | ||
total_reports = reports_in_range.count() | ||
confirmed_reports = reports_in_range.filter(decision__action__in=['marked_sensitive', 'deindexed_sensitive', 'deindexed_copyright']).count() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a minor thing, but the more I think about it the more the term 'accuracy' doesn't feel quite right -- specifically because it excludes deduplicated reports. We define dedeuplicating a report as an acknowledgement that it was accurate, but requires no action. (E.g. an already sensitive-marked work gets reported for sensitive content).
I totally understand why the duplication counts would be broken out into a separate metric, though. Maybe we could just change "accuracy" to something like "actionable"/"actioned"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just adding that I don't think the language necessarily needs to be finalized at this stage. I would be totally fine with just mentioning that in the issues that are created.
Happy to approve whenever this is moved out of the Clarification Round!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried very hard to find a better name for it but couldn't, because of these reaosons
- duplicates can exist for both accurate and inaccurate reports so "accuracy" isn't the best term for this
- marking a report as a duplicate is an action so not counting them under "actionable"/"actioned" isn't fair either
I'll move this proposal ahead into the decision round if we can keep this as an open question to find a better, more-suitable name for this metric.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fully on board, no blocking objections! Great work on this Dhruv! 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great to me!
...rust_and_safety/content_report_moderation/20240122-implementation_plan_moderation_metrics.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Staci Mullins <[email protected]>
Fixes
Fixes #1970 by @sarayourfriend
Description
This PR adds an implementation plan for adding metrics for the moderation based on the reports and decisions. This PR adds a few more metrics than the project proposal called for but that felt appropriate to track.
Reviewers:
Testing Instructions
Please read the IP and submit your thoughts.This proposal is now in the decision round.Checklist
Update index.md
).main
) or a parent feature branch.Developer Certificate of Origin
Developer Certificate of Origin