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

0000: Proposal for supporting comments when submitting pages for moderation #47

Closed

Conversation

stevejalim
Copy link

This changeset contains a draft RFC that explores the need for, and a solution that delivers, a way for Editors to supply extra contextual info when submitting a Page for modereration.

It's our (@stevejalim and @valgrimm) first Wagtail RFC, so I'm expecting to have to evolve it a fair bit. Feedback is very welcome!

@zerolab zerolab added the 1:New label Jan 8, 2020
@zerolab
Copy link
Contributor

zerolab commented Jan 8, 2020

Thank you for the draft RFC @stevejalim!

Adding a note for team discussion -- related:

- They will be presented with a modal dialog box
- The dialog box will contain a comment field
- The comment field will be required
- The comment field will have an enforced and clearly marked maximum length of 500 characters
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What’s the rationale for the maximum length?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simply a way to stop people writing massive notes in there. If something needs that much explanation, I'd wonder if this box is the best place for that.

Could easily be a higher limit, of course

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 I guess it would make sense to align with what other comments systems make possible.

## Abstract

Moderators for Wagtail websites do not always have context about a change made to Page content when it is submitted to them for moderation. They receive a notification that something has changed on the Page, and it is possible in Wagtail to see which Page fields have changed (and how) by comparing the Page pending moderation with its live version, but there is no summary information about _why_ (ie, something akin to a source-code commit, which has a log entry).
Being able to require the inclusion of a comment with each moderation request would help address this information gap, resulting in a more effective coordination workflow.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you thought about whether it would be valuable for those comments to have a notion of "assignee", or have some sort of mentions-like support (@mentions)? It seems to be a pretty common feature of commenting systems these days.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose it depends on how many people are Moderators in an org. Certainly @mentions could be handy, but possibly out of scope for an initial version of this feature?

- Currently there is no way provided in Wagtail for moderators and editors to communicate.
- This necessitates the use of email or instant message between moderators and editors to discuss submissions.
- This adds overhead which can constitute a bottleneck in the publication of content, becoming especially onerous when editors are much more numerous than moderators.
- Editors may appreciate the reduced friction of being able to clarify their wishes to moderators in the submission flow, rather than outside of it.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should also address the fact that with your proposed system, the comments will be mandatory. Is this something that can be configured? Should individual editors be allowed to bypass it? Should there be a permission system for it? Otherwise I can think of many scenarios where this would increase friction.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now a global REQUIRE_COMMENT_FOR_MODERATION_SUBMISSION setting would allow a way to turn it off, but Editor-level enabling/disabling might be more easily done via Groups, perhaps?


_This specification is still loose and suggestions are welcome_

1. A new Wagtail setting is added: `REQUIRE_COMMENT_FOR_MODERATION_SUBMISSION`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be nice if the setting was clearer on whether it turns on this "moderation comments" feature, or whether the feature is always turned on and it just makes the comment required or optional. ENABLE_REVISION_COMMENTS?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't mind your phrasing at all. Shorter and cleaner 👍

@emilytoppm
Copy link
Member

Hi @stevejalim - just wanted to give an update on some context with regard to this, given the implementation of this would overlap with the new workflow system, RFC 45. This is currently being implemented on the feature/workflow branch.

In the current approach, Task and TaskState models can be subclassed: allowing custom state information to be stored about the completion of a moderation task: for example, a comment. Commenting functionality is not provided by default, but can be enabled by using the ReviewTasks provided by Wagtail Review, which allows both comments from the moderator approving/rejecting, and comment discussion on the page itself (which includes discussion between moderator and editor).

However, the approach this RFC describes is commenting when submitting, which is not included in the current implementation. To make this an option would require either adding a comment field to WorkflowState (making it the default for all), or to mirror the current approach, making Workflow and WorkflowState subclassable as well: for example, allowing an app like Wagtail Review to provide a ReviewWorkflow which requires a comment on submission. I believe custom Workflows and WorkflowStates are logical next steps for the Workflow system, so we should look at implementing that way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants