Closed Bug 531269 Opened 15 years ago Closed 5 years ago

Allow editing of initial comment only ("description")

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement)

Product:
Bugzilla
Component:
Creating/Changing Bugs
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1535000

People

(Reporter: gerv, Unassigned)

Details

From an email from David Ascher:

"The whole concept of bugzilla bug history, w/ the lack of an actual editable state except for the summary, means that it's impossible to record usefully partial progress or consensus.  Wikis are the exact opposite, all about the shared state, and none about the discussion.  I think for feature discussions, we need something in between."

I think we should make "comment #0" (the initial description), and only that comment, editable by anyone who can edit the bug (like any other field). This would work as follows:

- User files bug as normal, with a description
- This initial description is displayed in a "Description" editable <textbox>. 
  (Perhaps click-to-edit)
- If it is ever actually edited, the first version becomes "comment 0", and the 
  current version is shown instead in the textbox.
- From then on, further edits are just reflected in the description field.
- Updates to the description are all reflected in the bug history.

This way, the initial form is never lost and yet you can usefully update the bug to reflect progress or changed ideas without each reader having to synthesize the current state from reading 100+ comments.

The implementation would be a new column in the bugs table, "description", and comments in the comments table would start instead at comment #1. If it were ever edited, before overwriting the old description, it would be copied into the comments table as comment #0 (i.e. with the creation_ts of the bug).

This bug is a limited subset of bug 540, which seems to be about making all comments editable. I think we could do the above much more simply, without any of the UI or implementation complexities that fixing bug 540 would entail, and still get much of the benefit (as outlined by dascher's comment).

Gerv
OS: Android → All
This seems overkill to me. If you want a way to keep progress or consensus in a "central" way without having to read 100+ comments, all you need is a textarea custom field named "progress" or "current status" or I don't know what, and write into it. Shifting comments is a pain for all references to comments. And editing a description seems awkward to me, because all the following comments are based on it, and so you could end with comments finally becoming unrelated to the edited description.

So WONTFIX in favor of a textarea custom field if you need such a feature.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
If we can make that custom area pre-filled with the contents of comment #0, and make it prominent (IOW, way above the fold), then that would work for me.

Here's a great example -- It'd be completely healthy and "right" IMO for this bug to evolve into a new bug with a different main description -- comments 0-2 would be "historical", but "description" would be up do date. People interested in this bug would naturally stay involved, and we'd have that many fewer bugs to track.

For feature requests, the initial formulation of an idea is rarely the right one.  But there's no way for bugzilla to reflect that evolution except through completely new bugs, which is a complexity we don't need.
Is there a possibility we could perhaps discuss this before you close it based on a misunderstanding of what I'm proposing? :-)

The "textarea containing current status" is roughly what I'm proposing, except that it is a textarea containing the current task the bug represents, which is not quite the same thing. The difference is that it's prefilled with the contents of the initial description, which is what the bug initially represents, but then can be modified if the purpose of the bug moves.

> Shifting comments is a pain for all references to comments.

I am not suggesting that comments should shift. Look carefully :-) 

When the bug is filed, it just has this initial description.
If someone adds a comment, that is comment 1. Then comment 2, and so on.
If the description ever gets modified, the initial description becomes comment 0, just as it is now. Comment 1 is still comment 1. Nothing shifts.
So the only difference is that bugs where the description has not been changed don't have a comment 0. (Of course, they could have an <a name="#c0"></a> above the description, if you want to maintain total backward compatibility.)

> And
> editing a description seems awkward to me, because all the following comments
> are based on it, and so you could end with comments finally becoming unrelated
> to the edited description.

...which is exactly why I proposed that if the description is modified, the initial description becomes comment 0. Then, it is directly above the comments which comment on it - exactly where it is now.

I did think about these things, you know :-) This proposal is carefully designed to take into account the objections which are usually raised to the suggestion that the initial comment be editable.

Gerv
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Actually, a simpler implementation is to make the "new description" actually be a new comment, and just hide the old comment and move the "new description" up to the position of Comment 0. This keeps comment text immutable, which is an important design aspect of Bugzilla.

I think that that would be an acceptable implementation that would solve this long-talked-of issue.
Blocks: 540
My design also keeps comment text immutable, for an (I think sane) definition of "comment". But it's great you think we can fix this :-) However, I don't quite understand your proposal.

Are you suggesting that when someone makes a comment, they can click a checkbox which says "this is a new description for this bug", and that comment then moves to the top of the list? Wouldn't that stop comment numbers being immutable? Comments are currently ordered by timestamp, aren't they? Wouldn't that require faking the timestamp of the new description? Wouldn't it confuse people if a new comment suddenly appeared before the initial comment?

I think I've probably misunderstood your suggestion :-)

Gerv
(In reply to comment #5)
> Are you suggesting that when someone makes a comment, they can click a checkbox
> which says "this is a new description for this bug", and that comment then
> moves to the top of the list? 

  Basically, yeah. Or there would be an (edit) link next to the Description that would pre-populate the comment box with the current description and then set it as the new description.

> Wouldn't that stop comment numbers being
> immutable? Comments are currently ordered by timestamp, aren't they? Wouldn't
> that require faking the timestamp of the new description? Wouldn't it confuse
> people if a new comment suddenly appeared before the initial comment?

  It wouldn't stop them from being immutable--we'd just be moving comments around in the UI. In bugmail we'd make it clear that the new comment was a new description, so people wouldn't be too confused. We could also make the timestamp of the Description more prominent, and provide links to unhide the old descriptions beneath it.
This idea looks totally crazy to me. And definitely confusing. I honestly wouldn't want this implementation.
I'm a bit lost.  My 2c is that from a UX POV "initial description" doesn't feel like a comment to users.  

I'd suggest that adding comments (esp. comments 1 and later) should stay "adding a comment", and that editing the description should be a clearly distinct operation, which should happen near the description.  

My first stab at it would be that comment 0 ends up populating the description field on bug creation, and that comment 0 would be collapsed in those (frequent) cases when the description is never changed.  If the description is changed, then comment 0 would be uncollapsed.  (comment 0 could also be marked as "Comment 0 (original description)".
Max, I think your idea requires more UI controls, and I agree with LpSolit that it would be quite confusing. Summarising the current state/goal of the bug, and adding a comment, seem like different operations. And placing comments in non-chronological order is going to confuse people. It'll look like a hack.

If someone adds a multi-line textbox custom field, we don't provide additional "what were the old values of this field?" UI other than the History page. So I don't think we need to do anything more than that if we added a "description" multi-line textbox field.

David: that's basically what I proposed :-) I like the "collapsed" idea for comment 0, though. We'd have to figure out if that would be more understandable than my idea, which was just not to show a comment 0 if the description hadn't changed. On the pro-side, it keeps the comments as now. On the con-side, if people didn't know that collapsed meant "hasn't changed", they might feel the need, once they "discovered" comment 0, to carefully compare the two to look for differences, and then be confused that there weren't any. ("Why is this information here twice?")

Gerv
(In reply to comment #9)
> Max, I think your idea requires more UI controls, and I agree with LpSolit that
> it would be quite confusing.

  I actually don't think it would be confusing at all--I'm not sure how you're imagining the UI, but it would be pretty straightforward, and it isn't necessarily defined by the implementation I'm describing. All I'm really talking about is a backend implementation that would work well for Bugzilla, not about how the UI would work.

> Summarising the current state/goal of the bug, and
> adding a comment, seem like different operations. And placing comments in
> non-chronological order is going to confuse people. It'll look like a hack.

  Well, the comment will be called "Description". I don't see how that will look odd at all. The old descriptions will be hidden, or they won't. They will be out of order, or they won't, as we decide.

> If someone adds a multi-line textbox custom field, we don't provide additional
> "what were the old values of this field?" UI other than the History page. So I
> don't think we need to do anything more than that if we added a "description"
> multi-line textbox field.

  Oh, I'd disagree in this particular case, because descriptions are a bit more valuable than one's typical multi-line textbox.

  I'm coming at this after having implemented versions of David's suggestion already as a customization for various clients--a customization that has always led to implementation difficulties and inconveniences.

(In reply to comment #8)
> I'm a bit lost.  My 2c is that from a UX POV "initial description" doesn't feel
> like a comment to users.  

  Yeah, I can see that.

> I'd suggest that adding comments (esp. comments 1 and later) should stay
> "adding a comment", and that editing the description should be a clearly
> distinct operation, which should happen near the description.  

  That's fine. We can do the UI for it any way that makes the most sense for all Bugzilla users.

> My first stab at it would be that comment 0 ends up populating the description
> field on bug creation, and that comment 0 would be collapsed in those
> (frequent) cases when the description is never changed.  If the description is
> changed, then comment 0 would be uncollapsed.  (comment 0 could also be marked
> as "Comment 0 (original description)".

  Okay. So why not then make each new description an additional comment that happens to be just moved out of order and labeled "Description"? It can have the link "#description" instead of "#c0". And then while we're at it, we could collapse all former descriptions except for the current one, and label them (old description) or something like that.

  I'm not totally bound to that UI, I just think that it would work the best across the many organizations using Bugzilla. Giving people a text box to edit Description that didn't preserve history in a dramatic and obvious way like comments would, I'm pretty sure, given my experience, cause the average organization to stop using comments in the way they're used and to simply just modify the description, possibly even bringing their discussions outside of Bugzilla and eliminating a large part of the usefulness of the tool to the organization (which is that it preserves with great accuracy the entire technical history of an issue's resolution or a feature's implementation).

  I think that what I want most out of it is the ability to quickly know, with a brief summary, what this bug is really currently about. I totally agree that that's necessary and something that Bugzilla is not good at currently, though I tend to use the summary for that, with some effectiveness. I actually only rarely have the need to point out a new comment as the description, but when I want that, I really want it. (Particularly on bugs that become advocacy forums, but that's a whole other issue.) 

  But if that's *all* I want, then simply taking a comment, styling it differently, and moving it out of order would accomplish what I'm looking for--though I agree that the break in comment numbering would be disorienting to novice users (of whom Bugzilla has many, in an open-source situation, because it has many bug reporters and readers) and possibly even to experienced users who didn't know the implementation (and users shouldn't be expected to know the implementation of a feature).
If I understand the problem you could implement this in attachment table style. Ultimate description is always first. Others are available in the Revisions table displayed on demand after you click "Show revisions".  This way we could see the history of changes and details (who, when and why (maybe comment link to put here) changed the original description). Simple.
P.S.
After each change of the description published comments could be seperated by "Bug description changed" line.
See also bug 99242, which I think is close.
It occurred to me that if we don't allow people to un-mark a comment as being the Description, then we can do this entirely without modifying the comment-number sequence. And it would then in fact become my suggested implementation for bug 540, except that only the first comment could be edited.
I would argue that fixing bug 540 is something we actively don't want to do. dascher put it well: there's a balance to be struck between everything being about the current state and not about the conversation (a wiki) and everything being about the conversation and not about the current state (a non-editable discussion board). I think that if we fix this bug, we'll get a good balance between bugs being a record of the development process (the comments), and bugs being a good record of the current state (the description).

The back-end implementation is far less interesting to me than the user experience. In other words, I think we should decide how we want it to work, and then figure out the best way to implement that.

Max's summary of the goal is a good one: "I think that what I want most out of it is the ability to quickly know, with a brief summary, what this bug is really currently about." We all agree on that - we need an editable multi-line text field called the "Description". The questions seem to be:

1) How prominently in the UI do we want to display earlier versions of that summary?
  a) In the History table only
  b) Somewhere more prominent on the main bug page

2) What UI do we want to use for editing that summary?
  a) dedicated text field
  b) add-comment text field, with a repurposing checkbox

My basis for answering these questions is the idea that users will conceptually see the Description as just another field to be edited as they wish. If that is so, then I suggest that the correct answer to question 2) is a). Appending a comment to a discussion, and editing the current state of some text, are different operations.

If they see it as just another field, that also suggests that the correct answer to question 1) is a) also, as that's where previous states of all the other fields are. Although I am open to the suggestion that this field is different because it contains more information than any of the others.

Gerv
I think it seems reasonable to allow editing the original comment and not the later comment. And the implementation would make it pretty easy for people to hack in editing of additional comments if they really wanted it, too.

And yes, the UI would be best as a separate box for editing the description.
Max: do you have a view on the answer to my question 1)?

If you agree that the UI is best as a separate box, what is the advantage of storing the Description in the comments table, as opposed to (like every other single-valued bug field) as a new column in the bugs table?

Gerv
I think that we'll go with 1b. I don't want any large fields like description in the bugs table. Also, it's the least change to the current architecture.
Is this pretty much what http://bzr.mozilla.org/bmo/4.2/files/head:/extensions/UserStory/ ended up implementing?  Or is that something else?
(In reply to Dave Miller [:justdave] (justdave@bugzilla.org) from comment #18)
> Is this pretty much what
> http://bzr.mozilla.org/bmo/4.2/files/head:/extensions/UserStory/ ended up
> implementing?  Or is that something else?

More or less. Given time, we could try to push that upstream.

dkl
No longer blocks: 540
Status: REOPENED → RESOLVED
Closed: 15 years ago → 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.