cometadata/datacite-titles-descriptions-related-identifiers huggingface dataset:
DOI: 10.5281/zenodo.268462
title: Ar 6

description: Softlab is the Software Research Laboratory in Bogazici University, Istanbul, Turkey

Notes

Data from a Turkish white-goods manufacturer <br>
Embedded software implemented in C.

Function/method level static code attributes are collected using the Prest Metrics Extraction and Analysis Tool.

In this data, ar<em>.arff files keep defect information in a discrete manner (whether there is bug or not), whereas ar</em>_numericdefects.arff files keep the bug count associated with the defectives.

For More Info

Contact Ayşe Tosun, Ayşe Bener
DOI: 10.5281/zenodo.268463
title: Empirical Validation Of Codecity - A Controlled Experiment

description: Reference

Studies who have been using the data (in any form) are required to include the following reference:

@inproceedings{Wettel:2011:SSC:1985793.1985868, author = {Wettel, Richard and Lanza, Michele and Robbes, Romain}, title = {Software Systems As Cities: A Controlled Experiment}, booktitle = {Proceedings of the 33rd International Conference on Software Engineering}, series = {ICSE '11}, year = {2011}, isbn = {978-1-4503-0445-0}, location = {Waikiki, Honolulu, HI, USA}, pages = {551--560}, numpages = {10}, url = {http://doi.acm.org/10.1145/1985793.1985868}, doi = {10.1145/1985793.1985868}, acmid = {1985868}, publisher = {ACM}, address = {New York, NY, USA}, keywords = {empirical validation, software visualization}, }

About the Data

Overview of Data

This paper provided the complete raw and processed data for the controlled experiment for the empirical evaluation of a 3D software visualization approach based on a city metaphor and implemented in a tool called CodeCity. This includes and is not limited to the pre-experiment, in-experiment and debriefing questionnaires, solution oracles and grading systems, correction scores and measured completion time.

Attribute Information

Debriefing questionnaires, solution oracles and grading systems, correction scores and measured completion time

Paper Abstract

Software visualization is a popular program comprehension technique used in the context of software maintenance, reverse engineering, and software evolution analysis. While there is a broad range of software visualization approaches, only few have been empirically evaluated. This is detrimental to the acceptance of software visualization in both the academic and the industrial world. We present a controlled experiment for the empirical evaluation of a 3D software visualization approach based on a city metaphor and implemented in a tool called CodeCity. The goal is to provide experimental evidence of the viability of our approach in the context of program comprehension by having subjects perform tasks related to program comprehension. We designed our experiment based on lessons extracted from the current body of research. We conducted the experiment in four locations across three countries, involving 41 participants from both academia and industry. The experiment shows that CodeCity leads to a statistically significant increase in terms of task correctness and decrease in task completion time. We detail the experiment we performed, discuss its results and reflect on the many lessons learned.
DOI: 10.5281/zenodo.268468
title: Python Systems For Empirical Analysis

description: Reference

Studies who have been using the data (in any form) are required to include the following reference:

@inproceedings{Orru2015, abstract = {The aim of this paper is to present a dataset of metrics associated to the first release of a curated collection of Python software systems. We describe the dataset along with the adopted criteria and the issues we faced while building such corpus. This dataset can enhance the reliability of empirical studies, enabling their reproducibility, reducing their cost, and it can foster further research on Python software.}, author = {Orrú, Matteo and Tempero, Ewan and Marchesi, Michele and Tonelli, Roberto and Destefanis, Giuseppe}, booktitle = {Submitted to PROMISE '15}, keywords = {Python, Empirical Studies, Curated Code Collection}, title = {A Curated Benchmark Collection of Python Systems for Empirical Studies on Software Engineering}, year = {2015} }

About the Data

Overview

This paper presents a dataset of metrics taken from a curated collection of 51 popular Python software systems.

The dataset reports 41 metrics of different categories: volume/size, complexity and object oriented metrics. These metrics and computed both at file and class level. We provide metrics for any file and class of each system and global metrics (computed on the entire system). Moreover we provide 14 meta-data for each system.

Paper Abstract

The aim of this paper is to present a dataset of metrics associated to the first release of a curated collection of Python software systems. We describe the dataset along with the adopted criteria and the issues we faced while building such corpus. This dataset can enhance the reliability of empirical studies, enabling their reproducibility, reducing their cost, and it can foster further research on Python software.
DOI: 10.5281/zenodo.268469
title: Cocommit

description: Reference

Studies who have been using the data (in any form) are required to add the following reference to their report/paper:

@inproceedings{Xuan:2014:BTS:2568225.2568238, author = {Xuan, Qi and Filkov, Vladimir}, title = {Building It Together: Synchronous Development in OSS}, booktitle = {Proceedings of the 36th International Conference on Software Engineering}, series = {ICSE 2014}, year = {2014}, isbn = {978-1-4503-2756-5}, location = {Hyderabad, India}, pages = {222--233}, numpages = {12}, url = {http://doi.acm.org/10.1145/2568225.2568238}, doi = {10.1145/2568225.2568238}, acmid = {2568238}, publisher = {ACM}, address = {New York, NY, USA}, keywords = {OSS, collaboration, communication, synchronization}, }

About the Data

The authors obtained data for 31 OSS projects from the Apache Software Foundation on March 24th, 2012. For each project, the commit activities of developers on dierent files are gathered from the corresponding Git repository while the email communication activities are gathered from the online developer mailing lists. For each commit activity, The authors recorded the developer ID, file ID, file type, the exact submitting time in seconds, and the numbers of added and deleted LOC in each file. For each communication activity, The authors recorded the sender ID, receiver ID, and the sending time in seconds. Note that, developers may have multiple aliases, which were resolved by using a semi-automatic approach.

Abstract

In distributed software development synchronized actions are important for completion of complex, interleaved tasks that require the abilities of multiple people. Synchronous development is manifested when le commits by two developers are close together in time and modify the same files. Here we propose quantitative methods for identifying synchronized activities in OSS projects, and use them to relate developer synchronization with effective productivity and communication. In particular, we dene co-commit bursts and communication bursts, as intervals of time rich in co-commit and correspondence activities, respectively, and construct from them smoothed time series which can be, subsequently, correlated to discover synchrony. We found that synchronized co-commits between developers are associated with their effective productivity and coordination: during co-commit bursts, vs. at other times, the project size grows faster even though the overall coding effort slows down. We also found strong correlation between synchronized co-commits and communication, that is, for pairs of developers,more co-commit bursts are accompanied with more communication bursts, and their relationship follows closely a linear model. In addition, synchronized co-commits and communication activities occur very close together in time, thus, they can also be thought of as synchronizing each other. This study can help with better understanding collaborative mechanisms in OSS and the role communication plays in distributed software engineering.
DOI: 10.5255/ukda-sn-852589
title: Rising powers Part 1 - Social equality forum China: Focus group transcripts
DOI: 10.5281/zenodo.268466
title: Sf100

description: Attribute Information

test case generation; unit testing; search-based software engineering; benchmark

Paper Abstract

Several promising techniques have been proposed to automate different tasks in software testing, such as test data generation for object-oriented software. However, reported studies in the literature only show the feasibility of the proposed techniques, because the choice of the employed artifacts in the case studies (e.g., software applications) is usually done in a non-systematic way. The chosen case study might be biased, and so it might not be a valid representative of the addressed type of software (e.g., internet applications and embedded systems). The common trend seems to be to accept this fact and get over it by simply discussing it in a threats to validity section. In this paper, we evaluate search-based software testing (in particular the EvoSuite tool) when applied to test data generation for open source projects. To achieve sound empirical results, we randomly selected 100 Java projects from SourceForge, which is the most popular open source repository (more than 300,000 projects with more than two million registered users). The resulting case study not only is very large (8,784 public classes for a total of 291,639 bytecode level branches), but more importantly it is statistically sound and representative for open source projects. Results show that while high coverage on commonly used types of classes is achievable, in practice environmental dependencies prohibit such high coverage, which clearly points out essential future research directions. To support this future research, our SF100 case study can serve as a much needed corpus of classes for test generation.
DOI: 10.5281/zenodo.268470
title: Boetticher

description: See Using Correlation and Accuracy for Identifying Good Estimators - Gary Boetticher and Nazim Lokhandwala in promise 2008
DOI: 10.5281/zenodo.268472
title: Aspect J

description: Reference

Studies who have been using the data (in any form) are required to include the following reference:

@INPROCEEDINGS{7372035, author={Lam, An Ngoc and Nguyen, Anh Tuan and Nguyen, Hoan Anh and Nguyen, Tien N.}, booktitle={Automated Software Engineering (ASE), 2015 30th IEEE/ACM International Conference on}, title={Combining Deep Learning with Information Retrieval to Localize Buggy Files for Bug Reports (N)}, year={2015}, pages={476-481}, keywords={Bridges;Computer bugs;Feature extraction;History;Information retrieval;Metadata;Software;Bug Localization;Bug Reports;Deep Learning;Deep Neural Network;Information Retrieval}, doi={10.1109/ASE.2015.73}, month={Nov},}

About the Data

This dataset is one of the Datasets donated by An Ngoc Lam.

Overview of Data

The data is present in 2 files:

“AspectJ.xlsx” : A spreadsheet with the bug-ids, commits, its summary, files etc.

“AspectJ.xml” : An xml file with more detailed information than the above spreadsheet(detailed files changed).

Attribute Information

The spreadsheet contains a table with the “bug_id”, “summary”, “description”, “time_reported”, “commit associated”, “status of commit” and “files committed”.

The xml contains the above information and additionally the lines associated with the commit.

Paper Abstract

Bug localization refers to the automated process of locating the potential buggy files for a given bug report. To help developers focus their attention to those files is crucial. Several existing automated approaches for bug localization from a bug report face a key challenge, called lexical mismatch, in which the terms used in bug reports to describe a bug are different from the terms and code tokens used in source files. This paper presents a novel approach that uses deep neural network (DNN) in combination with rVSM, an information retrieval (IR) technique. rVSM collects the feature on the textual similarity between bug reports and source files. DNN is used to learn to relate the terms in bug reports to potentially different code tokens and terms in source files and documentation if they appear frequently enough in the pairs of reports and buggy files. Our empirical evaluation on real-world projects shows that DNN and IR complement well to each other to achieve higher bug localization accuracy than individual models. Importantly, our new model, HyLoc, with a combination of the features built from DNN, rVSM, and project’s bug-fixing history, achieves higher accuracy than the state-of-the-art IR and machine learning techniques. In half of the cases, it is correct with just a single suggested file. Two out of three cases, a correct buggy file is in the list of three suggested files.
DOI: 10.5281/zenodo.268471
title: Tomcat

description: <strong>Overview of Data</strong>

The data is present in 2 files:

“Tomcat.xlsx” : A spreadsheet with the bug-ids, commits, its summary, files etc.

“Tomcat.xml” : An xml file with more detailed information than the above spreadsheet(detailed files changed).

<strong>Attribute Information</strong>

The spreadsheet contains a table with the “bug_id”, “summary”, “description”, “time_reported”, “commit associated”, “status of commit” and “files committed”.

The xml contains the above information and additionally the lines associated with the commit.

<strong>Paper Abstract</strong>

Bug localization refers to the automated process of locating the potential buggy files for a given bug report. To help developers focus their attention to those files is crucial. Several existing automated approaches for bug localization from a bug report face a key challenge, called lexical mismatch, in which the terms used in bug reports to describe a bug are different from the terms and code tokens used in source files. This paper presents a novel approach that uses deep neural network (DNN) in combination with rVSM, an information retrieval (IR) technique. rVSM collects the feature on the textual similarity between bug reports and source files. DNN is used to learn to relate the terms in bug reports to potentially different code tokens and terms in source files and documentation if they appear frequently enough in the pairs of reports and buggy files. Our empirical evaluation on real-world projects shows that DNN and IR complement well to each other to achieve higher bug localization accuracy than individual models. Importantly, our new model, HyLoc, with a combination of the features built from DNN, rVSM, and project’s bug-fixing history, achieves higher accuracy than the state-of-the-art IR and machine learning techniques. In half of the cases, it is correct with just a single suggested file. Two out of three cases, a correct buggy file is in the list of three suggested files.
DOI: 10.5281/zenodo.268474
title: Defect Prediction: Xerces

description: Background: This paper describes an analysis that was conducted on newly collected repository with 92 versions of 38 proprietary, open-source and academic projects. A preliminary study performed before showed the need for a further in-depth analysis in order to identify project clusters. <br>
Aims: The goal of this research is to perform clustering on software projects in order to identify groups of software projects with similar characteristic from the defect prediction point of view. One defect prediction model should work well for all projects that belong to such group. The existence of those groups was investigated with statistical tests and by comparing the mean value of prediction efficiency. <br>
Method: Hierarchical and k-means clustering, as well as Kohonen’s neural network was used to find groups of similar projects. The obtained clusters were investigated with the discriminant analysis. For each of the identified group a statistical analysis has been conducted in order to distinguish whether this group really exists. Two defect prediction models were created for each of the identified groups. The first one was based on the projects that belong to a given group, and the second one - on all the projects. Then, both models were applied to all versions of projects from the investigated group. If the predictions from the model based on projects that belong to the identified group are significantly better than the all-projects model (the mean values were compared and statistical tests were used), we conclude that the group really exists. <br>
Results: Six different clusters were identified and the existence of two of them was statistically proven: 1) cluster proprietary B – T=19, p=0.035, r=0.40; 2) cluster proprietary/open - t(17)=3.18, p=0.05, r=0.59. The obtained effect sizes (r) represent large effects according to Cohen’s benchmark, which is a substantial finding. <br>
Conclusions: The two identified clusters were described and compared with results obtained by other researchers. The results of this work makes next step towards defining formal methods of reuse defect prediction models by identifying groups of projects within which the same defect prediction model may be used. Furthermore, a method of clustering was suggested and applied.
DOI: 10.5281/zenodo.268475
title: Pitsa

description: This is a text mining data set generated from project and issue tracking system (PITS) reports.

Reference


	
	Tim Menzies, “Improving IV&V Techniques Through the Analysis of Project Anomalies: Text Mining PITS issue reports”, Technical Report at West Virginia University, 2008.
	
	
	Tim Menzies and Andrian Marcus “Automated Severity Assessment of Software Defect Reports”. ICSM’08 2008 . Available fromhttp://menzies.us/pdf/08severis.pdf .
DOI: 10.5281/zenodo.268477
title: Lucene Mail List

description: Sample of 506 email threads from the development mailing list of a major OSS project, Lucene.
description: Attributes - Names, email addresses, alias, addresses of developers
DOI: 10.5255/ukda-sn-852592
title: Rising powers Part 2 - Social equality forum Russia: Focus group transcripts
DOI: 10.5281/zenodo.268478
title: Ossreview

description: Reference

Studies who have been using the data (in any form) are required to add the following reference to their report/paper:

@inproceedings{Beller:2014:MCR:2597073.2597082, author = {Beller, Moritz and Bacchelli, Alberto and Zaidman, Andy and Juergens, Elmar}, title = {Modern Code Reviews in Open-source Projects: Which Problems Do They Fix?}, booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories}, series = {MSR 2014}, year = {2014}, isbn = {978-1-4503-2863-0}, location = {Hyderabad, India}, pages = {202--211}, numpages = {10}, url = {http://doi.acm.org/10.1145/2597073.2597082}, doi = {10.1145/2597073.2597082}, acmid = {2597082}, publisher = {ACM}, address = {New York, NY, USA}, keywords = {Code Review, Defects, Open Source Software}, }

About the Data

Datasets

These datasets reflect changes made to two software projects: ConQAT and GROMACS. These come from manually analyzed cases in TMS (Task Management System), which are sub-smpled due the large number of tasks for each product. The datasets changes_conqat_rand and changes_gromacs_rand each consist of a stratified random sample of 120 tasks from their respective projects, while changes_conqat_100 reflects the 100 most recently changed tasks from ConQAT.

These datasets are .odb databases, which can be opened with either LibreOffice Base or OpenOffice Base. Base is not included in the basic Ubuntu install of LibreOffice, but can be installed with “apt-get install libreoffice-base”

Each dataset includes two tables: -ISSUES lists issue numbers, authors, reviewers, the type of issue tracker, and whether the issue was valid.<br>
-REVIEWS lists issue numbers, sparse counts of the types of changes made according to the dichotomy below, and the number of self-motivated changes.

Change Taxonomy

Here is a chart of the classification of change types, pulled from the original paper: https://www.dropbox.com/s/rvp4mq9eo1rcyv9/fig3_screenshot.png?dl=0 Each type of change represented by columns in the REVIEWS table has a prefix corresponding to it’s classification in this taxonomy. Examples: -A comments change would be listed as “E_D_T_COMMENTS” where “E_D_T” corresponds to “Evolvability, Documentation, Textual” -A GUI change would be listed as “F_LA_GUI” where “F_LA” corresponds to “Functional, Larger Defects”

For more details on change types, see http://figshare.com/articles/Code_Review_Defects/689805
DOI: 10.5281/zenodo.268479
title: Java Concurrency

description: <strong>Data (External):  </strong>"http://stap.sjtu.edu.cn/index.php?title=JaConTeBe#Searched_Bugs"

Reference

Studies who have been using the data (in any form) are required to include the following reference:

@INPROCEEDINGS{7372007, author={Lin, Ziyi and Marinov, Darko and Zhong, Hao and Chen, Yuting and Zhao, Jianjun}, booktitle={Automated Software Engineering (ASE), 2015 30th IEEE/ACM International Conference on}, title={JaConTeBe: A Benchmark Suite of Real-World Java Concurrency Bugs (T)}, year={2015}, pages={178-189}, keywords={Benchmark testing;Computer bugs;Concurrent computing;Java;Open source software;System recovery;JaConTeBe;Java concurrency bugs;SIR;benchmark suite;evaluations}, doi={10.1109/ASE.2015.87}, month={Nov},}

About the Data

Overview of Data

JaConTeBe is a benchmark suite for Java concurrency bugs. The initial version of JaConTeBe contains 47 confirmed, real-world concurrency bugs from 8. open-source projects. JaConTeBe is an ongoing work and the authors plan to collect more bugs in the future.

Paper Abstract

Researchers have proposed various approaches to detect concurrency bugs and improve multi-threaded programs, but performing evaluations of the effectiveness of these approaches still remains a substantial challenge. We survey the existing evaluations and find out that they often use code or bugs not representative of real world. To improve representativeness, we have prepared JaConTeBe, a benchmark suite of 47 confirmed concurrency bugs from 8 popular open-source projects, supplemented with test cases for reproducing buggy behaviors. Running three approaches on JaConTeBe shows that our benchmark suite confirms some limitations of the three approaches. We submitted JaConTeBe to the SIR repository (a software-artifact repository for rigorous controlled experiments), and it was included as a part of SIR.
DOI: 10.5281/zenodo.268480
title: Mutation Testing Operators

description: Overview of Data

This dataset lists the mutation operators for C-programming language

Paper Abstract

Safety-critical software must adhere to stringent quality standards and is expected to be thoroughly tested. However, exhaustive testing of software is usually impractical. The two main challenges faced by a software testing team are generation of effective test cases and demonstration of testing adequacy.

This paper proposes an intuitive and conservative approach to determine the test adequacy in safety-critical software. The approach is demonstrated through a case study: the core temperature monitoring system of a nuclear reactor. We combine conservative test coverage of unique execution path test cases, and the results from mutation testing to determine the test adequacy.

Although mutation testing is a powerful technique, the difficulty in identifying equivalent mutants has limited its practical utility. To gain confidence on the computed test adequacy: (i) faults during mutation testing must be induced at all possible execution paths of the code, (ii) properties of unkilled mutants must be studied, and (iii) all equivalent mutants must be detected. In this regard; results of static, dynamic and coverage analysis of the mutants is presented, and a technique to identify the likely equivalent mutants is proposed.
DOI: 10.5281/zenodo.268011
title: Sonneberg Plate Photometry For Boyajian'S Star In Two Passbands

description: Sonneberg plate photometry for Boyajian's Star in two passbands