@conference {WeiBgerber:2008:SPG:1370750.1370767,
	title = {Small patches get in!},
	booktitle = {Proceedings of the 2008 international working conference on Mining software repositories},
	series = {MSR {\textquoteright}08},
	year = {2008},
	month = {05/2008},
	pages = {67{\textendash}76},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {While there is a considerable amount of research on analyzing the change information stored in software repositories, only few researcher have looked at software changes contained in email archives in form of patches. In this paper we look at the email archives of two open source projects and answer questions like the following: How many emails contain patches? How long does it take for a patch to be accepted? Does the size of the patch influence its chances to be accepted or the duration until it gets accepted? Obviously, the answers to these questions can be helpful for the authors of patches, in particular because some of the answers are surprising.},
	keywords = {case study, cvs, email, email archives, flac, mailing list, openafs, patch acceptance, patches, revision control, scm},
	isbn = {978-1-60558-024-1},
	doi = {http://doi.acm.org/10.1145/1370750.1370767},
	url = {http://doi.acm.org/10.1145/1370750.1370767},
	attachments = {https://flosshub.org/sites/flosshub.org/files/p67-weissgerber.pdf},
	author = {Wei{\ss}gerber, Peter and Neu, Daniel and Diehl, Stephan}
}
@conference {WeiBgerber:2006:RLE:1137983.1138011,
	title = {Are refactorings less error-prone than other changes?},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {112{\textendash}118},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Refactorings are program transformations which should preserve the program behavior. Consequently, we expect that during phases when there are mostly refactorings in the change history of a system, only few new bugs are introduced. For our case study we analyzed the version histories of several open source systems and reconstructed the refactorings performed. Furthermore, we obtained bug reports from various sources depending on the system. Based on this data we identify phases when the above hypothesis holds and those when it doesn{\textquoteright}t.},
	keywords = {argouml, bug reports, bugs, change history, jedit, junit, re-engineering, refactoring, reverse engineering, software evolution, version control},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138011},
	url = {http://doi.acm.org/10.1145/1137983.1138011},
	attachments = {https://flosshub.org/sites/flosshub.org/files/112AreRefactorings.pdf},
	author = {Wei{\ss}gerber, Peter and Diehl, Stephan}
}
@conference {WeiBgerber:2006:MRA:1137983.1138028,
	title = {Mining refactorings in ARGOUML},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	note = {"To see if refactorings in ARGOUML have an effect on the occurrence of new bugs and on communication between the developers, we relate the refactorings to bug reports in ISSUEZILLA respectively to mails on the developer mailing list. "},
	pages = {175{\textendash}176},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {In this paper we combine the results of our refactoring reconstruc- tion technique with bug, mail and release information to perform process and bug analyses of the ARGOUML CVS archive.},
	keywords = {argouml, bug tracking, bugs, cvs, email, evolution, mining challenge, msr challenge, re-engineering, refactoring, release history},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138028},
	url = {http://doi.acm.org/10.1145/1137983.1138028},
	attachments = {https://flosshub.org/sites/flosshub.org/files/175MiningRefactorings.pdf},
	author = {Wei{\ss}gerber, Peter and Diehl, Stephan and G{\"o}rg, Carsten}
}
@conference {Gorg:2005:EDR:1083142.1083148,
	title = {Error detection by refactoring reconstruction},
	booktitle = {Proceedings of the 2005 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}05},
	year = {2005},
	pages = {29-33},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {In many cases it is not sufficient to perform a refactoring only at one location of a software project. For example, refactorings may have to be performed consistently to several classes in the inheritance hierarchy, e.g. subclasses or implementing classes, to preserve equal behavior.In this paper we show how to detect incomplete refactorings - which can cause long standing bugs because some of them do not cause compiler errors - by analyzing software archives. To this end we reconstruct the class inheritance hierarchies, as well as refactorings on the level of methods. Then, we relate these refactorings to the corresponding hierarchy in order to find missing refactorings and thus, errors and inconsistencies that have been introduced in a software project at some point of the history.Finally. we demonstrate our approach by case studies on two open source projects.},
	keywords = {bugs, class, inheritance, jedit, refactoring, tomcat},
	isbn = {1-59593-123-6},
	doi = {http://doi.acm.org/10.1145/1082983.1083148},
	url = {http://doi.acm.org/10.1145/1082983.1083148},
	attachments = {https://flosshub.org/sites/flosshub.org/files/29ErrorDetection.pdf},
	author = {G{\"o}rg, Carsten and Wei{\ss}gerber, Peter}
}
