@proceedings {1521,
	title = {It{\textquoteright}s Not a Bug, It{\textquoteright}s a Feature: How Misclassification Impacts Bug Prediction},
	year = {2013},
	month = {05/2013},
	pages = {392-401},
	abstract = {In a manual examination of more than 7,000 issue reports from the bug databases of five open-source projects, we found 33.8\% of all bug reports to be misclassified{\textemdash}that is, rather than referring to a code fix, they resulted in a new feature, an update to documentation, or an internal refactoring. This misclassification introduces bias in bug prediction models, confusing bugs and features: On average, 39\% of files marked as defective actually never had a bug. We discuss the impact of this misclassification on earlier studies and recommend manual data validation for future studies.},
	keywords = {bias, bug reports, data quality, mining software repositories, noise},
	author = {Kim Herzig and Sascha Just and Zeller, Andreas}
}
@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}
}
