Bug handling survey - Tree based models
Hello FOP contributors, I am conducting a survey about the way bugs are handled in open source software projects. The survey includes questions that can be answered by developers,testers, bug fixers, project managers, and owners of defect databases. It is only and only for research purposes and it is very easy to fill out. It consists of three short sections which can be completed at once or in different sessions. Please fill it out if you haven't done yet. You will find the questions interesting since there is a reason behind each one one of them. They will make you think about how things work (or could work)in your project. The survey can be found in the address: http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html The data in the bug databases can be used to identify the high risk areas in the software development. One of the ways of doing it is constructing tree-based models, which could be very useful in open source projects. If you would like to read about it, I prepared a web page for you: http://www.seas.smu.edu/~gkoru/surveys/tbdm1.html Please accept my apologies if you receive duplicates of this e-mail. This is a survey, which will give useful results for all of us. I will try to prepare and make some preliminary results on-line within the next two weeks. Since this is a survey, covering many important open source projects, it will be interesting for everybody to see what kind of quality assurance work is going on in the other projects. As always, we are very dedicated to this research. Please contact me for any question you might have. Thank you, A. Gunes Koru http://www.engr.smu.edu/~gkoru - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Bug handling survey - 80:20 rule
Hi all contributors of FOP, As you might have heard, I am conducting a bug handling survey on: http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html So far, we have received answers from the developers, testers, defects fixers, and project managers in KDE, GNOME, Apache, OpenOffice, Mozilla, and other projects/sub-projects. Even though, we have not asked any names or e-mails, some of you have left their contact information and expressed their willingness for further cooperation in this direction. Thanks for your interest so far. If you have not done so, we would appreciate it, if you could fill out this survey since statistically more and more meaningful interpretations can be made as your participation increases. It is a short survey which consists of three sections that can be filled at once or different sessions. Many of the questions in the survey were put there purposefully, and they will make you think about how they apply to FOP project. You will find them very interesting. One more time, this is a research project,which has many potential implications. This is NOT anything like a spam, it has no commercial nature and it is aiming to contribute to FOP just like any other e-mail. We are very dedicated to this research, whose only and only purpose is looking for ways of increasing the quality of open source products. We apologize in advance if you receive duplicates of this e-mail. 80:20 rule, which is the subject of this e-mail is a well observed phenomenon, in many of the large scale software products. These products were produced by IT, Telecom companies, even by NASA. They were developed following different methodologies, they were written in different languages, and the application domain or problems they solve were different. However, 80:20 rule was still observed. This means that you might be developing desktop applications, office software, compiler, kernel, http server, or whatever, most likely you will make a similar observation your project. I included two references at the bottom about it. Both of them are very easy to follow and informative. Also, they are very recent references. The numbers in 80:20 rule are percentages but not of the same quantity. 80% here represents 80% of the target risk, which might be defects, rework, effort, etc. So, you want to reduce them. 20% represents the contributor. You might want to name 20% as modules, component, packages, for the product if you will. A great deal of your goal in a project lies in this 80%. And the observations tell us that this 80% target risk stems from 20% of your modules, or components. If you could only identify this 20% part in what you develop, you would make substantial improvements in quality. The identification techniques could be a subject of another time. But, now, why is this important? Because, some projects never get to a desired level of quality, they can not meet their schedule. People code it, patch it, code it, patch it.. After some time users may loose trust, it may become something which is not manageable any more. So even though, the efforts are made by volunteer programmers, it is sad to see that potential is not used fully. Because these efforts could make even greater contribution to free software and they could end the software monopoly out there more quickly. I am one of those who observes the high amount of traffic in developers lists. This is huge. Everybody looks at one thing, sees it from a different point of view, designs are evaluated, code is tested, fixed, etc. Collaborating, sharing bring many advantages. There is big potential. I can easily tell that in many cases the communities are much larger than many software teams in the industry. So, how come the commercial software can still compete with open source products. One of the reasons is that they have been applying these techniques for years. Now think about the advantages of risk identification techniques and the advantages of open source development combined. Wouldn't it be great? This is where we see the tremendous opportunity. As concluding this e-mail, I repeat my invitation one more time. Please visit: http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html today/this weekend and help us in this research. If you want to see or remember my previous invitations, they are at the same address. By the way, if you have already completed it and want to change your answers (some did ask this issue) please contact me, we need to identify your unique entry and change it, please do not complete it twice. Thanks for your support so far. Please contact me for any question you might have. Gunes References: 1) Barry Boehm, and Victor R. Basili, Software defect reduction: Top 10 list, IEEE Computer Magazine, Vol. 34, No.1, pp: 135-137, January 2001. 2) Jeff Tian, Risk identification techniques for defect reduction and quality improvement, Software Quality Professional, 2(2):32-41, Mar 2000
Re: Bug handling
On 2002.04.13 05:33 J.Pietschmann wrote: I'm focusing on the development to fix those bugs, it would be good if someone could put a bit of effort into the bug handling process. I read this as It's ok? That depends on what it is. I don't find it a very effective form of communication under the circumstances and I did say a bit. We could change most of the bugs to won't fix or postpone with the assumption that the current cvs does fix these problems but there won't be a release for a while. So what is the bug list for? To tell users what bugs there are in releases, to tell developers what problems need fixing in development? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Bug handling
Keiron Liddle wrote: We could change most of the bugs to won't fix or postpone with the assumption that the current cvs does fix these problems but there won't be a release for a while. So what is the bug list for? To tell users what bugs there are in releases, to tell developers what problems need fixing in development? From my user's perspective, the most important thing is that I can check the buglist whenever I have a problem. If the problem is known and unfixed, I usually can't wait for the fix anyway and have to do a hotfix or woraround myself.But at least I know it's a bug and can stop searching for a mistake I may have made. Even if no active committer ever looked into the buglist, it'd still be a valuable resource for users. I suppose the biggest problem with the current FOP buglist is that most users are unaware that the current 0.20.3 is a maintenance branch only. This information is not very prominent in the documentation which leads users to expect more from the FOP committers than they realistically can. My two cents. Arnd Beissner -- Cappelino Informationstechnologie GmbH Arnd Beißner Bahnhofstr. 3, 71063 Sindelfingen, Germany Email: [EMAIL PROTECTED] Phone: +49-7031-463458 Mobile: +49-173-3016917 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Bug handling (was: Re: fo:marker broken)
Keiron Liddle wrote: Bug reporting, fixing and handling is of course important to the process. The main problem is that many of the bugs are being fixed in the development but are not easy or appropriate to fix in the maintanence branch. The problem with the bugzilla backlog is that there are quite a few duplicates and already fixed bug in there. In particular, there is half a gadzillion equivalents of the well known OutOfMemoryException stuff, and other recurrent issues. I'm focusing on the development to fix those bugs, it would be good if someone could put a bit of effort into the bug handling process. I read this as It's ok? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Bug handling (was: Re: fo:marker broken)
Bug reporting, fixing and handling is of course important to the process. The main problem is that many of the bugs are being fixed in the development but are not easy or appropriate to fix in the maintanence branch. Having said that we could still do with some better tracking and feedback to bug reports. I'm focusing on the development to fix those bugs, it would be good if someone could put a bit of effort into the bug handling process. On 2002.04.09 21:54 J.Pietschmann wrote: Actually, does someone feel responsible for managing bug reports? There seems to be a loong backlog. I could take a look at it from time to time, in addition to FAQ writing (progress is slow, but measurable). A word from the committers? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
