Bug policy debate and so on.. Well, just sharing experience from as a past developper and notorious bug fighter.
There is no other point in creating a database of bugs and not treating them, than to have an ultra-complicated list of known issues (so complex that users report are duplicated) and frustrated reporters (and testers). "It is no a display of disrespect when a certain bug is not fixed." Yes until you have a list of open bugs, which generated itself a list of duplicates... What matters is the evolution ratio closed / confirmed by release (e.g. 3.4.1) and cumulated version (3.4.x). "I would like to add another one. I am a developer. When I spend time on fixing bugs then I sometimes wish there where a big list of all open bugs that are sorted according to importance. I would go down the list and grab a bug from the top that lies in the area of my expertise (Impress, UI, Slideshow, Sidebar). Without such a list I have to prioritize bugs by myself. And if I do that then I use my own judgement of which bug is important and which is not." This further illustrate the fact that in order to handle these list, one has introduced techniques such as priority and vote for bug. My own experience shows, that all these are not good policy for bug treatment, it's a dispair. Bug should be assigned in groups regarding a feature with final objective in mind. What do I mean by feature. Take for instance in Calc, the pivot table function. All bug regarding pivot table should be treated together, or most of them. Why concentrating? Because: 1/ It takes time to fix a bug, because one needs to understand or re-understand the implementation. "- Fixing a bug usually takes a lot more time and effort than reporting one. Also, often because test case scenario are not narrow enough - see my other post. 2/ By taking all bugs related to a piece of source code, each time you become more familliar and so more efficient. In a sense you proof reading it several times, you get leverage on bug handling. 3/ By reviewing several related bugs, you reduce the risk or regression, as you've been through it several times, each time with a deeper understanding. "The other thing to note is that bug fixes are not risk-free. Studies have shown that 25% of defects in code are side effects of changes". FFmpeg is really a good example for regression, to a point I stopped reporting (first you have to convince it's a bug, then it lays pending to a wish to fix it and then you find older release which works...) 4/ Having fixed a bulk of related feature bugs, report the fix is implemented to all different reporters. They will(hopefully if done in a reasonable time, not like me who got a mail for a bug I posted 2 years ago...) test "their" bug and by doing so improve the total quality control and reduce regression risk. What do I mean by assigning by objective. Well, here is for me where the votes should take place, grouped by user, tester and developer (might have different interests). Suppose, pivot table code is considered as a mess by developpers and ought to be re-written by next release. There is no point in fixing pivot table bug now. Suppose users consider that priority should be assigned in this order 1. fix doc format issues 2. fix grammar check issues It has to be respected and if there is a "critical" bug in another field, well if it will wait. One should not vote for a bug, but rather for an expected behaviour. Phil 2013/6/21 Andre Fischer <awf....@gmail.com> > On 21.06.2013 13:42, Edwin Sharp wrote: > >> Dear Andre >> This is exactly the problem! >> When you grab a bug from the top and critical bugs continuously enter the >> list - >> The minor bugs at the bottom will never get attention. >> > You make that sound like it where a bad thing. > A bug is critical because it affects man users and/or causes data loss > (and one or the other additional property). Therefore it should be fixed > before minor bugs are fixed. > This is how it should work. If it does not then I see two reasons for it: > > - There is not one single sorted list of bugs. Everybody has his or her > own idea of which bug is important and which isn't. > > - The way in which bugs are ordered is not good enough. This ordering is > certainly not easy to define and it will be impossible to define it in a > way that makes everybody happy. But if there where one central list of > ordered bugs then we could at least try. And everybody could help to > improve it. With such a list you have to rely on my judgement or that of > other developers. > > -Andre > > >> On Fri, Jun 21, 2013, at 14:24, Andre Fischer wrote: >> >>> >>> All good ideas. >>> >>> I would like to add another one. I am a developer. When I spend time >>> on fixing bugs then I sometimes wish there where a big list of all open >>> bugs that are sorted according to importance. I would go down the list >>> and grab a bug from the top that lies in the area of my expertise >>> (Impress, UI, Slideshow, Sidebar). Without such a list I have to >>> prioritize bugs by myself. And if I do that then I use my own judgement >>> of which bug is important and which is not. >>> >>> Regards, >>> Andre >>> >>> >>> ------------------------------**------------------------------** >> --------- >> To unsubscribe, e-mail: >> qa-unsubscribe@openoffice.**apache.org<qa-unsubscr...@openoffice.apache.org> >> For additional commands, e-mail: qa-h...@openoffice.apache.org >> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > qa-unsubscribe@openoffice.**apache.org<qa-unsubscr...@openoffice.apache.org> > For additional commands, e-mail: qa-h...@openoffice.apache.org > >
