Add support for public commenting on posted/published content

[asmecher]

Editors wish to be able to permit public commenting on published content (articles, monographs, and preprints).

This could be achieved by:

• Integrating an external off-the-shelf commenting toolset such as https://coralproject.net/
• Integrating a Laravel-friendly toolkit such as...
  • https://spatie.be/docs/laravel-comments (not free)
  • https://github.com/laravelista/comments
  • https://github.com/beyondcode/laravel-comments
  • https://github.com/iooe/laravel-comments
• Coding it up from scratch (as OJS2 used to support).

Specs Update - Friday, September 27th, 2024

Workflows Affected by This Change

• Adding Comment feature to the Article Landing page of OJS default theme
• Form for reporting a comment for the users
• Ability for Journal Admins / Managers to Hide only reported comments

Detailed Specs

For public commenting, I really like @felixhelix's approach and might tweak it slightly, as shown below

In the 'More Options' section for admins or journal managers, we could implement a 'Report' feature, where the admin sees the report and can then decide to hide it. Typically, reporting a comment involves filling out a form explaining the reason.

[felixhelix]

Hi, we developed a commenting plugin from scratch for our preprint server :)
It uses vue, tailwind and the pkp api. It is in our gitlab repo, but I see if I can get it in github within the next weeks so you can have a look at it (and/or post a link once our OPS goes public).
Currently version ops 3.3 is supported, but I already started working on a 3.5 version.
yours,
felix

[ewhanson]

@felixhelix, that would be great to see. Looking forward to it!

@asmecher, I also did a bit of looking into some of the Laravel packages. I haven't ever adapted an existing Laravel package to work in a non-Laravel context, but it seems like it may end up being a decent amount of work since a lot of what makes the Laravel packges easy to get up and running are the automatic binding of things in the service providers, use of the different Laravel helpers, etc. I was looking at the beyondcode/laravel-comments package, which is fairly minimal, but could be straightforward to using as a starting point for coding something from scratch.

[felixhelix]

I just published the OPS 3.3 version of the commenting plugin to github, so you can have a look and see if this could be a way to go:

https://github.com/felixhelix/userComments

There is no release yet, but I provided some documentation for installing.
The backend is a bit clumsy, since it was originally only meant for me and my colleague to work with.

I will be at the sprint in Turin this year :)
So maybe this could be an opportunity to talk about it as well.

[asmecher]

Thanks, @felixhelix!

@ewhanson, could you take a look over this?

[Devika008]

Hello @felixhelix

Is there a recording or screenshots showing how this works?

From a UI/UX perspective, I was thinking of keeping it simple with plain text comments, without any formatting options. To identify the user, we could include their profile picture and name. I've noticed some journals offer features like liking or replying to comments, but I feel that might be a bit too much. Keeping it straightforward would be better.

@ewhanson do you need me to develop some mockups for this or would you like me to review? I think its a better idea to use @felixhelix 's plugin as starting point for this

[Devika008]

Hello @felixhelix

Is there a recording or screenshots showing how this works?

From a UI/UX perspective, I was thinking of keeping it simple with plain text comments, without any formatting options. To identify the user, we could include their profile picture and name. I've noticed some journals offer features like liking or replying to comments, but I feel that might be a bit too much. Keeping it straightforward would be better.

@ewhanson do you need me to develop some mockups for this or would you like me to review? I think its a better idea to use @felixhelix 's plugin as starting point for this

[asmecher]

The big question -- if the commenting feature is intended to serve an open review functionality -- is whether it would be best to extend the existing peer review toolkit to support an additional transparent mode. This would have several benefits -- all review content, whether open or closed, would live in the same data model. However, public peer reviews are quite different from traditional peer reviews in that there is no assign/accept/complete workflow, so much of the existing review assignment code would not be useful and might need to be made more flexible.

[Devika008]

How about we make the peer review process more interactive? If someone is interested in reviewing an article, they could click on 'Review article,' and then the page would expand to show the questions. This way, we can separate casual comments from formal reviews, keeping the space organized and easy to navigate without overwhelming users and/or editors parsing through the comments

[felixhelix]

Hi @Devika008, we hope to go online next month. But here is a screenshot of the details page (we are currently doing usability tests, so the overall design is still in a flux):

As you see, there is a button for submitting peer reviews and below is the comment section.
So far we have no user picture, instead we provide the orcid id.

As one can see, there is a "submit a review report" button as suggested :)
This leads to a pre-configured submission wizard: Review reports are submitted as yet another manuscript, but assigned to a specific section and with submission metadata entries that link them to the manuscript under review. This is because we want to use the existing workflow for doi and orcid registration.

@ewhanson I also finished a version that works with 3.5. I am about to update some code, but if it would make it easier for you to have a look, I could push that branch too.

[Devika008]

Hello,

@ewhanson and I had a quick discussion about this, and while we're still going over the details, I think it's best to focus on enabling public commenting for now. We can create a separate issue for the workflow of inviting open reviews since that will need more in-depth research. For public commenting, I really like @felixhelix's approach and might tweak it slightly, as shown below

In the 'More Options' section for admins or journal managers, we could include a 'Hide Comment' button to remove inappropriate comments. While this gives them the ability to hide any comment, another option could be to implement a 'Report' feature, where the admin sees the report and can then decide to hide it. Typically, reporting a comment involves filling out a form explaining the reason. Let me know if that feels too much or unnecessary

[felixhelix]

Thanks @Devika008 for taking this up!
I will see that I update the design in one of the next versions. I think one of the challenges will be to design the plugin anew using the predefined styles from the default theme while finding a way that allows for override by custom themes (such as ours).

[Devika008]

@felixhelix you can adapt the styling based on the UI components you have in your journal or the OJS default. I just provided a structure of the comments should look like

[taslangraham]

@ewhanson @Devika008 @asmecher
I explored the commenting feature and whether it would be better to use an existing package or build it from scratch. I mainly focused on beyondcode/laravel-comments because it's lightweight and focuses exclusively on comments, unlike others that bundle additional features like UI and authorizations.

The beyondcode package is fairly straightforward, but there’s a catch: we'd need to convert the models we want to allow comments on to Eloquent models. This is because the package relies on Laravel's Polymorphic Relationships, which only works with Eloquent models - this is the same for the other packages as well. Would it be worth refactoring our existing models now?

That said, the package is quite minimal, so we could use it as a guide to coding something from scratch that fits better into our current setup.

Here are a few more things we have to consider when implementing comments:

• Comment approval logic: By default, comments aren't auto-approved, and most of the existing packages include an approval feature. If we code something from scratch then we'd need to handle this.

• UI for moderators: Whether we use a package or custom solution, we’ll need a way for authorized moderators to approve comments.

• Version-specific comments: Support for commenting on individual versions of published content.

• Review responses: In an open review setting, users (including authors) should be able to comment on or respond to the review report of a version of published content. This is separate from just commenting on the content version itself.