Tags:
stale_content1Add my vote for this tag create new tag
, view all tags

Bug Item Ping Pong

I have quite often raised a bug report myself, had it discarded, reopened it again arguing why it is really a bug, and then it got fixed. Often I end up fixing the bug myself or analysing the code for hours until I find where the issue is so it takes a core developer 5 minutes to fix it.

So some bug items go from "new" -> "discarded" -> "new" -> "discarded" -> "new" -> "waiting for release".

I call it "Bug Item Ping Pong".

It is a sport I am good at and I tend to win more than I loose. But in the process core developers waste time and I often find myself in a state of anger. This topic tries to address this as I believe I am not the only one with this experience. This is not a topic trying to rant specific individuals. It is an attempt to clarify how to manage the bug items and use the bug states .

So let us try and list the rules for "Bug Item Ping Pong" so it becomes a more fun game to play.

In the Bugs application the discarded state is defined as

  • Discarded the issue was already fixed, or it's a duplicate, or an RTFM.

And whenever someone reports a bug which ...

  • Is already fixed
  • Is a duplicate of another bug item
  • Or the bug report is not a bug but how the feature is supposed to work, as documented
... then there is no doubt that the bug must be discarded.

But bugs are often also being discarded based on

  • I will not be fixing this myself for one good reason or another.
  • You did not provide a test case
  • I do not understand your report
  • I cannot reproduce it
  • I do not agree
  • This is an enhancement, and it needs to be discussed on Codev first.

What KennethLavrsen suggests is

  • If the bug is a bug and you do not feel like fixing it yourself ... leave it open and let someone else give it a try.
  • If the bug is a bug and you find other bugs to be much more urgent then put the priority low.
  • If the bug report is incomplete, or you cannot reproduce it, or you do not understand it ... the "Waiting for feedback" is the right state to choose.

"Waiting for feedback" is defined as: "the report was insufficient to analyse the issue, and more feedback is needed from the reporter. Once the reporter has added feedback they should flip the state back to "New""

Same with reports that need discussion on Codev. The state to use is "Waiting for feedback". (or a new state should be invented for this specific purpose)

If a bug item has been in "Waiting for feedback" and there is no ongoing Codev discussion referred to from the bug item then it is perfectly OK to discard the bug after a week or two. People need to follow up on their bug reports and a "discarded" with the reason "no feedback from reporter" is perfectly adequate and acceptable.

The problem with discarded is

  • Discarded bugs are never returned to again. They fall off the radar screen the minute it is not among the last 10 changed topics.
  • Discarding - when it is not "issue was already fixed, or it's a duplicate, or an RTFM" is easily perceived rude and sometimes even arrogant - even if the developer never intended to be rude or arrogant. When you have been sitting with a problem maybe for hours, and you take the time to write a bug report - then it is easy to get angry when someone just discards it without keeping a door open for more dialog.

So the short message is: Use "discard" less and "waiting for feedback" more.

And to the reporters, please provide feedback within 24 hours. And if the answer you got when the developer flipped it to "Waiting for feedback" means that the bug is not a bug anyway - remember to discard the report yourself as quickly as possible.

If you are a reporter and intend to fix or at least work on it yourself set it to Actioning right when you open it so other developers can focus on something else.

And finally. Those of you that can program Perl at a reasonable level. Do not leave all the bug fixing of core to Crawford! It is fun to code plugins but the core needs attention and I have never heard Crawford say that he should be the only one fixing core bugs. The TWiki core belongs to the TWiki community. All the way from managing feature proposals, coding the feature, coding unit tests, documenting, testing, to fixing the bugs. I recognize that one reason for the high discard rate is lack of resources to maintain the core. And I want to make it clear that I really appreciate the incredible effort Crawford puts into maintaining the core.

-- Contributors: KennethLavrsen - 21 Oct 2006

Discussion

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2006-10-21 - ArthurClemens
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.