An in-depth study of the promises and perils of mining GitHub

Kalliamvakou, Eirini; Gousios, Georgios; Blincoe, Kelly; Singer, Leif; Germán, Daniel M.; Damian, Daniela

doi:10.1007/s10664-015-9393-5

Cited by 222 publications

(159 citation statements)

References 31 publications

Supporting

Mentioning

158

Contrasting

Order By: Relevance

“…In our analysis, we are interested in state-of-the-art software systems that have a larger real-world user base. To retrieve a meaningful sample of projects from GITHUB, we follow established project selection instructions [35]: we selected all projects that have forks, received at least one commit in a period of 6 months prior to our study, received at least one pull request and have more than 50 stars.…”

Section: Rq1: How Common Is the Use Of Travis CI On Github?mentioning

confidence: 99%

Oops, my tests broke the build: An analysis of Travis CI builds with GitHub

Beller

Gousios

Zaidman

2016

Preprint

Self Cite

View full text Add to dashboard Cite

Continuous Integration (CI) has become a best practice of modern software development.At present, we have a shortfall of insight into the testing practices that are common in CIbased software development. In particular, we seek quantifiable evidence on how central testing really is in CI, how strongly the project language influences testing, whether different integration environments are valuable and if testing on the CI can serve as a surrogate to local testing in the IDE. In an analysis of 2,640,825 Java and Ruby builds on Travis CI, we find that testing is the single most important reason why builds fail.Moreover, the programming language has a strong influence on both the number of executed tests, their test run time and proneness to fail. The use of multiple integration environments leads to 10% more failures being caught at build time. However, testing in the CI does not seem to be a good surrogate for running tests in the IDE.

show abstract

Section: Rq1: How Common Is the Use Of Travis CI On Github?mentioning

confidence: 99%

Oops, my tests broke the build: An analysis of Travis CI builds with GitHub

Beller

Gousios

Zaidman

2016

Preprint

Self Cite

View full text Add to dashboard Cite

show abstract

“…Their effect size (Cliff's delta: 0.28) shows that the adoption of milestone tool is correlated with the contributors size, ie, single‐person and small‐size‐team projects are less likely to adopt the milestone tool. Projects with only one developer or small‐scale contributors are unlikely to have many development tasks, thereby affecting their usage of the milestone tool. Project forks : Figure C shows the distribution of number of project forks for projects with milestone and without. We find that, on average, projects without milestone have 70.3 (median: 20.0) forks, while projects with milestone have 150.3 (median: 28.0) forks.…”

Section: Study Resultsmentioning

confidence: 99%

“…Our independent variables of the models are mainly based on prior studies and come from two confound areas: project‐level and milestone‐level. • language : Project's programming language, one of the top‐20 popular programming languages, as described in Section .…”

Section: Methodsmentioning

confidence: 99%

“…Projects with different programming languages are likely to have different development paradigms . We controlled for it as a random‐effect variable; • nContributors : Number of project contributors (submitted at least one commit), as a proxy for the project team size . Larger teams may be better prepared to handle higher volumes of incoming issues or pull requests; • nForks : Number of project forks, as a proxy for the project network scale and project success .…”

Section: Methodsmentioning

confidence: 99%

See 1 more Smart Citation

GitHub's milestone tool: A mixed‐methods analysis on its use

Zhang

Wang

et al. 2019

J Software Evolu Process

View full text Add to dashboard Cite

Social coding site GitHub provides developers with many management tools to facilitate project maintenance and developer collaboration. Milestone tool, in particular, plays an important role in organizing and tracking progress on groups of issues or pull requests in a project. However, few research has analyzed the milestone tool, even though it has been used in practice for a long time. In this paper, we want to address this literature gap and present an ongoing work aimed at investigating the use of the milestone tool in GitHub open‐source projects. We conduct a mixed‐methods analysis in a large‐scale dataset of GitHub projects, to help developers gain some insights into the milestone tool, including its usage, benefits, and limitations. We quantitatively investigate the basic adoption of milestone tool and its correlation with project properties. We also survey developers to understand the reasons for using milestone tool or not and their perceptions of the milestone tool. We find that certain types of projects use milestone tool more than others. Adopting the milestone tool is associated with more commits, more releases, and more project popularity, but the current milestone tool also has some limitations. These observations can then be forwarded to the GitHub community for follow‐up and can result in them potentially making a better milestone tool.

show abstract

“…As the upper outliers, the Semantic discovery toolkit 5 ) project has some 1,500 classes, while Ps3 media server 6 underwent around 800 revisions. 1 Data dump is available at http://flossdata.syr.edu/data/gc/2012/2012-Nov/ 2 Prior research [21] shows that 75% of OSS projects on Github have over 20 commits and 90% have less than 50 commits. We selected projects with above 20 commits to retrieve a variety of projects with varying levels of development activity in our sample, and improve generalizeabiliy of the study.…”

Section: A Datasetmentioning

confidence: 99%

Managing Hidden Dependencies in OO Software: A Study Based on Open Source Projects

Ajienka

Capiluppi

Counsell

2017

2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)

View full text Add to dashboard Cite

Abstract-Dependency-based software change impact analysis is the domain concerned with estimating the sets of artifacts impacted by a change to a related artifact. Research has shown that analysing the various class dependency types independently will never completely reveal the impact sets. Therefore, dependency types are combined to improve the precision of estimated when compared to impact sets.Software classes can be linked in different ways; for instance semantically, if their meaning is somewhat related or, structurally, if one class depends on the services of other classes. 'Hidden' dependencies arise when two classes, linked structurally, do not share the same semantic namespace or when semantically dependent classes do not share a structural link.With the goal of revealing hidden dependencies during change impact analysis, we empirically investigated the relationship between structural and semantic class dependencies in objectoriented software systems.Results show that (i) semantic and structural links are significantly associated, (ii) the strengths of those links do not play a significant role and, (iii) a significant number of dependencies are hidden.We propose two refactoring techniques to deal with hidden dependencies, based on existing design patterns. We plan to investigate them further to assert whether either has the potential for reducing refactoring and testing effort.

show abstract

An in-depth study of the promises and perils of mining GitHub

Cited by 222 publications

References 31 publications

Oops, my tests broke the build: An analysis of Travis CI builds with GitHub

Oops, my tests broke the build: An analysis of Travis CI builds with GitHub

GitHub's milestone tool: A mixed‐methods analysis on its use

Managing Hidden Dependencies in OO Software: A Study Based on Open Source Projects

Contact Info

Product

Resources

About