Request's comments enhancements

[zzacharo]

At CERN we conducted various interviews with our different experiment communities, trying to understand the way they review publication drafts and below is a summary of proposed enhancements in InvenioRDM's request commenting capabilities that can facilitate their work.

The features are categorized in terms of significance in:

R: required i.e. these features will be needed for our ongoing content migration of existing review comments
RL: required later i.e. these features will be needed in the near future
NTH: nice-to-have i.e. features that possibly enhance the commenting user experience but not an immediate priority.

This discussion aims to expose these ideas and give to the community a chance to add/propose changes or new ideas.

Required

Autosave the current draft comment written in the textarea

Users tend to add extentive comments directly via the web application and often a wrong misclick can lead to the loss of significant amount of work.

Quote reply functionality

The aim of the feature is to add a way for users to quote and reply to an existing comment (similar to github).

Additionally, due to comments potentially being quite big, the ability to select and quote specific text from a comment would be a valuable addition.

Collapsible comments

Make each comment collapsible. Evaluate if after n chars the comment is automatically collapsed with the possibility to expand it.

Attach files to comments

At CERN, in the research community, users are attaching files to their comments. These can be useful as reviewers can:

• add their comments directly on the submitted pdf and upload their extensive review
• attach corrected material e.g figures, diagrams etc.
• embed an image in the comment and inline preview it

Note: Once the possibility of uploading a file is available, we could think of extending the commenting processing with tools that could parse the submitted files and e.g auto-generate comments.

Discussion per comment

This feature aims to add a one level thread level per comment. The incentive behind this is that a comment is considered a thorough review of a publication. In that context, having a conversation between the authors and the reviewer regarding the submitted review makes sense. The one-level single thread is a compromise between "no replies per comment" and "nested threading" that still keeps the focus of the commenting on the submitted resource but facilitates the interaction between authors and reviewers.

Required later

Deep linked comments so that users can share a comment

At CERN, we have communities that were creating peristent URLS to comments. In that paradigm, a comment is more of a peer review which after submission was immutable to changes.

The feature aims to add a way to "copy the link" to a comment, similar to github, so that this can be shared with others or referenced in comments.

Switch paginated comments for single-loaded discussion

In the example of heavily commented publication drafts, the fact that comments are paginated makes searching for them quite complex.

The feature aims to provide an alternative/change the display of the request timeline from paginated results to a single loaded discussion. The advantage is that users can easily find comments by simply pressing Ctrl + F) in the page. Additional features e.g collapsing comments, might be needed to mitigate densely commented requests.

Create structured tags in comment payload

The motivation behind this feature is to be able eventually to categorize/search content aggregated by a specific tag. For example, at CERN each comment contains an extended text in the format of comments per line in a pdf. The editors spend a significant amount of time to merge all comments and group them by the referenced line in the e.g. submitted pdf. Although the generattion of such reports is most probably a feature customized to CERN, the ability to add some reserved tags will enable these kind of advanced post processing of comments.

Preview of comment

Users would like to have a preview button ala GH or Wikipedia, to be able to preview their comment so that they can catch typo errors in cases e.g. using latex syntax

Apply a grace period for comment actions e.g. edit/delete/add new comment

Usually after adding a comment/review, the receivers of the comment start working on the posted review. There should be a configurable grace period after which specific actions on the comment and in the request discussion should be disabled.

Nice to have

• Export/Download all comments/attached files
  • different formats
  • users then can user their favorite tool to analyze them
• Comment resolution
  • Visually indicate that a comment/review has been resolved i.e. the author has addressed the comments
• Comment statistics (e.g., 7 approved, 3 rejected) would help authors post-review.
• Generate review request reports
  • Group comments per line of the document
    • Users highlighted that is rather difficult to find all comments related to a specific line
  • Resolved/unresolved?
  • This could be also a LLM use case (allow download of comments/attachments and generate reports)

[ugswork]

@zzacharo @nicola It is great to see that this topic is given more attention now.
I am attaching some screenshots of what I have implemented on extending the conversation, for your reference.

1. Addition of Reply threads to Comments in conversation.
   (This custom change was originally implemented on V11 and ported to V12 too. Because of the difficulty in porting this locally for future RDM versions, it would be good to see if something similar to this is a candidate for being included in the core RDM code.)

2. Collapse the content of a comment when it is more than some length and expand when needed.

[zzacharo]

Hello @ugswork , thanks a lot for sharing your use cases and implementation efforts :) In terms of features, I think we are aligned... I have a question about the thread replies in comments:

• Are you adding single level of nesting? I.e. one single thread discussion per comment?
• In terms of UI, what was the reasoning behind displaying the threads in a separate view rather than inline under each comment? For example (AI generated image):

[ugswork]

This is what i added for Version 11.

[ugswork]

Conversation for published records are made available. This can be enabled at the community level.

[tmorrell]

Our librarians want to be able to see the conversation history from the landing page because they want to know the reasons for curatorial decisions made to a record, such as "Why is this file embargoed?" or "Who reviewed this record?". We've used @ugswork's tab implementation and it's worked nicely. I've made an issue for that integration inveniosoftware/invenio-app-rdm#2953, and there is a preliminary PR inveniosoftware/invenio-app-rdm#2954.

[ugswork]

@tmorrell Good to note that you have been using the conversation tab for published records. I made an update to that code. I have updated my git repo with the changes.

[ugswork]

@zzacharo @ntarocco I have added the links for the custom code changes done regarding conversation for your reference. I meant to send this earlier, but was caught up with a server upgrade.

File attached to this for comment collapsed when more than certain chars and expand.
TimelineCommentEvent.js

Link for making conversation available for published records - updated for V13 @tmorrell
https://github.com/ugswork/published_record_conversation

Link for addition of reply thread to each comment. This has been done for an older version of invenio-requests
https://github.com/ugswork/invenio-requests-reply-thread

[ugswork]

@zzacharo @ntarocco
I tested the following custom code to send notifications whenever a comment is added to a conversation.
By default whenever a comment is added, notifications are sent to:
* request creator
* all commenters in that conversation
* all mentions from all comments using @username
* mentions in current comment
- Validate all usernames
- Track skipped users

notifications.py