@conference {1304,
	title = {Entering the circle of trust},
	booktitle = {Proceeding of the 8th working conference on Mining software repositories - MSR {\textquoteright}11},
	year = {2011},
	note = {"we started by analyzing 219 projects"
},
	month = {05/2011},
	pages = {133-142},
	publisher = {ACM Press},
	organization = {ACM Press},
	address = {New York, New York, USA},
	abstract = {The success of an open-source project depends to a large degree on the proactive and constructive participation by the developer community. An important role that developers play in a project is that of a code committer. However, code-commit privilege is typically restricted to the core group of a project. In this paper, we study the phenomenon of the induction of external developers as code committers. The trustworthiness of an external developer is one of the key factors that determines the granting of commit privileges. Therefore, we formulate different hypotheses to explain how the trust is established in practice. To investigate our hypotheses, we developed an automated approach based on mining code repositories and bug-tracking systems. We implemented the approach and performed an empirical study, using the Eclipse projects, to test the hypotheses. Our results indicate that, most frequently, developers establish trust and credibility in a project by contributing to the project in a non-committer role. Moreover, the employing organization of a developer is another factor--although a less significant one--that influences trust.},
	keywords = {bug tracking, bug tracking system, commits, committers, core, developers, eclipse, trust},
	isbn = {9781450305747},
	doi = {10.1145/1985441.1985462},
	author = {Mani, Senthil and Sinha, Saurabh and Sinha, Vibha Singhal}
}
@conference {1308,
	title = {Social interactions around cross-system bug fixings},
	booktitle = {Proceedings of the 8th working conference on Mining software repositories - MSR {\textquoteright}11},
	year = {2011},
	note = {"We rely on information stored in versioning database and mailing lists of both systems and develop methods to reconstruct and integrate different historical database"},
	month = {05/2011},
	pages = {143-152},
	publisher = {ACM Press},
	organization = {ACM Press},
	address = {New York, New York, USA},
	abstract = {Cross-system bug fixing propagation is frequent among systems having similar characteristics, using a common framework, or, in general, systems with cloned source code fragments. While previous studies showed that clones tend to be properly maintained within a single system, very little is known about cross-system bug management.

This paper describes an approach to mine explicitly documented cross-system bug fixings, and to relate their occurrences to social characteristics of contributors discussing through the project mailing lists--e.g., degree, betweenness, and brokerage--as well as to the contributors{\textquoteright} activity on source code.

The paper reports results of an empirical study carried out on FreeBSD and OpenBSD kernels. The study shows that the phenomenon of cross-system bug fixing between these two projects occurs often, despite the limited overlap of contributors. The study also shows that cross-system bug fixings mainly involve contributors with the highest degree, betweenness and brokerage level, as well as contributors that change the source code more than others.},
	keywords = {bug fixing, bug tracking system, committers, email, email archives, freebsd, mailing list, openbsd},
	isbn = {9781450305747},
	doi = {10.1145/1985441.1985463},
	author = {Cerulo, Luigi and Cimitile, Marta and Di Penta, Massimiliano and Canfora, Gerardo}
}
@conference {1217,
	title = {Trends That Affect Temporal Analysis Using SourceForge Data},
	booktitle = {5th Workshop on Public Data about Software Development (WoPDaSD 2010)},
	year = {2010},
	note = {"In this paper we examine some of the limitations of artifact data by specifically addressing the applicability of SourceForge data to the study of project evolution."

"For our analysis we examine 9,997 Production/Stable or Maintenance phase projects stored in CVS on SourceForge and extracted in October of 2006 [5]"},
	abstract = {SourceForge is a valuable source of software artifact data for researchers who study project evolution and developer behavior. However, the data exhibit patterns that may bias temporal analyses. Most notable are cliff walls in project source code repository timelines, which indicate large commits that are out of character for the given project. These cliff walls often hide significant periods of development and developer collaboration{\textemdash}a threat to studies that rely on SourceForge repository data. We demonstrate how to identify these cliff walls, discuss reasons for their appearance, and propose preliminary measures for mitigating their effects in evolution-oriented studies.},
	keywords = {cliff walls, committers, cvs, evolution, growth, source code, sourceforge, time, time series},
	attachments = {https://flosshub.org/sites/flosshub.org/files/wopdasd001.pdf},
	author = {MacLean, Alexander C. and Pratt, Landon J. and Krein, Jonathan L. and Knutson, Charles D.}
}
@conference {Alonso:2008:EIV:1370750.1370780,
	title = {Expertise identification and visualization from CVS},
	booktitle = {Proceedings of the 2008 international working conference on Mining software repositories},
	series = {MSR {\textquoteright}08},
	year = {2008},
	month = {05/2008},
	pages = {125{\textendash}128},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {As software evolves over time, the identification of expertise becomes an important problem. Component ownership and team awareness of such ownership are signals of solid project. Ownership and ownership awareness are also issues in open-source software (OSS) projects. Indeed, the membership in OSS projects is dynamic with team members arriving and leaving. In large open source projects, specialists who know the system very well are considered experts. How can one identify the experts in a project by mining a particular repository like the source code? Have they gotten help from other people?

We provide an approach using classification of the source code tree as a path to derive the expertise of the committers. Because committers may get help from other people, we also retrieve their contributors. We also provide a visualization that helps to further explore the repository via committers and categories. We present a prototype implementation that describes our research using the Apache HTTP Web server project as a case study.},
	keywords = {apache, classification, committers, components, contributors, expertise, expertise identification, repository, scm, source code},
	isbn = {978-1-60558-024-1},
	doi = {http://doi.acm.org/10.1145/1370750.1370780},
	url = {http://doi.acm.org/10.1145/1370750.1370780},
	attachments = {https://flosshub.org/sites/flosshub.org/files/p125-alonso.pdf},
	author = {Alonso, Omar and Premkumar T. Devanbu and Gertz, Michael}
}
@conference {686,
	title = {Contributor Turnover in Libre Software Projects},
	booktitle = {OSS2006: Open Source Systems (IFIP 2.13)},
	series = {IFIP International Federation for Information Processing},
	year = {2006},
	pages = {273 - 286},
	publisher = {Springer},
	organization = {Springer},
	abstract = {A common problem that management faces in software companies is the high instability of their staff. In libre (free, open source) software projects, the permanence of developers is also an open issue, with the potential of causing problems amplified by the self-organizing nature that most of them exhibit. Hence, human resources in libre software projects are even more difficult to manage: developers are in most cases not bound by a contract and, in addition, there is not a real management structure concerned about this problem. This raises some interesting questions with respect to the composition of development teams in libre software projects, and how they evolve over time. There are projects lead by their original founders (some sort of {\textquotedblleft}code gods{\textquotedblright}), while others are driven by several different developer groups over time (i.e. the project {\textquotedblleft}regenerates{\textquotedblright} itself). 
In this paper, we propose a quantitative methodology, based on the analysis of the activity in the source code management repositories, to study how these processes (developers leaving, developers joining) affect libre software projects. The basis of it is the analysis of the composition of the core group, the group of developers most active in a project, for several time lapses. We will apply this methodology to several large, well-known libre software projects, and show how it can be used to characterize them. In addition, we will discuss the lessons that can be learned, and the validity of our proposal.
},
	keywords = {apache, committers, core, cvs, cvsanaly, developers, evolution, freebsd, gimp, gnome, kde, mono, mozilla},
	doi = {http://dx.doi.org/10.1007/0-387-34226-5_28},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Contributor\%20Turnover\%20in\%20Libre\%20Software\%20Projects.pdf},
	author = {Gregorio Robles and Gonzalez-Barahona, Jesus}
}
