Bugzilla “Limitations” 2: Comments Are Permanent

Another “limitation” of Bugzilla is that you can’t edit comments after you’ve submitted them. Someone who wants this ability usually puts forward one or more of the following arguments:

  • What if the comment turns out to be factually wrong?
  • What if I change my mind about something?
  • What about confidential info accidentally added?
  • What if I make a typo?

Editing comments is a bad idea because it is altering history. You said that stuff and, even if you wish you hadn’t, it had an effect on things other people had said. If you revise what you said, and they don’t, then there’s potential for confusion and inconsistency.

I sometimes use another bug tracking system whose comments are basically big textboxes. If you have something to say, you just add it at the bottom and hit Save – but you can also edit, remove or rearrange anything anyone else has said before. (Admittedly, this is an extreme case of comment editing.)

This system has several undesirable effects. The rationale for decisions often gets lost by people “tidying up”. You can’t be certain that you are reading what someone else read before they said what they said.

But what about those initial reasons for permitting it?

  • What if the comment turns out to be factually wrong? – Then add another one and correct it
  • What if I change my mind about something? – Then add another comment with your new view, explaining why you changed your mind
  • What about confidential info accidentally added? – That’s what the “insiders” function is for
  • What if I make a typo? – Type more carefully; everyone knows what you meant anyway

Comment editing, along with any form of history alteration, isn’t necessary and actually decreases the reliability and usability of your bug tracking system. Don’t go there.

6 thoughts on “Bugzilla “Limitations” 2: Comments Are Permanent

  1. Actually, I agree completely here. No matter how dopey the comment is, you said it, it happened, life goes on. Maybe it’ll help reinforce people not saying stupid things…

  2. I think there should be a form at the bottom to notify the admin, on such cases. So the admin could decide.

    Confidential info could be a big problem. If say an Mozilla Contributing company (Mozilla, Redhat, etc. etc.) makes this mistake, and it’s not removed… it could lead to that company eventually pulling out.

    It could also cause contributors to be in a bad position.

    IMHO a little form to report the post, and make it a redline to an admin on duty.

  3. If say an Mozilla Contributing company (Mozilla, Redhat, etc. etc.) makes this mistake, and it’s not removed… it could lead to that company eventually pulling out.

    That’s a bit extreme, don’t you think? There are stages between “oops, we’ve posted something we shouldn’t”, and “we’re leaving the project”.

    In the past, in a small handful of cases, we have secured the bug and cloned it into another one. Exceptional circumstances, exceptional measures. That doesn’t justify comment editing, IMO.

  4. It becomes a bit awkward when you have a contributor who frequently makes mistakes and flip-flops on what’s good and what’s not.

    My own testcases have that in abundance. However, on the whole I largely agree with what you’ve said. I just happen to make it inconvenient for everyone on the cc list…