@article {1920,
	title = {Process Aspects and Social Dynamics of Contemporary Code Review: Insights from Open Source Development and Industrial Practice at Microsoft},
	journal = {IEEE Transactions on Software Engineering},
	volume = {43},
	year = {2017},
	note = {" We sent the survey
to code review participants from 36 popular OSS projects
and received 287 responses"},
	month = {1/2017},
	pages = {56 - 75},
	abstract = {Many open source and commercial developers practice contemporary code review, a lightweight, informal, tool-based code
review process. To better understand this process and its benefits, we gathered information about code review practices via surveys of
open source software developers and developers from Microsoft. The results of our analysis suggest that developers spend
approximately 10-15 percent of their time in code reviews, with the amount of effort increasing with experience. Developers consider
code review important, stating that in addition to finding defects, code reviews offer other benefits, including knowledge sharing,
community building, and maintaining code quality. The quality of the code submitted for review helps reviewers form impressions about
their teammates, which can influence future collaborations. We found a large amount of similarity between the Microsoft and OSS
respondents. One interesting difference is that while OSS respondents view code review as an important method of impression
formation, Microsoft respondents found knowledge dissemination to be more important. Finally, we found little difference between
distributed and co-located Microsoft teams. Our findings identify the following key areas that warrant focused research: 1) exploring the
non-technical benefits of code reviews, 2) helping developers in articulating review comments, and 3) assisting reviewers{\textquoteright} program
comprehension during code reviews.},
	keywords = {code review, commercial projects, peer impressions, Survey},
	issn = {1939-3520},
	doi = {10.1109/TSE.2016.2576451},
	url = {https://amiangshu.com/papers/CodeReview-TSE-2016.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/CodeReview-TSE-2016.pdf},
	author = {Bosu, Amiangshu and Carver, Jeffrey C. and Christian Bird and Orbeck, Jonathan and Chockley, Christopher}
}
@proceedings {export:232407,
	title = {The Uniqueness of Changes: Characteristics and Applications},
	year = {2015},
	month = {05/2015},
	abstract = {Changes in software development come in many forms. Some changes are frequent, idiomatic, or repetitive (e.g. adding checks for nulls or logging important values) while others are unique. We hypothesize that unique changes are different from the more common similar (or non-unique) changes in important ways; they may require more expertise or represent code that is more complex or prone to mistakes. As such, these changes are worthy of study. In this paper, we present a definition of unique changes and provide a method for identifying them in software project history. Based on the results of applying our technique on the Linux kernel and two large projects at Microsoft, we present an empirical study of unique changes. We explore how prevalent unique changes are and characterize where they occur along the architecture of the project. We further investigate developers{\textquoteright} contribution towards uniqueness of changes. We also describe potential applications of leveraging the uniqueness of change and implement two such applications, evaluating the risk of changes based on uniqueness and providing change recommendations for non-unique changes.},
	keywords = {linux kernel},
	url = {http://research.microsoft.com/apps/pubs/default.aspx?id=232407},
	attachments = {https://flosshub.org/sites/flosshub.org/files/MSR-TR-2014-149.pdf},
	author = {Ray, Baishakhi and Meiyappan Nagappan and Christian Bird and Nachiappan Nagappan and Zimmermann, Thomas}
}
@conference {zanjani2015developer,
	title = {Using Developer-Interaction Trails to Triage Change Requests},
	booktitle = {12th Working Conference on Mining Software Repositories (MSR 2015)},
	year = {2015},
	month = {05/2015},
	publisher = {IEEE},
	organization = {IEEE},
	abstract = {The paper presents an approach, namely iHDev, to recommend developers who are most likely to implement incoming change requests. The basic premise of iHDev is that the developers who interacted with the source code relevant to a given change request are most likely to best assist with its resolution. A machine-learning technique is first used to locate source-code entities relevant to the textual description of a given change request. iHDev then mines interaction trails (i.e., Mylyn sessions) associated with these source-code entities to recommend a ranked list of developers. iHDev integrates the interaction trails in a unique way to perform its task, which was not investigated previously. 
An empirical study on open source systems Mylyn and Eclipse Project was conducted to assess the effectiveness of iHDev. A number of change requests were used in the evaluated benchmark. Recall for top one to five recommended developers and Mean Reciprocal Rank (MRR) values are reported. Furthermore, a comparative study with two previous approaches that use commit histories and/or the source-code authorship information for developer recommendation was performed. Results show that iHDev could provide a recall gain of up to 127.27\% with equivalent or improved MRR values by up to 112.5\%.},
	url = {http://www.cabird.com/wp/zanjani2015developer/},
	attachments = {https://flosshub.org/sites/flosshub.org/files/zanjani2015developer.pdf},
	author = {Motahareh Bahrami Zanjani and Kagdi, Huzefa and Christian Bird}
}
@article {1401,
	title = {Clones: what is that smell?},
	journal = {Empirical Software Engineering},
	volume = {17},
	year = {2012},
	month = {8/2012},
	pages = {503 - 530},
	abstract = {Clones are generally considered bad programming practice in software engineering folklore. They are identified as a bad smell (Fowler et al. 1999) and a major contributor to project maintenance difficulties. Clones inherently cause code bloat, thus increasing project size and maintenance costs. In this work, we try to validate the conventional wisdom empirically to see whether cloning makes code more defect prone. This paper analyses the relationship between cloning and defect proneness. For the four medium to large open source projects that we studied, we find that, first, the great majority of bugs are not significantly associated with clones. Second, we find that clones may be less defect prone than non-cloned code. Third, we find little evidence that clones with more copies are actually more error prone. Fourth, we find little evidence to support the claim that clone groups that span more than one file or directory are more defect prone than collocated clones. Finally, we find that developers do not need to put a disproportionately higher effort to fix clone dense bugs. Our findings do not support the claim that clones are really a {\textquotedblleft}bad smell{\textquotedblright} (Fowler et al. 1999). Perhaps we can clone, and breathe easily, at the same time. },
	issn = {1573-7616},
	doi = {10.1007/s10664-011-9195-3},
	author = {Rahman, Foyzur and Christian Bird and Devanbu, Premkumar}
}
@conference {bird2012www,
	title = {Who? What? Where? Examining Distributed Development in Two Large Open Source Projects},
	booktitle = {Proceedings of the Working Conference on Mining Software Repositories},
	year = {2012},
	abstract = {To date, a large body of knowledge has been built up around understanding open source software development. However, there is limited research on examining levels of geographic and organizational distribution within open source software projects, despite many studies examining these same aspects in commercial contexts. We set out to fill this gap in OSS knowledge by manually collecting data for two large, mature, successful projects in an effort to assess how distributed both geographically and organizationally. Both Firefox and Eclipse have been the subject of many studies and are ubiquitous in the areas of software development and internet usage respectively. Further, both receive substantial development contributions from many companies. As such, both are worthy of study in order to understand the development processes that they use, how distributed the projects are, and what, if any, relationship distribution has with quality. To this end, we identified the top contributors that made 95\% of the changes over multiple major releases of Firefox and Eclipse and determined their geographic locations and organizational affiliations. We found that Firefox is very geographically distributed with over a third of its components receiving major contributions from developers on different continents, and that components that are highly distributed have no more defects than those that are not. In contrast, Eclipse is directed and developed largely by one company; with IBM making 96\% of the total commits (49\% coming from one lab in Ottawa, Canada). We further examined the distribution in each project{\textquoteright}s constituent subsystems and report the relationship of pre- and post-release defects with geographic and organizational factors.},
	keywords = {eclipse, Firefox},
	attachments = {https://flosshub.org/sites/flosshub.org/files/bird2012www.pdf},
	author = {Christian Bird and Nachiappan Nagappan}
}
@conference {1306,
	title = {Java generics adoption},
	booktitle = {Proceedings of the 8th working conference on Mining software repositories - MSR {\textquoteright}11},
	year = {2011},
	note = {"we automatically analyzed 20 open source software projects. We analyzed the top {\textquotedblleft}most used{\textquotedblright} projects according to ohloh.net, including only projects with significant amounts of Java code"

"The 20 selected projects were Ant, Azureus, CheckStyle, Commons Collections, Free- Mind, FindBugs, Jetty, JEdit, JDT, JUnit, Eclipse-cs, Hibernate, Log4j, Lucene, Maven, the Spring Frame- work, Squirrel-SQL, Subclipse, Weka, and Xerces."

"In mining the full version histories of these 20 projects, we analyzed the full content of each version of each Java source file, a total of 548,982,841 lines."},
	month = {05/2011},
	pages = {3-12},
	publisher = {ACM Press},
	organization = {ACM Press},
	address = {New York, New York, USA},
	abstract = {Support for generic programming was added to the Java language in 2004, representing perhaps the most significant change to one of the most widely used programming languages today. Researchers and language designers anticipated this addition would relieve many long-standing problems plaguing developers, but surprisingly, no one has yet measured whether generics actually provide such relief. In this paper, we report on the first empirical investigation into how Java generics have been integrated into open source software by automatically mining the history of 20 popular open source Java programs, traversing more than 500 million lines of code in the process. We evaluate five hypotheses, each based on assertions made by prior researchers, about how Java developers use generics. For example, our results suggest that generics do not significantly reduce the number of type casts and that generics are usually adopted by a single champion in a project, rather than all committers.},
	keywords = {commits, generics, java, source code, version history},
	isbn = {9781450305747},
	doi = {10.1145/1985441.1985446},
	author = {Christian Bird and Murphy-Hill, Emerson and Parnin, Chris}
}
@booklet {bird2011scc,
	title = {Sociotechnical Coordination and Collaboration in Open Source Software},
	howpublished = {Proceedings of the 27th IEEE International Conference on Software Maintenance},
	year = {2011},
	publisher = {IEEE},
	abstract = {Over the past decade, a new style of software development, termed open source software (OSS) has emerged and has originated large, mature, stable, and widely used software projects. As software continues to grow in size and complexity, so do development teams. Consequently, coordination and communication within these teams play larger roles in productivity and software quality. My dissertation focuses on the relationships between developers in large open source projects and how software affects and is affected by these relationships. Fortunately, source code repository histories, mailing list archives, and bug databases from OSS projects contain latent data from which we can reconstruct a rich view of a project over time and analyze these sociotechnical relationships. We present methods of obtaining and analyzing this data as well as the results of empirical studies whose goal is to answer questions that can help stakeholders understand and make decisions about their own teams. We answer questions such as {\textquotedblleft}Do large OSS project really have a disorganized bazaar-like structure?{\textquotedblright} {\textquotedblleft}What is the relationship between social and development behavior in OSS?{\textquotedblright}
{\textquotedblleft}How does one progress from a project newcomer to a full-fledged, core developer?{\textquotedblright} and others in an attempt to understand how large, successful OSS projects work and also to contrast them with projects in commercial settings.},
	attachments = {https://flosshub.org/sites/flosshub.org/files/bird2011scc.pdf},
	author = {Christian Bird}
}
@conference {954,
	title = {Clones: What is that smell?},
	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 = {72 - 81},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {Clones are generally considered bad programming practice in software engineering folklore. They are identified as a bad smell and a major contributor to project maintenance difficulties. Clones inherently cause code bloat, thus increasing project size and maintenance costs. In this work, we try to validate the conventional wisdom empirically to see whether cloning makes code more defect prone. This paper analyses relationship between cloning and defect proneness. We find that, first, the great majority of bugs are not significantly associated with clones. Second, we find that clones may be less defect prone than non-cloned code. Finally, we find little evidence that clones with more copies are actually more error prone. Our findings do not support the claim that clones are really a "bad smell". Perhaps we can clone, and breathe easy, at the same time.},
	keywords = {apache, bug fix revisions, bugs, clone, evolution, gimp, nautilus, scm, source code},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463343},
	attachments = {https://flosshub.org/sites/flosshub.org/files/72rahman2010cws.pdf},
	author = {Rahman, Foyzur and Christian Bird and Devanbu, Premkumar}
}
@conference {bird2010lee,
	title = {{Linkster: Enabling Efficient Manual Mining}},
	booktitle = {Demonstration Track, Proceedings of the 17th SIGSOFT Symposium on Foundations of Software Engineering},
	year = {2010},
	note = {"LINKSTER efficiently displays, integrates, and allows inspection and annotation of information from three main sources of data: source code repositories, developer mailing lists archives, and bug tracking databases. LINKSTER requires access to a source code repository for file content and a database which contains the raw mined repository, mailing list, and bug tracking information. All notes and annotations made by the user are also recorded in the database."},
	publisher = {ACM},
	organization = {ACM},
	abstract = {While many uses of mined software engineering data are automatic in nature, some techniques and studies either require, or can be improved, by manual methods. Unfortunately, manually inspecting, analyzing, and annotating mined data can be difficult and tedious, especially when information from multiple sources must be integrated. Oddly, while there are numerous tools and frameworks for automatically mining and analyzing data, there is a dearth of tools which facilitate manual methods. To fill this void, we have developed LINKSTER, a tool which integrates data from bug databases, source code repositories, and mailing list archives to allow manual inspection and annotation. LINKSTER has already been used successfully by an OSS project lead to obtain data for one empirical study.},
	keywords = {artifacts, bug, bug tracking, data mining, email, mailing lists, open source, source code},
	attachments = {https://flosshub.org/sites/flosshub.org/files/bird2010lee.pdf},
	author = {Christian Bird and Adrian Bachman and Rahman, Foyzur and Bernstein, Abraham}
}
@conference {969,
	title = {Validity of network analyses in Open Source Projects},
	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},
	note = {"We have mined archival records of developer mailing lists to generate reply-to social networks for the three OSS projects: Apache, MySQL, and Perl."

"For each of these projects, we construct an information flow network based on messages that are sent as replies to previous messages....We use this methodology on all mined data to create a network of mailing list participants. "},
	pages = {201 - 209},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {Social network methods are frequently used to analyze networks derived from Open Source Project communication and collaboration data. Such studies typically discover patterns in the information flow between contributors or contributions in these projects. Social network metrics have also been used to predict defect occurrence. However, such studies often ignore or side-step the issue of whether (and in what way) the metrics and networks of study are influenced by inadequate or missing data. In previous studies email archives of OSS projects have provided a useful trace of the communication and co-ordination activities of the participants. These traces have been used to construct social networks that are then subject to various types of analysis. However, during the construction of these networks, some assumptions are made, that may not always hold; this leads to incomplete, and sometimes incorrect networks. The question then becomes, do these errors affect the validity of the ensuing analysis? In this paper we specifically examine the stability of network metrics in the presence of inadequate and missing data. The issues that we study are: 1) the effect of paths with broken information flow (i.e. consecutive edges which are out of temporal order) on measures of centrality of nodes in the network, and 2) the effect of missing links on such measures. We demonstrate on three different OSS projects that while these issues do change network topology, the metrics used in the analysis are stable with respect to such changes.},
	keywords = {apache, email archives, mailing lists, missing data, mysql, perl, social networks},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463342},
	attachments = {https://flosshub.org/sites/flosshub.org/files/201NetworkAnalysis.pdf},
	author = {Nia, Roozbeh and Christian Bird and Devanbu, Premkumar and Filkov, Vladimir}
}
@conference {DBLP:conf/msr/BirdRBHGD09,
	title = {The promises and perils of mining git},
	booktitle = {Proceedings of the 6th International Working Conference on Mining Software Repositories, MSR 2009},
	year = {2009},
	pages = {1-10},
	abstract = {We are now witnessing the rapid growth of decentralized source code management (DSCM) systems, in which every developer has her own repository. DSCMs facilitate a style of collaboration in which work output can flow sideways (and privately) between collaborators, rather than always up and down (and publicly) via a central repository. Decentralization comes with both the promise of new data and the peril of its misinterpretation. We focus on git, a very popular DSCM used in high-profile projects. Decentralization, and other features of git, such as automatically recorded contributor attribution, lead to richer content histories, giving rise to new questions such as "How do contributions flow between developers to the official project repository?" However, there are pitfalls. Commits may be reordered, deleted, or edited as they move between repositories. The semantics of terms common to SCMs and DSCMs sometimes differ markedly, potentially creating confusion. For example, a commit is immediately visible to all developers in centralized SCMs, but not in DSCMs. Our goal is to help researchers interested in DSCMs avoid these and other perils when mining and analyzing git data.},
	keywords = {dscm, git, mining, scm, source code},
	attachments = {https://flosshub.org/sites/flosshub.org/files/1promisePeril.pdf},
	author = {Christian Bird and Peter C. Rigby and Earl T. Barr and David J. Hamilton and Daniel M. Germ{\'a}n and Premkumar T. Devanbu}
}
@conference {bird2009pat,
	title = {{Putting it All Together: Using Socio-Technical Networks to Predict Failures}},
	booktitle = {Proceedings of the 17th International Symposium on Software Reliability Engineering},
	year = {2009},
	note = {First, we build each type of network separately and use network analysis on both to gather metrics for use in a predictive model. Second, we build a socio-technical network which combines the nodes and edges from both the dependency network and the contribution network and use metrics gathered from this network in a predictive model.
We evaluate our approach by collecting data from Mi- crosoft Windows Vista and ECLIPSE development and using logistic regression analysis.},
	abstract = {Studies have shown that social factors in development organizations have a dramatic effect on software quality. Separately, program dependency information has also been used successfully to predict which software components are more fault prone. Interestingly, the influence of these two phenomena have only been studied separately. Intuition and practical experience suggests, however, that task assignment (i.e. who worked on which components and how much) and dependency structure (which components have dependencies on others) together interact to influence the quality of the resulting software. We study the influence of combined socio-technical software networks on the fault-proneness of individual software components within a system. The network properties of a software component in this combined network are able to predict if an entity is failure prone with greater accuracy than prior methods which use dependency or contribution information in isolation. We evaluate our approach in different settings by using it on Windows Vista and across six releases of the Eclipse development environment including using models built from one release to predict failure prone components in the next release. We compare this to previous work. In every case, our method performs as well or better and is able to more accurately identify those software components that have more post-release failures, with precision and recall rates as high as 85\%.},
	keywords = {eclipse, microsoft, social network, vista, windows},
	attachments = {https://flosshub.org/sites/flosshub.org/files/bird2009pat.pdf},
	author = {Christian Bird and Nachiappan Nagappan and Devanbu, Premkumar and Gall, Harald and Brendan Murphy}
}
@conference {bird2008lss,
	title = {{Latent Social Structure in Open Source Projects}},
	booktitle = {SIGSOFT {\textquoteright}08/FSE-16: Proceedings of the 16th ACM SIGSOFT Symposium on Foundations of Software Engineering},
	year = {2008},
	note = {We first identified the projects of interest and mined the developer mailing list archives and source code repositories of each of the projects. Next, we filtered the mailing list messages and created a social network of the participants over 3-month intervals. We then calculated the community structure of each social network. Following that, the relevance of the divisions of participants was evaluated quantitatively using mined source code development data and qualitatively by manual methods.},
	pages = {24{\textendash}35},
	publisher = {ACM},
	organization = {ACM},
	abstract = {Commercial software project managers design project organizational structure carefully, mindful of available skills, division of labour, geographical boundaries, etc. These organizational {\textquotedblleft}cathedrals{\textquotedblright} are to be contrasted with the "bazaar-like" nature of Open Source Software (OSS) Projects, which have no pre-designed organizational structure. Any structure that exists is dynamic, self-organizing, latent, and usually not explicitly stated. Still, in large, complex, successful, OSS projects, we do expect that subcommunities will form spontaneously within the developer teams. Studying these subcommunities, and their behavior can shed light on how successful OSS projects self-organize. This phenomenon could well hold important lessons for how commercial software teams might be organized. Building on known well-established techniques for detecting community structure in complex networks, we extract and study latent subcommunities from the email social network of several projects: Apache HTTPD, Python, PostgresSQL, Perl, and Apache ANT. We then validate them with software development activity history. Our results show that subcommunities do indeed spontaneously arise within these projects as the projects evolve. These subcommunities manifest most strongly in technical discussions, and are significantly connected with collaboration behaviour.},
	attachments = {https://flosshub.org/sites/flosshub.org/files/bird2008lss.pdf},
	author = {Christian Bird and David Pattison and Raissa D{\textquoteright}Souza and Filkov, Vladimir and Devanbu, Premkumar}
}
@conference {1011,
	title = {Detecting Patch Submission and Acceptance in OSS Projects},
	booktitle = {Fourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {26 - 26},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {The success of open source software (OSS) is completely dependent on the work of volunteers who contribute their time and talents. The submission of patches is the major way that participants outside of the core group of developers make contributions. We argue that the process of patch submission and acceptance into the codebase is an important piece of the open source puzzle and that the use of patch-related data can be helpful in understanding how OSS projects work. We present our methods in identifying the submission and acceptance of patches and give results and evaluation in applying these methods to the Apache webserver, Python interpreter, Postgres SQL database, and (with limitations) MySQL database projects. In addition, we present valuable ways in which this data has been and can be used.},
	keywords = {apache, contributions, mysql, patches, postgresql, python, scm, source code},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.6},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300026.pdf},
	author = {Christian Bird and Gourley, Alex and Devanbu, Prem}
}
@conference {995,
	title = {Open Borders? Immigration in Open Source Projects},
	booktitle = {Fourth International Workshop on Mining Software RepositoriesFourth International Workshop on Mining Software Repositories (MSR{\textquoteright}07:ICSE Workshops 2007)},
	year = {2007},
	pages = {6 - 6},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Minneapolis, MN, USA},
	abstract = {Open source software is built by teams of volunteers. Each project has a core team of developers, who have the authority to commit changes to the repository; this team is the elite, committed foundation of the project, selected through a meritocratic process from a larger number of people who participate on the mailing list. Most projects carefully regulate admission of outsiders to full developer privileges; some projects even have formal descriptions of this process. Understanding the factors that influence the "who, how and when" of this process is critical, both for the sustainability of FLOSS projects, and for outside stakeholders who want to gain entry and succeed. In this paper we mount a quantitative case study of the process by which people join FLOSS projects, using data mined from the Apache web server, Postgres, and Python. We develop a theory of open source project joining, and evaluate this theory based on our data.},
	keywords = {apache, core, joining, postgresql, python, team},
	isbn = {0-7695-2950-X},
	doi = {10.1109/MSR.2007.23},
	attachments = {https://flosshub.org/sites/flosshub.org/files/28300006.pdf},
	author = {Christian Bird and Gourley, Alex and Devanbu, Prem and Swaminathan, Anand and Hsu, Greta}
}
@conference {Bird:2006:MES:1137983.1138016,
	title = {Mining email social networks},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {137{\textendash}143},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Communication \& Co-ordination activities are central to large software projects, but are difficult to observe and study in traditional (closed-source, commercial) settings because of the prevalence of informal, direct communication modes. OSS projects, on the other hand, use the internet as the communication medium,and typically conduct discussions in an open, public manner. As a result, the email archives of OSS projects provide a useful trace of the communication and co-ordination activities of the participants. However, there are various challenges that must be addressed before this data can be effectively mined. Once this is done, we can construct social networks of email correspondents, and begin to address some interesting questions. These include questions relating to participation in the email; the social status of different types of OSS participants; the relationship of email activity and commit activity (in the CVS repositories) and the relationship of social status with commit activity. In this paper, we begin with a discussion of our infrastructure (including a novel use of Scientific Workflow software) and then discuss our approach to mining the email archives; and finally we present some preliminary results from our data analysis.},
	keywords = {communication, contributions, developers, email, email archives, mailing lists, open source, social networks},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138016},
	url = {http://doi.acm.org/10.1145/1137983.1138016},
	attachments = {https://flosshub.org/sites/flosshub.org/files/137MiningEmail.pdf},
	author = {Christian Bird and Gourley, Alex and Devanbu, Prem and Gertz, Michael and Swaminathan, Anand}
}
@conference {Bird:2006:MES:1137983.1138033,
	title = {Mining email social networks in Postgres},
	booktitle = {Proceedings of the 2006 international workshop on Mining software repositories},
	series = {MSR {\textquoteright}06},
	year = {2006},
	pages = {185{\textendash}186},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Open Source Software (OSS) projects provide a unique opportunity to gather and analyze publicly available historical data. The Postgres SQL server, for example, has over seven years of recorded development and communication activity. We mined data from both the source code repository and the mailing list archives to examine the relationship between communication and development in Postgres. Along the way, we had to deal with the difficult challenge of resolving email aliases. We used a number of social network analysis measures and statistical techniques to analyze this data. We present our findings in this paper.},
	keywords = {developers, email, email archives, open source, postgresql, scm, social network analysis, social networks, source code, status},
	isbn = {1-59593-397-2},
	doi = {http://doi.acm.org/10.1145/1137983.1138033},
	url = {http://doi.acm.org/10.1145/1137983.1138033},
	attachments = {https://flosshub.org/sites/flosshub.org/files/185MiningEmail.pdf},
	author = {Christian Bird and Gourley, Alex and Devanbu, Prem and Gertz, Michael and Swaminathan, Anand}
}
