@conference {Vasilescu:2016:SLM:2884781.2884875,
	title = {The Sky is Not the Limit: Multitasking Across GitHub Projects},
	booktitle = {Proceedings of the 38th International Conference on Software Engineering (ICSE 2016)},
	series = {ICSE {\textquoteright}16},
	year = {2016},
	pages = {994{\textendash}1005},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Software development has always inherently required multitasking: developers switch between coding, reviewing, testing, designing, and meeting with colleagues. The advent of software ecosystems like GitHub has enabled something new: the ability to easily switch between projects. Developers also have social incentives to contribute to many projects; prolific contributors gain social recognition and (eventually) economic rewards. Multitasking, however, comes at a cognitive cost: frequent context-switches can lead to distraction, sub-standard work, and even greater stress. In this paper, we gather ecosystem-level data on a group of programmers working on a large collection of projects. We develop models and methods for measuring the rate and breadth of a developers{\textquoteright} context-switching behavior, and we study how context-switching affects their productivity. We also survey developers to understand the reasons for and perceptions of multitasking. We find that the most common reason for multitasking is interrelationships and dependencies between projects. Notably, we find that the rate of switching and breadth (number of projects) of a developer{\textquoteright}s work matter. Developers who work on many projects have higher productivity if they focus on few projects per day. Developers that switch projects too much during the course of a day have lower productivity as they work on more projects overall. Despite these findings, developers perceptions of the benefits of multitasking are varied.
},
	keywords = {github, multitasking, productivity},
	isbn = {978-1-4503-3900-1},
	doi = {10.1145/2884781.2884875},
	url = {http://doi.acm.org/10.1145/2884781.2884875},
	author = {Vasilescu, Bogdan and Blincoe, Kelly and Xuan, Qi and Casalnuovo, Casey and Damian, Daniela and Devanbu, Premkumar and Filkov, Vladimir}
}
@proceedings {1713,
	title = {Gender and Tenure Diversity in GitHub Teams},
	year = {2015},
	abstract = {Software development is usually a collaborative venture.
Open Source Software (OSS) projects are no exception; indeed,
by design, the OSS approach can accommodate teams
that are more open, geographically distributed, and dynamic
than commercial teams. This, we find, leads to OSS teams
that are quite diverse. Team diversity, predominantly in of-
fline groups, is known to correlate with team output, mostly
with positive effects. How about in OSS?
Using GITHUB, the largest publicly available collection of
OSS projects, we studied how gender and tenure diversity
relate to team productivity and turnover. Using regression
modeling of GITHUB data and the results of a survey, we
show that both gender and tenure diversity are positive and
significant predictors of productivity, together explaining a
sizable fraction of the data variability. These results can
inform decision making on all levels, leading to better outcomes
in recruiting and performance.},
	keywords = {gender, github, team},
	url = {http://bvasiles.github.io/papers/chi15.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/chi15.pdf},
	author = {Vasilescu, Bogdan and Posnett, Daryl and Ray, Baishakhi and van den Brand, Mark G.J. and Serebrenik, Alexander and Devanbu, Premkumar and Filkov, Vladimir}
}
@proceedings {1766,
	title = {Wait For It: Determinants of Pull Request Evaluation Latency on GitHub},
	year = {2015},
	month = {05/2015},
	publisher = {IEEE},
	abstract = {The pull-based development model, enabled by git
and popularised by collaborative coding platforms like BitBucket,
Gitorius, and GitHub, is widely used in distributed software
teams. While this model lowers the barrier to entry for potential
contributors (since anyone can submit pull requests to any repository),
it also increases the burden on integrators (i.e., members
of a project{\textquoteright}s core team, responsible for evaluating the proposed
changes and integrating them into the main development line),
who struggle to keep up with the volume of incoming pull
requests. In this paper we report on a quantitative study that tries
to resolve which factors affect pull request evaluation latency
in GitHub. Using regression modeling on data extracted from
a sample of GitHub projects using the Travis-CI continuous
integration service, we find that latency is a complex issue,
requiring many independent variables to explain adequately.},
	url = {https://bvasiles.github.io/papers/msr15.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/msr15.pdf},
	author = {Yu, Yue and Wang, Huaimin and Filkov, Vladimir and Devanbu, Premkumar and Vasilescu, Bogdan}
}
@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 {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 {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 {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}
}
