user should be able to remove comments when no followups are present
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Confirmed
|
Undecided
|
Unassigned | ||
Bug Description
If a user is the author of the last N comments on a bug, and there are no further comments after that by anyone else, then that user should be able to remove any subset (including all) of those N comments, because there is no danger of making someone else's later comment obsolete by doing so.
For example, I recently made an accidental comment here:
https:/
I had no way to remove it, even though I realized my mistake immediately. So I followed up with another comment saying:
"Aaaaaaaargh. Commented in wrong bug, please ignore above."
I should just be able to remove the original comment right away, and for that matter my followup comment too. No subsequent commenter has commented yet, after all (that may no longer be true by the time you read this, of course). While some emails have gone out with my comments, more emails could be sent out when I delete them, so that the email record would be clear that they were later deleted.
This is similar to bug #1734 ("need ability to mark bug comments as obsolete"), but in this case I'm talking about actual deletion. However, even just being able to mark them as obsolete or accidental would be an improvement.
| Emmet Hikory (persia) wrote | #1 |
| Karl Fogel (kfogel) wrote | #2 |
| Launchpad Janitor (janitor) wrote | #3 |
| Changed in launchpad: | |
| status: | New → Confirmed |
I disagree that this is any different than any other case of unexpected comment. Bugmail has gone out. People or systems may be replying to the bugmail at the time the comment is removed (or commenting using the web, for that matter). The current system of removing comments through administrative action only in certain cases is not overly onerous, and it's no more trouble to ignore a comment after seeing "Please ignore comment #14" than "Comment #14 was deleted", except that under race conditions, the context is preserved.
An implementation like bug #1734 is much more interesting, because the UI can hide them to ease ignoring stuff. An implementation like bug #80895 is alternately interesting, as one could postpone sending the bugmail during the edit period, giving the user a bit of time to come up with something interesting to say instead of what ever they originally said (even if this ends up only being "me too" or some such).
An implementation like bug #33796 is probably most robust, as it would let the user avoid an unexpected comment in the first place, but it makes it harder to add a comment when this isn't a mistake, which impact may be worth discussing there (also see duplicates of 33796).