The SEOSS 33 dataset — Requirements, bug reports, code history, and trace links for entire projects

Rath, Michael; Mäder, Patrick

doi:10.1016/j.dib.2019.104005

Cited by 18 publications

(11 citation statements)

References 11 publications

(16 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For QT Creator, we extracted the PR history 3 and bug history 4 until December 2019. For HIVE , we used the version provided by SEOSS 33 [23], a dataset repository that includes data retrieved from several open-source software projects. In the data gathering stage, we used the Perceval tool from GrimoireLab 5 , which allows fetching datasets from both GitHub and Jira.…”

Section: Dataset Description and Preprocessingmentioning

confidence: 99%

Detection and Elimination of Systematic Labeling Bias in Code Reviewer Recommendation Systems

Tecimer

Tüzün

Dibeklioğlu

et al. 2021

Evaluation and Assessment in Software Engineering

View full text Add to dashboard Cite

Reviewer selection in modern code review is crucial for effective code reviews. Several techniques exist for recommending reviewers appropriate for a given pull request (PR). Most code reviewer recommendation techniques in the literature build and evaluate their models based on datasets collected from real projects using opensource or industrial practices. The techniques invariably presume that these datasets reliably represent the "ground truth. "In the context of a classification problem, ground truth refers to the objectively correct labels of a class used to build models from a dataset or evaluate a model's performance. In a project dataset used to build a code reviewer recommendation system, the recommended code reviewer picked for a PR is usually assumed to be the best code reviewer for that PR. However, in practice, the recommended code reviewer may not be the best possible code reviewer, or even a qualified one. Recent code reviewer recommendation studies suggest that the datasets used tend to suffer from systematic labeling bias, making the ground truth unreliable. Therefore, models and recommendation systems built on such datasets may perform poorly in real practice.In this study, we introduce a novel approach to automatically detect and eliminate systematic labeling bias in code reviewer recommendation systems. The bias that we remove results from selecting reviewers that do not ensure a permanently successful fix for a bug-related PR. To demonstrate the effectiveness of our approach, we evaluated it on two open-source project datasets -HIVE and QT Creator-and with five code reviewer recommendation techniques -Profile-Based, RSTrace, Naive Bayes, k-NN, and Decision Tree. Our debiasing approach appears promising since it improved the Mean Reciprocal Rank (MRR) of the evaluated techniques up to 26% in the datasets used.

show abstract

Section: Dataset Description and Preprocessingmentioning

confidence: 99%

Detection and Elimination of Systematic Labeling Bias in Code Reviewer Recommendation Systems

Tecimer

Tüzün

Dibeklioğlu

et al. 2021

Evaluation and Assessment in Software Engineering

View full text Add to dashboard Cite

show abstract

“…commits) and their related data such as author, changed files and linked issues. Rath and Mader [21] published datasets for 33 OSS projects, SEOSS 33. All 33 datasets are available online 3 .…”

Section: Dataset 41 Selecting Datasetsmentioning

confidence: 99%

“…After each code change, we removed the file if its change type is DELETE, and we added the file if its change type is ADD. • Git does not track RENAME situations explicitly, and the dataset [21] did not share such information about the code changes. When a file is renamed, it is a DELETE and an ADD for Git (if there is no change in the file) 7 .…”

Section: Preprocessingmentioning

confidence: 99%

“…For example, it detects RENAME when "example.java" moved from "module1/example.java" to "module2/example.java" but does not detect it when the file content is changed. Since we used the datasets from SQL tables [21] directly and we did not mine them from Git repositories ourselves, we used the heuristic give. above.…”

Section: Preprocessingmentioning

confidence: 99%

“…Construct validity is about how the operational measures in the study represent what is investigated according to the RQs [24]. We used a dataset from another study [21], and their mining process can potentially affect our results. To reduce the threat caused by the data mining process, we eliminated the possible problems (e.g.…”

Section: Threats To Validitymentioning

confidence: 99%

See 2 more Smart Citations

Identifying key developers using artifact traceability graphs

Çetin

Tüzün

2020

Proceedings of the 16th ACM International Conference on Predictive Models and Data Analytics in Software Engineering

View full text Add to dashboard Cite

Developers are the most important resource to build and maintain software projects. Due to various reasons, some developers take more responsibility, and this type of developers are more valuable and indispensable for the project. Without them, the success of the project would be at risk. We use the term key developers for these essential and valuable developers, and identifying them is a crucial task for managerial decisions such as risk assessment for potential developer resignations. We study key developers under three categories: jacks, mavens and connectors. A typical jack (of all trades) has a broad knowledge of the project, they are familiar with different parts of the source code, whereas mavens represent the developers who are the sole experts in specific parts of the projects. Connectors are the developers who involve different groups of developers or teams. They are like bridges between teams.To identify key developers in a software project, we propose to use traceable links among software artifacts such as the links between change sets and files. First, we build an artifact traceability graph, then we define various metrics to find key developers. We conduct experiments on three open source projects: Hadoop, Hive and Pig. To validate our approach, we use developer comments in issue tracking systems and demonstrate that the identified key developers by our approach match the top commenters up to 92%. CCS CONCEPTS• Software and its engineering → Programming teams.

show abstract

Balanced knowledge distribution among software development teams—Observations from open‐ and closed‐source software development

Shafiq,

Mayr‐Dorn,

Mashkoor

et al. 2024

J Software Evolu Process

View full text Add to dashboard Cite

SummaryIn software development, developer turnover is among the primary reasons for project failures, leading to a great void of knowledge and strain for newcomers. Unfortunately, no established methods exist to measure how the problem domain knowledge is distributed among developers. Awareness of how this knowledge evolves and is owned by key developers in a project helps stakeholders reduce risks caused by turnover. To this end, this paper introduces a novel, realistic representation of problem domain knowledge distribution: the ConceptRealm. To construct the ConceptRealm, we employ a latent Dirichlet allocation model to represent textual features obtained from 300 K issues and 1.3 M comments from 518 open‐source projects. We analyze whether the newly emerged issues and developers share similar concepts or how aligned the individual developers' concepts are with the team over time. We also investigate the impact of leaving developers on the frequency of concepts. Finally, we also evaluate the soundness of our approach on a closed‐source software project, thus allowing the validation of the results from a practical standpoint. We find out that the ConceptRealm can represent the problem domain knowledge within a project and can be utilized to predict the alignment of developers with issues. We also observe that projects exhibit many keepers independent of project maturity and that abruptly leaving keepers correlates with a decline of their core concepts as the remaining developers cannot quickly familiarize themselves with those concepts.

show abstract

The SEOSS 33 dataset — Requirements, bug reports, code history, and trace links for entire projects

Cited by 18 publications

References 11 publications

Detection and Elimination of Systematic Labeling Bias in Code Reviewer Recommendation Systems

Detection and Elimination of Systematic Labeling Bias in Code Reviewer Recommendation Systems

Identifying key developers using artifact traceability graphs

Balanced knowledge distribution among software development teams—Observations from open‐ and closed‐source software development

Contact Info

Product

Resources

About