Closed RokeJulianLockhart closed 1 month ago
https://github.com/mozilla/addons/issues/15130#issue-2627187588
This was originally requested at https://bugzilla.mozilla.org/show_bug.cgi?id=1648767#c0 (paraphrased undermentioned):
#### Steps to reproduce: Write a review on a Firefox add-on, then let the specific add-on-developer reply to your review. #### Actual results: There is no button to reply to the developer's review-reply. #### Expected results: We need a button to be able to reply to the developer in an add-on-review-reply.
For the sake of its author, if a URI to this FR could be added to that ticket by someone with adequate permissions, I'd be thankful.
Thanks! I just saw your mail (landed in my spam o_O), what is an "FR"?
https://github.com/mozilla/addons/issues/15130#issuecomment-2452706681
@D4n2021, just a feature request. I must be spending too much time on bug trackers if I'm inventing acronyms.
Our goal is to keep the reviews system as simple as possible to enable users add-on users to provide detailed reviews that will be useful for others to decide if they should install the add-on, whilst not encouraging it to be used as a support forum or feature request platform. We encourage developers to include a link to a forum or GitHub issues page to facilitate these types of discussion. At this time we are not investing in adding more complex logic to the reviewing system.
We encourage developers to include a link to a forum or GitHub issues page to facilitate these types of discussion.
@abyrne-moz, that's understandable. However, are you at least aware that for add-on authors who do not provide that, the review system is frequently misused by both reviewer and author as a method of discussion (as aforementioned)? Perhaps mandating a tracker for each add-on would be of use.
https://github.com/mozilla/addons/issues/15130#event-15150636294
This should be closed as unplanned, surely?
Yeah, I've occasionally seen the review system used this way. Mandating a bug tracker adds significant overhead to extension developers and is not something we would want to impose on our developer ecosystem.
I've changed it to unplanned, thanks for pointing that out.
Description
Conversations can already occur in reviews, because modifications to reviews and developer responses cause notifications to be sent to the relevant party. However, this requires the developer and user to constantly modify their comments, which, without review modification histories (requested in https://github.com/mozilla/addons/issues/15131#issue-2627195609), means that the discussion is ephemeral. When this is occurring on multiple reviews, this can cause the review section to appear more like a notice board to a reader, because reviews are instead misused to communicate with the development team, instead of being reviews.
Instead, I propose that threaded response support be implemented, so that a top-level review can remain a review whilst permitting the add-on author and reviewer to discuss in a way that preserves the conversation for others and themselves.
Acceptance Criteria
Checks
┆Issue is synchronized with this Jira Task