>IMHO there are no bad ideas here. They are just mistimed ;-) It would be mad to change the bug policy now, but for the future it might have an impact.
2013/6/21 Rob Weir <robw...@apache.org> > On Fri, Jun 21, 2013 at 11:09 AM, Sub Phil <phil40...@gmail.com> wrote: > > 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). > > > > Metrics like this could be useful if we're measuring defects not > defect reports. Unfortunately the duplicates, plus the "how do I?" > and other non-defects that users enter , make this difficult to > estimate. My impression is that close to half of the Bugzilla reports > are invalid. We'd need to do a major clean up of Bugzilla before we > even knew how many actual defects are there. > > > "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." > > > > To the extent that rated priority is a motivation to volunteers, this > is true. But we have all sorts of volunteers. I think some of them > have enough stress in their real lives that they don't want to take > "high priority" issues and world rather work on lower priority ones, > where there is less urgency. > > Also, much of this depends on where we are in the release. Once we > have completed regression testing we want to avoid introducing > additional risk. So it is no longer "open season" for fixing just any > defect. We need to weigh the risks involved. In many cases, for less > serious bugs, we fix them in a later release, so they can undergo a > full test pass. > > > 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. > > > > Prioritization is not despair. It is just acknowledging that changing > the code after testing has completed is risky, and that we should only > make changes now where absolutely necessary. Despair is what users > feel when we don't show such precautions and see a last minute fix > introduce a serious bug that is not caught before release. > > > 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. > > > > This is a good practice to follow, before the main test pass > completes. After than we intentionally aim to minimize the changes to > the code. Otherwise we don't have a good sense of what the quality is > we're release. > > Bugs are bad, but with testing we can at least have a degree of > confidence that there are no defects above a certain severity level. > If we make unrestrained changes after the test pass then our degree of > confidence is reduced or eliminated. > > > "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...) > > > > I know it can be frustrating as a tester to see defects you reported > go unfixed in a release. I've been there. > > > 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. > > > > All good ideas. But we do need to respect where we are in the release > cycle for AOO 4.0. Main testing is done. Main bug fixing is done. > We're not going back to do feature work, clean up or whatever for this > release. We're fixing a few remaining severe issues in preparation > for release. The time to suggest specific other bugs for this > release was many months ago. Of course, this is a great time to > suggest specific bugs for AOO 4.1. Along with feature work for AOO > 4.1 it would be great if we could identify priority bugs to fix in > that release, so fixes could be integrated into the release before the > AOO 4.1 test passes conclude. > > IMHO there are no bad ideas here. They are just mistimed ;-) > > Regards, > > -Rob > > > 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 > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org > For additional commands, e-mail: qa-h...@openoffice.apache.org > >
