DEFECT HANDLING PRACTICES IN OPEN SOURCE PROJECTS

DEFECT HANDLING PRACTICES IN OPEN SOURCE PROJECTS

What is your project name?

Which of the defect tools/databases listed below do you use for your project?

  Apache (<http://nagoya.apache.org/bugzilla>)
  GNOME (<http://bugzilla.gnome.org/>)
  Horde (<http://bugs.horde.org/>)
  KDE(<http://bugs.kde.org/>)
  LyX (<http://bugzilla.lyx.org/>)

  Mandrake (<https://qa.mandrakesoft.com/cgi-bin/index.cgi>)
  Mozilla (<http://bugzilla.mozilla.org/>)
  OpenOffice (www.openoffice.org/issues/query.cgi <http://www.openoffice.org/issues/query.cgi>)
  If another, please give the name of the defect database and its Web address.

Which of the roles below best describe your participation in the project? (choose all that apply)

  Technical Lead
  Software Developer/Engineer
  Technical Documenter

  Project Manager
  Tester
  Other (please explain)

The defects reported in your project include defects in the ... (choose all that apply)

  Requirement documents
  Design documents
  Source code

  Test documents
  Manuals
  Other (please explain)

The defects reported in your projects include ... (choose all that apply)

  Pre release defects
  Post release defects
  Both pre release and post release defects with no distinction

Both pre release and post release defects but put into categories
Any other strategy used regarding pre/post release defects (please explain)

In your current practice, a defect is usually recorded in the bug tracking system due to .... (choose all that apply)

  Any problems found with the requirements
  Any problems found in the design
  Any problems arising out of testing
  Unit testing
  Integration testing
  System testing

  Acceptance testing
  After deployment
  Any problems found in the code through inspection
  Any incorrect part of the software that must be fixed
  Any other types of defect that apply to your project (please explain)

How do you categorize the defects being reported in the bug tracking system that you use? (choose all that apply)

Accumulated for all releases/versions
Defects that have been corrected

Defects which have not been corrected
Other (please explain)

When was the defect database first used in your project?

  Inherited from another project or from a previous release
  Right after the project started
  Right after the design started
  Right after coding started

  Right after pre release testing started
  In the post-release stage
  Other (please explain)

How consistent was the usage of defect the database in your project?

  Very consistent, all defects are reported before being fixed
  Generally consistent, the greater majority of defects are reported
  Generally consistent, but only for major defects

  Not very consistent, intermittently report
  Not consistent at all, defects reported only as time allows, most are not reported
  Other way in which you can describe the level of consistency of reporting defects

How many defects and which type (if applicable) have been reported for the project release under investigation? (please refer email for which release I'm referring to)