Skip to content
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

Merged
merged 16 commits into from
Mar 19, 2024
Merged

Implementation Plan: Content moderation metrics #3760

merged 16 commits into from
Mar 19, 2024

Conversation

dhruvkb
Copy link
Member

@dhruvkb dhruvkb commented Feb 6, 2024

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

  • My pull request has a descriptive title (not a vague title likeUpdate index.md).
  • My pull request targets the default branch of the repository (main) or a parent feature branch.
  • My commit messages follow best practices.
  • My code follows the established code style of the repository.
  • I added or updated tests for the changes I made (if applicable).
  • I added or updated documentation (if applicable).
  • I tried running the project locally and verified that there are no visible errors.
  • I ran the DAG documentation generator (if applicable).

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

@dhruvkb dhruvkb added 🟨 priority: medium Not blocking but should be addressed soon 🌟 goal: addition Addition of new feature 📄 aspect: text Concerns the textual material in the repository 🧱 stack: api Related to the Django API 🧱 stack: documentation Related to Sphinx documentation 🧭 project: implementation plan An implementation plan for a project labels Feb 6, 2024
Copy link

github-actions bot commented Feb 6, 2024

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 ➕:

Copy link
Member Author

@dhruvkb dhruvkb left a 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.

@dhruvkb dhruvkb marked this pull request as ready for review February 11, 2024 10:13
@dhruvkb dhruvkb requested a review from a team as a code owner February 11, 2024 10:14
@sarayourfriend
Copy link
Collaborator

Just a heads up @dhruvkb, from the PR description:

🚧 WIP. No reviewers have been decided yet.

@dhruvkb dhruvkb marked this pull request as draft February 13, 2024 05:46
@dhruvkb
Copy link
Member Author

dhruvkb commented Feb 13, 2024

Drafting for a short bit to address potential changes from #3760 (comment) and determine reviewers.

@dhruvkb dhruvkb requested review from stacimc and removed request for obulat February 13, 2024 13:24
@dhruvkb dhruvkb marked this pull request as ready for review February 13, 2024 13:24
Copy link
Collaborator

@stacimc stacimc left a 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.

- 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) -->
Copy link
Collaborator

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.

Copy link
Member Author

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.

@openverse-bot
Copy link
Collaborator

Based on the medium urgency of this PR, the following reviewers are being gently reminded to review this PR:

@AetherUnbound
This reminder is being automatically generated due to the urgency configuration.

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

  1. Specifically, Saturday and Sunday.

  2. For the purpose of these reminders we treat Monday - Friday as weekdays. Please note that the operation that generates these reminders runs at midnight UTC on Monday - Friday. This means that depending on your timezone, you may be pinged outside of the expected range.

@dhruvkb dhruvkb marked this pull request as draft February 20, 2024 07:07
@dhruvkb dhruvkb requested a review from stacimc February 27, 2024 13:28
@dhruvkb dhruvkb marked this pull request as ready for review February 27, 2024 15:48
Copy link
Collaborator

@AetherUnbound AetherUnbound left a 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!

Copy link
Collaborator

@stacimc stacimc left a 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()
Copy link
Collaborator

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"?

Copy link
Collaborator

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!

Copy link
Member Author

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.

Copy link
Collaborator

@AetherUnbound AetherUnbound left a 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! 😄

Copy link
Collaborator

@stacimc stacimc left a 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!

Co-authored-by: Staci Mullins <[email protected]>
@dhruvkb dhruvkb merged commit 0a4c34a into main Mar 19, 2024
38 checks passed
@dhruvkb dhruvkb deleted the mod_metrics branch March 19, 2024 06:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📄 aspect: text Concerns the textual material in the repository 🌟 goal: addition Addition of new feature 🟨 priority: medium Not blocking but should be addressed soon 🧭 project: implementation plan An implementation plan for a project skip-changelog 🧱 stack: api Related to the Django API 🧱 stack: documentation Related to Sphinx documentation
Projects
Status: Accepted
Archived in project
Development

Successfully merging this pull request may close these issues.

Implementation Plan: Moderation queue metrification
6 participants