Welcome to the FogBugz Knowledge Exchange

Question

11

1

I was pleased to see the Case Event Edit plugin added to FogBugz as of version 7.3. However, I can't say I am entirely satisfied with the way it works. With this plugin, I was looking for, among other things, the ability to clean up a case that has become hard to follow due to excessive edits. You provide the ability to edit case entries. Awesome! You provide a history of the edits and a means to compare any two revisions. Totally awesome! However, with each event edit comes a new case entry (see the entries highlighted in red). Not so awesome.

alt text

It seems to me this just clutters up the case as fast I as try to clean it up. It's obvious that case entries have been edited by the [Edited h:mm A/PM] links that are added to edited case entries (highlighted in green). Is that not enough?

Case FC1897114

edited May 16 2011 at 18:59

Rich Armstrong♦♦
13k●11●29

asked May 10 2010 at 23:37

Greg Saven♦
2,469●1●5●13

	I second that completely (including the awesome parts I and II) and would add that the event "edited" is greatly ambiguous, in this context and should better read "revised by" .. – KJ May 11 2010 at 20:49
	Too bad the image is gone. – Michel de Ruiter♦ Jan 30 at 20:49

KJ · Answer 1 · 2010-05-14 21:21:03Z UTC

4

Appologies for not adding comment but answer. I would like to suggest a solution (even though I am not in the position to make it happen): 1) Drop the "edited" trail entry (drop all the "RED" stuff above), 2) and make the "GREEN" stuff read "revised by" instead. 3) Deal with case event clutter separatly and make this plugin NOT subject to wait to be cleaned-up in greater context only (defeating the iteration cycle for the plugin)

answered May 14 2010 at 21:21

KJ
61●3

I agree with this. Bugevents like these ones by their nature don't have any body text, and so they'll naturally look cluttery. But all the other types of textless events (assigns, state changes, etc) all contribute to the sequential nature of the bug lifecycle, and it's important to be able to say "Bob opened the case", "Alice edited the case with the following text", "Bob assigned the case to Steve", "Steve closed the case with the following text", and so on. Each one fits naturally into the timeline and contributes usefully to the narrative. – Brian Tiemann May 18 2010 at 17:40

But event-edit bugevents don't do that. They're visually separate from the events they pertain to, and anyone trying to mine the edit trail has to skip back and forth in the timeline, and ultimately it doesn't really matter in most cases when or in what stage of the case's life the edit was made. The edit trail should really just be accessible through the green "Edited" links in the screenshot above, not exposed at the top level. And I'm arguing that event edits are fundamentally different from other kinds of textless events in this regard. – Brian Tiemann May 18 2010 at 17:43

I generally agree. We're considering switching to the "silent edit' functionality for CaseEventEdit. That is to say, maintain the audit trail via the history, but don't spawn new events when there's an edit. This has a lot of consequences, though- No emails generation is one of them. In many cases, this seems good, but the generality of C.E.E. is damaged. Might be worth it. I might also take the lame approach and add a configurable switch for silent editing... – Jude Allred♦ May 19 2010 at 17:57

1

+1 for this. The ability to set the default behavior like show/hide event edits, send/don't send emails, etc via the plugin settings would be nice. Plus the ability to override the email option when editing a case would be good. As similar plugin for the Bug itself would be great, too. Allowing someone to modify the bug label, priority, area assigned, milestone, etc. in the same way would help project managers clean up bugs in general without cluttering it up the bug view with every change. – iamgoat May 22 2010 at 15:41

Can't you just generate an email specifically for silent edits, as opposed to lumping it into the same group of "if there has been an entry, email x,y,z people". Kind of strange that you can't code in that kind of functionality (and provide an on/off switch). – Sergei Jun 7 2010 at 19:09

adambox · Answer 2 · 2010-08-11 22:00:10Z UTC

Thanks for all of the extremely useful feedback! It weighs heavily on what future changes will be made to Case Event Edit.

For now, the solution to this problem is the Tidy Case Events plugin (...It was heavily influence by this discussion.)

On "Edited" vs "Revised"... I think it's pretty clear that "Revised" is better. I'll make that tweak next time there's a bugfix.

adambox · Answer 3 · 2010-05-11 19:13:40Z UTC

3

I'm glad to hear you're finding the new plugin useful! As I'm sure you know, design is full of trade-offs and we thought about this one for a while. We decided that the need for a clear audit trail was great enough to justify the extra bugevents. In any case, I will let the FogBugz PM and the engineer who worked on this know about your feedback. Thanks!

answered May 11 2010 at 19:13

adambox♦♦
20.9k●14●46

1

The audit trail is indeed important...perhaps have a way to hide/unhide different classes of edits. A few classes come to mind that many people may or may not care about: Edit edits, attribute change edits, edits with comments, resolution/open-close status changes. If not hiding them, perhaps greatly visually deemphasizing them. – cdeszaq May 13 2010 at 16:15

1

We played with this for a while, and we know some solutions. Our main findings were: 1. BugEvent clutter should be fixed at a greater scope than that of just Case Event Edit, ergo the fix for it is not part of said plugin; 2. Toy examples of event clutter look particularly bad- in practice, pages tend to have much more textual content or interleaving bugevents, so it's more acceptable than initial impressions give (but still poor). In short, I agree with you and it's in our priority queue, but not as an aspect of Caase Event Edit. As always, upvote this question to bump it in our queue ;-) – Jude Allred♦ May 13 2010 at 23:21

My personal opinion is that it is worth the clutter. Say Bob edits a case and writes "This code is great". Sally later edits that event to say "This code is TERRIBLE". One can see it was edited and click the link to see the diffs, but since Sally is changing Bob's words in a pretty huge way, it's nice to a) make that more obvious that Sally made the edit and b) make sure the person to whom the case is currently assigned gets a notification that a change was made (so it's not stealth!) – adambox♦ May 14 2010 at 11:34

1

The Bob - Sally argument I find not convincing; a) the issue at hand is NOT the audit trail - it is instead its cluttery representation; b) in the case Bob and Sally, Sally would not revise Bobs entry but instead add an own real "note" by editing the case not Bobs case event. – KJ May 14 2010 at 21:15

1

Agreed. The need for an audit trail should not decrease the useability for general users. – cdeszaq Aug 12 2010 at 13:06

Don’t add a new case entry for every case entry edit.

3 Answers