Repository navigation
Replies: 1 comment
|
Design PR #4126 proposes |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Problem
There is no place in EmDash for the people working on a site's content to discuss a draft or post. People are needing to use other channels to make comments, or drafting posts outside of EmDash before posting. There is no way to make these comments within EmDash itself
Two parts of EmDash make this harder to work around:
Edit locks, which are on by default, let one person edit an entry at a time. Everyone else sees the entry read-only, so a reviewer cannot leave even a temporary note in the text.
Contributors can read drafts but cannot edit entries, so they have no way to give feedback inside the CMS.
EmDash's existing comments feature is for site visitors, with moderation, Turnstile, and public display. It is not suited to private discussion between the people producing the content.
Use case
This affects any site where more than one person works on content: a publication with writers and editors, a marketing site where stakeholders approve copy before launch, an agency exchanging drafts with a client, or a docs team reviewing changes. Editors and reviewers need to give feedback, authors need to act on it, and contributors need a way to take part without edit access.
The expected interaction is the one people know from Google Docs and Notion. Select some text, or pick a field, a block, or the whole entry, and leave a comment. Others reply in a thread, mention a colleague to bring them in, and resolve the thread when it is dealt with. Some feedback is only visible on the rendered page, such as a headline that wraps badly or an image crop that cuts off the subject, so commenting from the visual editing toolbar would be useful as well.
The scope I have in mind for an RFC:
Private threads attached to an entry, a field, a Portable Text block, or a range of text. Threads are stored outside the content, so commenting does not edit the entry, does not need the edit lock, and never appears in published output.
Threads that stay attached to their text as it is edited, and that keep showing the original text if it is removed.
Replies, resolving and reopening, and mentions, with email notifications when the site has an email provider.
The admin entry editor first, followed by a lighter version in the visual editing toolbar.
A REST API and MCP tools, so agents can read and leave review comments.
Out of scope: real-time co-editing, suggested edits or tracked changes, and comments from people without an account.
Feedback that would help shape the RFC:
Which roles on your site would comment, and which would resolve threads?
Do you mostly comment on specific text, or on whole fields and entries?
Would you want unresolved threads to block publishing, or is that a separate workflow concern?
Would email notifications be welcome, or would you need to opt out before they ship?
What do you call this feature? "COmments" is easy to confuse with public comments.
Current workarounds
Discussing drafts in Slack, email, or issue trackers, describing the location in words.
Copying a draft into Google Docs for review and pasting the result back. This loses Portable Text structure, embeds, and custom blocks, and the reviewed copy drifts from the version in EmDash.
Writing notes into the content itself, such as bracketed TODOs. This needs the edit lock and edit permission, creates revisions, and risks publishing the notes.
A plugin can cover part of this. Plugins can add declarative panels to the entry editor, so a plugin could store notes on an entry. Plugins cannot add highlights or selection actions to the Portable Text editor or the visual editing toolbar, so comments attached to specific text need core support
Your involvement
All reactions