Moderation and approval queue: review data model and state transitions #89

Closed
opened 2024-04-23 18:17:38 +02:00 by Oleg-Komarov · 3 comments
Owner

Current state

  • problems:
    • approval-queue listing (AQ for short) doesn't indicate if a moderator requested changes
    • once an extension is approved and listed, it becomes hidden in AQ, making it difficult to return to the corresponding approval thread (AT)
    • confusing distinction and some code duplication between draft and manage extension/version pages:
      • after a draft is submitted it is possible to still edit the extension via the manage page;
      • also it is possible to save changes while the extension is still being reviewed, creating a scenario when a moderator may miss the latest change and approve the extension in an browser tab with outdated content
  • accepted by design:
    • moderation is required only for an initial version, all subsequent versions are automatically marked as approved and become listed
    • a user can notify moderators about a problem with a listed extension via an abuse report
    • initial version submission generates a comment in AT with the "Awaiting Review" status (triggers a notification)

Relevant new features (full implementation may be out of scope)

  • new versions of a listed extension should create an comment on the AT (without triggering a notification)
  • when an upload (both for a draft an a listed extension) is marked as suspicious (FIleValidation not is_ok):
    • it should be visible in AQ to moderators and admins (also triggers a notification)
    • the AT should be hidden from the author and other users

Proposal on the structure

  • rewrite AQ page as a list of all ApprovalActivity items across all extensions, grouped by extension, display a summary:
    • last meaningful status ("Awaiting review", "Awaiting changes")
    • presence of a suspicious upload
    • other fields present today (Type, Name, Author, Submitted, Activity)
  • make the role of Extension status (not ApprovalActivity!) "Awaiting Review" explicit:
    • once a draft extension (status "Incomplete") is submitted for review, its status is changed to "Awaiting Review"
    • saving changes while in "Awating Review" is either blocked or generates a comment on the AT
    • when a moderator creates an "Awaiting Changes" ApprovalActivity item, the extension changes its status from "Awaiting Review" to "Incomplete", effectively returning it to a draft state
## Current state - problems: - approval-queue listing (AQ for short) doesn't indicate if a moderator requested changes - once an extension is approved and listed, it becomes hidden in AQ, making it difficult to return to the corresponding approval thread (AT) - confusing distinction and some code duplication between draft and manage extension/version pages: - after a draft is submitted it is possible to still edit the extension via the manage page; - also it is possible to save changes while the extension is still being reviewed, creating a scenario when a moderator may miss the latest change and approve the extension in an browser tab with outdated content - accepted by design: - moderation is required only for an initial version, all subsequent versions are automatically marked as approved and become listed - a user can notify moderators about a problem with a listed extension via an abuse report - initial version submission generates a comment in AT with the "Awaiting Review" status (triggers a notification) ## Relevant new features (full implementation may be out of scope) - new versions of a listed extension should create an comment on the AT (without triggering a notification) - when an upload (both for a draft an a listed extension) is marked as suspicious (FIleValidation not is_ok): - it should be visible in AQ to moderators and admins (also triggers a notification) - the AT should be hidden from the author and other users ## Proposal on the structure - rewrite AQ page as a list of all ApprovalActivity items across all extensions, grouped by extension, display a summary: - last meaningful status ("Awaiting review", "Awaiting changes") - presence of a suspicious upload - other fields present today (Type, Name, Author, Submitted, Activity) - make the role of Extension status (not ApprovalActivity!) "Awaiting Review" explicit: - once a draft extension (status "Incomplete") is submitted for review, its status is changed to "Awaiting Review" - saving changes while in "Awating Review" is either blocked or generates a comment on the AT - when a moderator creates an "Awaiting Changes" ApprovalActivity item, the extension changes its status from "Awaiting Review" to "Incomplete", effectively returning it to a draft state
Author
Owner

updates from https://devtalk.blender.org/t/2024-04-30-extensions-platform-backend/34413:

Approval Queue:

  • Sort by status (Awaiting Review, Awaiting Changes, Approved).
  • Create activity for image changes.
  • Don’t show status on the images.
  • When reporting a review, there is no need for “Versions” (aka Releases).
updates from https://devtalk.blender.org/t/2024-04-30-extensions-platform-backend/34413: Approval Queue: - [x] Sort by status (Awaiting Review, Awaiting Changes, Approved). - [ ] Create activity for image changes. - [x] Don’t show status on the images. - [x] When reporting a review, there is no need for “Versions” (aka Releases).

I thought that "Don’t show status on the images." was already tackled by 6ec4e31e24. Though I haven't tested it myself.

I thought that "Don’t show status on the images." was already tackled by https://projects.blender.org/infrastructure/extensions-website/commit/6ec4e31e24446356dc618fc94c4fc90cb19d6362. Though I haven't tested it myself.
Author
Owner

Closing this, as most of the things have been addressed, creating activity for extension changes (image uploads, description changes, etc) can be created as a separate more focused issue.

Closing this, as most of the things have been addressed, creating activity for extension changes (image uploads, description changes, etc) can be created as a separate more focused issue.
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: infrastructure/extensions-website#89
No description provided.