@proceedings {1467,
	title = {A Linguistic Analysis on How Contributors Solve Software Problems in a Distributed Context},
	volume = {378},
	year = {2012},
	note = {"... a sample of 4109 bug reports was extracted from Bugzilla bug report repository"
"The analysis of our sample allows identifying the roles of participants in this activity according to their hierarchical statutes in the community. "
"we look statistically at words that people use in Bugzilla to discern differences in the discourse and representation between participants (core and periphery)"},
	month = {09/2012},
	pages = {322-330},
	publisher = {IFIP AICT,  Springer},
	abstract = {There is a little understanding of distributed solving activities in Open Source communities. This study aimed to provide some insights in this way. It was applied to the context of Bugzilla, the bug tracking system of Mozilla community. This study investigated the organizational aspects of this meditated, complex and highly distributed context through a linguistic analysis method. The main finding of this research shows that the organization of distributed problem-solving activities in Bugzilla isn{\textquoteright}t based only on the hierarchical distribution of the work between core and periphery participants but on their implication in the interactions. This implication varies according to the status of each one participant in the community. That is why we distinguish their roles, as well as, the established modes to manage such activity.},
	keywords = {bug report, bugzilla, linguistic, text mining},
	author = {Masmoudi, H{\'e}la and Boughzala, Imed}
}
@conference {961,
	title = {Do stack traces help developers fix bugs?},
	booktitle = {2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010)2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010)},
	year = {2010},
	pages = {118 - 121},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {A widely shared belief in the software engineering community is that stack traces are much sought after by developers to support them in debugging. But limited empirical evidence is available to confirm the value of stack traces to developers. In this paper, we seek to provide such evidence by conducting an empirical study on the usage of stack traces by developers from the ECLIPSE project. Our results provide strong evidence to this effect and also throws light on some of the patterns in bug fixing using stack traces. We expect the findings of our study to further emphasize the importance of adding stack traces to bug reports and that in the future, software vendors will provide more support in their products to help general users make such information available when filing bug reports.},
	keywords = {bug fixing, bug report, debugging, eclipse, stack trace},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463280},
	attachments = {https://flosshub.org/sites/flosshub.org/files/118-10-msr.pdf},
	author = {Schroter, Adrian and Schr{\"o}ter, Adrian and Bettenburg, Nicolas and Premraj, Rahul}
}
@article {10.1109/TSE.2010.63,
	title = {What Makes a Good Bug Report?},
	journal = {IEEE Transactions on Software Engineering},
	volume = {36},
	year = {2010},
	note = {"o find out which matter most, we asked 872 devel-
opers from the APACHE, ECLIPSE, and MOZILLA projects to:
1. Complete a survey on important information in bug reports and the problems they faced with them. We received a total of 156 responses to our survey (Section 2 and 3).
2. Rate the quality of bug reports from very poor to very good on a five-point Likert scale [22]. We received a total of 1,186 votes for 289 randomly selected bug reports (Section 4).
In addition, we asked 1,354 reporters1 from the same projects to complete a similar survey, out of which 310 responded. "},
	pages = {618-643},
	publisher = {IEEE Computer Society},
	address = {Los Alamitos, CA, USA},
	abstract = {In software development, bug reports provide crucial information to developers. However, these reports widely differ in their quality. We conducted a survey among developers and users of APACHE, ECLIPSE, and MOZILLA to find out what makes a good bug report.
The analysis of the 466 responses revealed an information mis- match between what developers need and what users supply. Most developers consider steps to reproduce, stack traces, and test cases as helpful, which are at the same time most difficult to provide for users. Such insight is helpful to design new bug tracking tools that guide users at collecting and providing more helpful information.
Our CUEZILLA prototype is such a tool and measures the quality of new bug reports; it also recommends which elements should be added to improve the quality. We trained CUEZILLA on a sample of 289 bug reports, rated by developers as part of the survey. In our experiments, CUEZILLA was able to predict the quality of 31{\textendash}48\% of bug reports accurately.},
	keywords = {bug report, Survey},
	issn = {0098-5589},
	doi = {http://doi.ieeecomputersociety.org/10.1109/TSE.2010.63},
	url = {http://dl.acm.org/citation.cfm?id=1453146},
	attachments = {https://flosshub.org/sites/flosshub.org/files/bettenburg-fse-2008.pdf},
	author = {Zimmermann, Thomas and Premraj, Rahul and Bettenburg, Nicolas and Sascha Just and Schroter, Adrian and Weiss, Cathrin}
}
@conference {Wang:2008:ADD:1368088.1368151,
	title = {An approach to detecting duplicate bug reports using natural language and execution information},
	booktitle = {Proceedings of the 30th international conference on Software engineering},
	series = {ICSE {\textquoteright}08},
	year = {2008},
	pages = {461{\textendash}470},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {An open source project typically maintains an open bug repository so that bug reports from all over the world can be gathered. When a new bug report is submitted to the repository, a person, called a triager, examines whether it is a duplicate of an existing bug report. If it is, the triager marks it as DUPLICATE and the bug report is removed from consideration for further work. In the literature, there are approaches exploiting only natural language information to detect duplicate bug reports. In this paper we present a new approach that further involves execution information. In our approach, when a new bug report arrives, its natural language information and execution information are compared with those of the existing bug reports. Then, a small number of existing bug reports are suggested to the triager as the most similar bug reports to the new bug report. Finally, the triager examines the suggested bug reports to determine whether the new bug report duplicates an existing bug report. We calibrated our approach on a subset of the Eclipse bug repository and evaluated our approach on a subset of the Firefox bug repository. The experimental results show that our approach can detect 67\%-93\% of duplicate bug reports in the Firefox bug repository, compared to 43\%-72\% using natural language information alone.},
	keywords = {bug report, duplicate bug report, execution information, information retrieval, natural language},
	isbn = {978-1-60558-079-1},
	doi = {10.1145/1368088.1368151},
	url = {http://doi.acm.org/10.1145/1368088.1368151},
	author = {Wang, Xiaoyin and Zhang, Lu and Xie, Tao and Anvik, John and Sun, Jiasu}
}
@conference {Herraiz:2008:TSB:1370750.1370786,
	title = {Towards a simplification of the bug report form in eclipse},
	booktitle = {Proceedings of the 2008 international working conference on Mining software repositories},
	series = {MSR {\textquoteright}08},
	year = {2008},
	pages = {145{\textendash}148},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {We believe that the bug report form of Eclipse contains too many fields, and that for some fields, there are too many options. In this MSR challenge report, we focus in the case of the severity field. That field contains seven different levels of severity. Some of them seem very similar, and it is hard to distinguish among them. Users assign severity, and developers give priority to the reports depending on their severity. However, if users can not distinguish well among the various severity options, they will probably assign different priorities to bugs that require the same priority. We study the mean time to close bugs reported in Eclipse, and how the severity assigned by users affects this time. The results shows that classifying by time to close, there are less clusters of bugs than levels of severity. We therefore conclude that there is a need to make a simpler bug report form.},
	keywords = {bug fixing, bug report, bug tracking system, classification, eclipse, msr challenge, severity},
	isbn = {978-1-60558-024-1},
	doi = {http://doi.acm.org/10.1145/1370750.1370786},
	url = {http://doi.acm.org/10.1145/1370750.1370786},
	author = {Herraiz, Israel and Daniel M. German and Jesus M. Gonzalez-Barahona and Gregorio Robles}
}
@conference {Anvik:2006:FTB:1134285.1134336,
	title = {Who should fix this bug?},
	booktitle = {Proceedings of the 28th international conference on Software engineering},
	series = {ICSE {\textquoteright}06},
	year = {2006},
	pages = {361{\textendash}370},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Open source development projects typically support an open bug repository to which both developers and users can report bugs. The reports that appear in this repository must be triaged to determine if the report is one which requires attention and if it is, which developer will be assigned the responsibility of resolving the report. Large open source developments are burdened by the rate at which new bug reports appear in the bug repository. In this paper, we present a semi-automated approach intended to ease one part of this process, the assignment of reports to a developer. Our approach applies a machine learning algorithm to the open bug repository to learn the kinds of reports each developer resolves. When a new report arrives, the classifier produced by the machine learning technique suggests a small number of developers suitable to resolve the report. With this approach, we have reached precision levels of 57\% and 64\% on the Eclipse and Firefox development projects respectively. We have also applied our approach to the gcc open source development with less positive results. We describe the conditions under which the approach is applicable and also report on the lessons we learned about applying machine learning to repositories used in open source development.},
	keywords = {bug fixing, bug report, bug report assignment, bug triage, eclipse, Firefox, gcc, issue tracking, machine learning, problem tracking},
	isbn = {1-59593-375-1},
	doi = {10.1145/1134285.1134336},
	url = {http://doi.acm.org/10.1145/1134285.1134336},
	author = {Anvik, John and Hiew, Lyndon and Murphy, Gail C.}
}
@article {1095,
	title = {High Quality and Open Source Software Practices},
	journal = {Proceedings of the 2nd ICSE Workshop on Open Source},
	year = {2002},
	note = {"We examined the publicly visible portions of these projects from November 2001 through March 2002, ...The SLOC counts for the predominate languages are shown},
	month = {2002},
	abstract = {Surveys suggest that, according to various metrics, the quality and dependability of today{\textquoteright}s open source software is roughly on par with commercial and government developed software. What are the prospects for advancing to much higher levels of quality in open source software? More specifically, what attributes must be possessed by quality-related interventions for them to be feasibly adoptable in open source practice? In order to identify some of these attributes, we conducted a preliminary survey of the quality practices of a number of successful open source projects. We focus, in particular, on attributes related to adoptability by the open source practitioner community.},
	keywords = {apache, bug report, bug tracker, bug tracking system, feature requests, gcc, gnome, kde, lines of code, linux, loc, mozilla, netbeans, perl, position paper, python, sloc, source code, Survey, tomcat, xfree86},
	attachments = {https://flosshub.org/sites/flosshub.org/files/HalloranScherlis.pdf},
	author = {T. Halloran and W. Scherlis}
}
