1144473 - (ninjaedits) Allow comments to be editable by author for some short duration after posting

Status: RESOLVED WONTFIX

(Bugzilla :: Creating/Changing Bugs, enhancement)

Description

[Mark Côté [:mcote]]

Also referred to as "ninja edits", this (optional) feature would allow the author of a comment to be able to edit (or delete) the comment within a short duration after posting it.  This would allow users to correct simple mistakes without really compromising a bug's history.  The corrected version would *not* trigger bugmail, since the intended use is for simple edits.

Open questions:

1. The duration should be configurable, but what's a good default, i.e., what should we try first?
2. Is editing prohibited if another user has since posted another comment?  Conversely, if a user has posted several comments in a row, should only the last be editable, regardless of time passed?

See also bug 540 and bug 53514.

Comment 1

[:glob ✱]

(In reply to Mark Côté [:mcote] from comment #0)
> .. to edit (or delete) the comment ..

i don't think comment deletion should be supported.  it's a lot more complicated, and you can already tag a comment to mark it as obsolete.

> 1. The duration should be configurable, but what's a good default, i.e.,
> what should we try first?

(rolls die) 5 minutes

> 2. Is editing prohibited if another user has since posted another comment

yes, editing shouldn't be allowed if the bug has otherwise changed in any way, including but not limited to comments.

> Conversely, if a user has posted several comments in a row, should only the
> last be editable, regardless of time passed?

for simplicity i think only your most recent comment should be editable.

Comment 2

[Frédéric Buclin]

Wouldn't it make more sense to continue this discussion in existing dupes or in bug 540 itself? There are *tons* of such bugs which have already been reported, and reasons about why this is a good idea or not have already been discussed. Now you are keeping this discussion in a separate thread/bug again. Is that a way to avoid comments or reasoning from other people?

For instance, should the diff of the comment be stored in the DB (bugs_activity table)? Are you allowed to edit the whole comment to write something completely new (or how to write spam without triggering bugmail)? Shouldn't bugmail be sent again as you can entirely rewrite your comment? etc...

Comment 3

[Mark Côté [:mcote]]

Not setting this as an official goal after all.

(In reply to Frédéric Buclin from comment #2)
> Wouldn't it make more sense to continue this discussion in existing dupes or
> in bug 540 itself? There are *tons* of such bugs which have already been
> reported, and reasons about why this is a good idea or not have already been
> discussed. Now you are keeping this discussion in a separate thread/bug
> again. Is that a way to avoid comments or reasoning from other people?

Bug 540 is a mess, but the final comments appear to be coalescing around merging the EditComments extension into upstream, or at least verifying that all necessary hooks are there.  There are many other proposals there too.  It seemed logical to split a specific one out into another bug.  I admit we should have linked to this bug as we did with other, related fixes; I've just done that now.

As for technical details, I'll let glob reply, but as I mentioned, this will probably wait a bit longer, after the bug-modal stuff has further improvements.

Comment 4

[:glob ✱]

(In reply to Frédéric Buclin from comment #2)
> For instance, should the diff of the comment be stored in the DB (bugs_activity table)?

no - the bugs_activity cannot store long values.

i plan on storing just that comment was edited in the bugs_activity table, and storing the full text history of comments in a separate table.  there will also be an indicator in the comment's header that it has been edited which will link to the history.

> Are you allowed to edit the whole comment to write something completely new?

yes.

there's already a preference which allows users to receive notifications for bug changes even if the changer checked the "minor change, don't email" checkbox.  ninja edits would fall into the same category and would still trigger bugmail for people who have opted in to that funnel.



there _is_ a strong demand for comment editing, and we're not going to find a solution which deal with all situations perfectly.  ninja-edits covers most of the requirements of our users, especially when using in conjunction with a fully editable custom field for text that require constant updating (called "user story" on bmo), and the editcomments extension to allow admins to deal with spam/privacy/security issues.

Comment 5

[Frédéric Buclin]

(In reply to Byron Jones ‹:glob› from comment #4)
> and storing the full text history of comments in a separate table.

And so this defeats the possibility to edit comments to remove confidential data (something which was mentioned by myk, IIRC), because confidential data will be stored anyway. That's generally why some bugs or comments remain private even after the bug has been fixed, to never disclose the confidential data they contain.


> there _is_ a strong demand for comment editing

The important point here is that once the bug has been edited again, or after X minutes, the existing comments must not be editable anymore. I know you told this in comment 1, but I want to emphasize it once more. :)

For example, JIRA lets you edit comments even after new comments or other changes have been made, and so I started editing some of my old comments to bring more information requested by the bug assignee. But then, when you read the thread again, you realize that subsequent comments become irrelevant, because they are no longer in a chronological order. The bug quickly became a real mess.

Comment 6

[:glob ✱]

(In reply to Frédéric Buclin from comment #5)
> And so this defeats the possibility to edit comments to remove confidential
> data (something which was mentioned by myk, IIRC), because confidential data
> will be stored anyway. That's generally why some bugs or comments remain
> private even after the bug has been fixed, to never disclose the
> confidential data they contain.

that use-case is covered by the editcomments extension -- bmo admins have the ability to edit comments to remove sensitive information, and this has been used to remove sensitive information prior to making a bug public.

Comment 7

[Jonathan French (:jfrench)]

(In reply to Byron Jones ‹:glob› from comment #1)
> 
> > 1. The duration should be configurable, but what's a good default, i.e.,
> > what should we try first?
> 
> (rolls die) 5 minutes

Wondering if we should reset the 5 minute timer on subsequent edits, _if they happen in that first 5min window? So if the user does their '2nd' edit, they have _another 5 minute window in which to tweak it further, and so on until they don't touch the record for 5 minutes. I doubt that will get abused but it might prevent unexpected UX where they run out of time.

Maybe we could provide some little blue font awesome fa-clock-o or similar in the top right of a committed comment, to cue the user. eg.

[Edit (fa-clock)] Comment 8 [wrap][tag][reply][-]

..with a title of some kind on hover.. "Editable for the next n-minutes".

Then remove it on any page reload after that comment is locked, dynamically remove it, etc.

Unrelated - I wonder how frequently a different user will post a quick reply to a bug, while the commenter is busy doing their 5min edit, only to discover when they try to save their edit, they can't. That's the only snag I can see with the business rule of preventing an edit if another comment has been added.

Comment 8

[:glob ✱]

(In reply to Jonathan French (:jfrench) from comment #7)
> > > 1. The duration should be configurable, but what's a good default, i.e.,
> > > what should we try first?
> > 
> > (rolls die) 5 minutes
> 
> Wondering if we should reset the 5 minute timer on subsequent edits if
> they happen in that first 5min window?

great question.  it think it should be "5 minutes from your last edit", not "5 minutes from the comment's initial creation time".

> Maybe we could provide some little blue font awesome fa-clock-o or similar
> in the top right of a committed comment, to cue the user. eg.

i think a tooltip on the edit button makes more sense - ideally editing comments should be an exception so it isn't something we should explicitly draw attention to.

> Unrelated - I wonder how frequently a different user will post a quick reply
> to a bug, while the commenter is busy doing their 5min edit, only to
> discover when they try to save their edit, they can't. That's the only snag
> I can see with the business rule of preventing an edit if another comment
> has been added.

that would result in our normal mid-air collision page.  i agree it may be painful, but allowing unrestrained editing of comments is undesirable.  the work around is for the user to tag their initial comment as 'obsolete' and post a new comment with corrections (which may be impacted by the new activity on the bug).

Comment 11

[Jörn Hees]

Reading your 2.5 year old considerations, editing bugs and comments is industry standard (just look at github, bitbucket and gitlab). People make mistakes and your standard bug report form doesn't even provide a "preview" (ok, at least comments do). File uploads might fail late due to size (not that one could tell this in advance or anything), leaving you with ridiculous reports like bug 1419138.

Also please acknowledge that people (like me) coming here to report bugs are nowadays just used to such a feature.

Wrt. consistency problems:
The whole discussion shows that you don't trust your reporters. You're more worried about consistency than usability for them.
How often do you honestly think such conflict or evil behavior will happen? Just look at the timestamps of your comments!

That said:
Set the grace period to 15 minutes for bug reports and 10 for comments.

NEVER make a reporter invest time and then lose their work for being blocked by a timeout, they'll very likely just walk away and never return. So either every started edit is allowed or you show a well visible countdown on the edit page! Lost work is a usability nightmare (and i can't believe it's even suggested as a solution).

If there's another comment within the grace period, why not simply rely on them being able to change as well? Simple to implement, won't cause a problem in 99.99% of the time. If you're worried about emails not being in sync with the reports: maybe simply also delay sending out emails till the grace period expires.

Optimize the interface so the reporter feels empowered, not as if they enter some kind of bureaucracy hell.

Comment 12

[Kohei Yoshino [:kohei]]

WONTFIXing this bug in favour of Bug 1484892, as per a conversation on IRC. To summarize: 

* There are some uses cases where users want to update an old comment, such as a dead mailing list link, as pointed out during my interview with the DevTools team [1]
* Other sites like GitHub or Facebook don’t have such a limitation
* Admins will probably be getting a lot of comment editing requests if we introduce a timer

[1] https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-6-Roadmap

Comment 13

[Kohei Yoshino [:kohei]]

I mean https://github.com/bugzilla/bugzilla-ux/wiki/Hearing-from-DevTools-team