Hi all contributors of Jakarta,
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 Jakarta 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 Jakarta 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. -- *************************************************************************** A. Gunes Koru Research Assistant, Ph.D. Student Southern Methodist University Computer Science and Engineering Department 6425 North Ownby Drive Science and Information Building Room 317 Dallas, TX 75205 Home: 214 691 5633 Work: 214 768 2005 Cell: 214 893 7311 http://www.seas.smu.edu/~gkoru Email: [EMAIL PROTECTED] *************************************************************************** -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
