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
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
91 changes: 91 additions & 0 deletions text/000-append-comments-for-moderation.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,91 @@
# RFC 1: Provide option to require a comment when submitting content for moderation

- Authors: Val Grimm (@valgrimm) and Steve Jalim (@stevejalim)
- Created: 2019-12-21
- Last Modified: 2019-12-30

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


## Specification

### Rationale

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


### Acceptance Criteria

_End-user behavior_:

1. After an Editor (or role with equivalent permissions) selects "Submit for Moderation" in the main combo-button _and_ a configuration setting to require a submission comment is enabled:

- 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.

- The comment field will have a label that reads "Please add a comment here to provide context for your submission"
- The dialog box will have a "Complete submission for Moderation" button beneath it
- This submission button will remain disabled until the user enters content in the comment field

If the setting to require a submission comment is not enabled, the behaviour of the workflow remains the same as the current version of Wagtail.

_Administration behavior_:

1. It should be possible to activate/deactivate this functionality via Wagtail/Django `settings`, but it is not necessary to surface this option in the Wagtail Admin's Settings UI.

Note: the rationale for only making this functionality deactivatable via code is:

- it will be easier to implement
- keeping it out of the Admin UI means it cannot be disabled without good reason

### Technical specification

_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 👍

2. A new field (`moderation_comment`, `models.CharField(max_length=500, blank=True)`) is added to the `PageRevision` class.
3. Given the Admin UI for creation and editing uses a Django form as its transport mechanism, we slot in an additional form field (`moderation_comment`, `forms.CharField(max_length=500, required=True, widget=forms.Textarea()`) for the submission comment's text, _but only if `REQUIRE_COMMENT_FOR_MODERATION_SUBMISSION` is `True`._
- If this field is present in the DOM, its visibility will initially be hidden.
4. An update to the Admin UI's JS is required:

- The JS must watch for submission of a Page for moderation and prevent the HTTP POST that would normally send the form's payload to the server
- It will then trigger a basic modal popup to capture the required info from the Editor
- The modal will show the label, as described above
- The modal will have a button to complete the submission, as described above. It will take the `disabled` state while the `moderation_comment` `<textarea>`'s content has no length or is greater than 500 characters. The page's JS will update the `disabled` state of the submission button accordingly, so that only valid comment content can be submitted.
- Once the submission-completion button has been clicked, the full page PLUS the new moderation-request comment will be sent to the server. (How this is done is definitely open: it could be that the payload state is copied/held when the original POST is blocked, and then that payload is updated before finally being POSTed; alternatively, the whole page could be re-POSTed now the hidden `moderation_comment` field has been populated)

5. The server receives the form payload and, upon seeing a `moderation_comment` field:

- validates that it is between 0 and 500 characters.
- ensures that data is saved with the `PageRevision` it creates.
- Note: If validation fails, Wagtail does not save the new revision and instead returns an error message using the same workflow as per any required field missing data.
- It might be useful to outline the Publish combo-button in red, to show where the user needs to go to amend the problem.

6. When any Editor is informed via email that a Page has been submitted for moderation, the `moderation_comment` shall also be included (but must be marked safe/sanitised)
7. When any Editor views the details of a Page pending Moderation (ie at `admin/pages/<pageid>/revisions/compare/live...<newrev>/`), if the relevant revision has a `moderation_comment`, it should be shown above the list of field diffs.

Notes:

- The same behaviour will need to be present on both page creation and page editing forms

## Drawbacks

- A code change will be needed to enable/disable the functionality as described above.
- In some situations the functionality will not be needed, so this change adds complexity to provide non-core functionality.
- This functionality will not guarantee an improved workflow: Editors can still circumvent it by typing nonsense into the comment field.

## Alternatives

- A reminder emailed to editors upon submission to ensure that they give context to moderators by email or instant message.
- A reminder screen displayed to editors after submission, asking them to do similar.

## Open Questions

- Is there a better way to slot on the `moderation_comment` data without having to block the submission first?
- Is this option compatible with any known plans to move away from using a Django `Form` for the page payload transport?
- Do we want to make the max-length of the moderation comment more than 500 chars?