-
Notifications
You must be signed in to change notification settings - Fork 32
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
0000: Proposal for supporting comments when submitting pages for moderation #47
Conversation
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 |
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.
What’s the rationale for the maximum length?
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.
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
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 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. |
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.
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.
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 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. |
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 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.
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.
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` |
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 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
?
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 don't mind your phrasing at all. Shorter and cleaner 👍
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 In the current approach, 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 |
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!