cometadata/datacite-titles-descriptions-related-identifiers huggingface dataset:
DOI: 10.5281/zenodo.268442
title: Camel

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.268443
title: Eclipse And Mozilla Defect Tracking Dataset

description: A dataset with over 200.000 reported bugs extracted from the Eclipse and Mozilla projects (respectively 47.000 and 168.000 reported bugs). Besides providing a single snapshot of a bug report, we also include all the incremental modifications as performed during the lifetime of the bug report.
DOI: 10.5281/zenodo.268445
title: Birt

description: 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.268447
title: Pitsd

description: This is a text mining data set generated from project and issue tracking system (PITS) reports.
DOI: 10.5281/zenodo.268448
title: Columba, Eclipse Jdt.Core And Scarab

description: Many software defect prediction models have been built using historical defect data obtained by mining software repositories (MSR). Recent studies have discovered that data so collected contain noises because current defect collection practices are based on optional bug fix keywords or bug report links in change logs. Automatically collected defect data based on the change logs could include noises. This paper proposes approaches to deal with the noise in defect data. First, we measure the impact of noise on defect prediction models and provide guidelines for acceptable noise level. We measure noise resistant ability of two well-known defect prediction algorithms and find that in general, for large defect datasets, adding FP (false positive) or FN (false negative) noises alone does not lead to substantial performance differences. However, the prediction performance decreases significantly when the dataset contains 20%-35% of both FP and FN noises. Second, we propose a noise detection and elimination algorithm to address this problem. Our empirical study shows that our algorithm can identify noisy instances with reasonable accuracy. In addition, after eliminating the noises using our algorithm, defect prediction accuracy is improved.
DOI: 10.5281/zenodo.268449
title: Fault

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

Defects4J: A Database of Existing Faults to Enable Controlled Testing Studies for Java Programs

<strong>Paper Abstract</strong>

Rather than tediously writing unit tests manually, tools can be used to generate them automatically – sometimes even resulting in higher code coverage than manual testing. But how good are these tests at actually finding faults? To answer this question, we applied three state-of-the-art unit test generation tools for Java (Randoop, EvoSuite, and Agitar) to the 357 real faults in the Defects4J dataset and investigated how well the generated test suites perform at detecting these faults. Although the automatically generated test suites detected 55.7% of the faults overall, only 19.9% of all the individual test suites detected a fault. By studying the effectiveness and problems of the individual tools and the tests they generate, we derive insights to support the development of automated unit test generators that achieve a higher fault detection rate. These insights include 1) improving the obtained code coverage so that faulty statements are executed in the first instance, 2) improving the propagation of faulty program states to an observable output, coupled with the generation of more sensitive assertions, and 3) improving the simulation of the execution environment to detect faults that are dependent on external factors such as date and time.
DOI: 10.5281/zenodo.268450
title: Mozilla4

description: Creators


	Creator: A. Gunes Koru
	Date: February 23, 2007
	Contact: gkoru AT umbc DOT edu Phone: +1 (410) 455 8843


Past Usage


	A. Gunes Koru, Dongsong Zhang, and Hongfang Liu, “Modeling the Effect of Size on Defect Proneness for Open-Source Software”, Predictive Models in Software Engineering Workshop, PROMISE 2007, May 20th 2007, Minneapolis, Minnesota, US.
	
		Abstract: Quality is becoming increasingly important with the continuous adoption of open-source software. Previous research has found that there is generally a positive relationship between module size and defect proneness. Therefore, in open-source software development, it is important to monitor module size and understand its impact on defect proneness. However, traditional approaches to quality modeling, which measure specific system snapshots and obtain future defect counts, are not well suited because open-source modules usually evolve and their size changes over time. In this study, we used Cox proportional hazards modeling with recurrent events to study the effect of class size on defect-proneness in the Mozilla product. We found that the effect of size was significant, and we quantified this effect on defect proneness.
		The full paper can be downloaded from A. Gunes Koru’s Websitehttp://umbc.edu/~gkoru by following the Publications link or from the Web site of PROMISE 2007.
	
	


Features


	This data set is used to create a conditional Cox Proportional Hazards Model # <em>id</em>: A numeric identification assigned to each separate C++ class(Note that the id’s do not increment from the first to the last data row) # <em>start</em>: A time infinitesimally greater than the time of the modification that created this observation (practically, modification time). When a class is introduced to a system, a new observation is entered with start=0 # <em>end</em>: Either the time of the next modification, or the end of the observation period, or the time of deletion, whichever comes first. # <em>event</em>: event is set to 1 if a defect fix takes place at the time represented by ‘end’, or 0 otherwise. A class deletion is handled easily by entering a final observation whose event is set to 1 if the class is deleted for corrective maintenance, or 0 otherwise. # <em>size</em>: It is a time-dependent covariate and its column carries the number of source Lines of Code of the C++ classes at time ‘start’. Blank and comment lines are not counted. # <em>state</em>: Initially set to 0, and it becomes 1 after the class experiences an event, and remains at 1 thereafter.


Reference

See above section “Relevant Information” for further reference.
DOI: 10.5281/zenodo.268451
title: Log4J

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.268592
title: Pythia Generated Jet Images With Alternative Rotation Scheme For Location Aware Generative Adversarial Network Training

description: Dataset containing 300k jet images that can be used to train Location Aware Generative Adversarial Networks (LAGAN) for High Energy Physics, such as the one in [arXiv:1701.05927].

<strong>Format</strong>:

HDF5 file with the following fields:


	'image' : array of dim (300000, 25, 25), contains the pixel intensities of each 25x25 image
	'signal' : binary array to identify signal (1, i.e. W boson) vs background (0, i.e. QCD)
	'jet_eta': eta coordinate per jet
	'jet_phi': phi coordinate per jet
	'jet_mass': mass per jet
	'jet_pt': transverse momentum per jet
	'jet_delta_R': distance between leading and subleading subjets if 2 subjets present, else 0
	'tau_1', 'tau_2', 'tau_3': substructure variables per jet (a.k.a. n-subjettiness, where n=1, 2, 3)
	'tau_21': tau<sub>2</sub>/tau<sub>1</sub> per jet
	'tau_32': tau<sub>3</sub>/tau<sub>2</sub> per jet


<strong>Details</strong>:


	Simulated using Pythia 8.219 at √ s = 14 TeV
	Image pre-processing using method from in L. de Oliveira et al., <em>Jet-Images -- Deep Learning Edition </em>[arXiv:1511.05190]
	scikit-image==0.10.0 implementation of cubic spline rotation with fewer low energy artifacts than scikit-image&gt;=0.12.0
	Finite calorimeter granularity simulated with 0.1×0.1 grid in η and φ, with η × φ ∈ [−1.25, 1.25] × [−1.25, 1.25]
	Jet clustering with anti-k<sub>t</sub> algorithm with a radius R = 1.0 using FastJet 3.2.1; constituent re-clustering into R = 0.3 k<sub>t</sub> subjets
	Intensity of pixel = p<sub>T</sub> of cell
	60 GeV &lt; m<sup>jet</sup> &lt; 100 GeV
	250 GeV &lt; p<sub>T</sub><sup>jet</sup> &lt; 300 GeV
	Sparse images (~10% NNZ)


Full dataset description in [arXiv:1701.05927].
description: Generation and analysis code available at https://github.com/lukedeo/adversarial-jets
description: {"references": ["T. Sjostrand, S. Mrenna and P. Z. Skands, A Brief Introduction to PYTHIA 8.1, Comput. Phys. Commun. 178 (2008) 852\u2013867 [0710.3820].", "T. Sjostrand, S. Mrenna and P. Z. Skands, PYTHIA 6.4 Physics and Manual, JHEP 0605 (2006) 026 [hep-ph/0603175].", "L. de Oliveira, M. Kagan, L. Mackey, B. Nachman and A. Schwartzman, Jet-images \u2014 deep learning edition, JHEP 07 (2016) 069 [1511.05190]."]}
DOI: 10.5517/ccdc.csd.cc1nd3bh
title: CCDC 1530976: Experimental Crystal Structure Determination

description: Related Article: Peng-Liang Zhang|2017|CSD Communication|||
description: An entry from the Cambridge Structural Database, the world’s repository for small molecule crystal structures. The entry contains experimental data from a crystal diffraction study. The deposited dataset for this entry is freely available from the CCDC and typically includes 3D coordinates, cell parameters, space group, experimental conditions and quality measures.
DOI: 10.5519/0025663
title: Mark My Bird

description: The Mark My Bird dataset comprises 3D scans of bird bills from the ornithology collection of the Natural History Museum, London. Mark My Bird is part of a European Research Council (ERC) funded project based at the University of Sheffield. The project aims to contribute to our understanding of how and why bird species form and diversify. 3D scans of bills were taken primarily from the ornithological skins collections. The scans were uploaded to the markmybird.org citizen science website where they were analysed by both researchers from the University of Sheffield and volunteer citizen scientists. Analysis involved landmarking pre-defined features of the bill on computer visualisations of the scans.\r\n\r\nThe dataset comprises records of 2028 specimens. Each specimen represents a different birds species and is typically a male. The dataset includes raw scan data in obj format, landmarks from 3-4 volunteers (and the average of those landmarks) for each specimen stored as txt files with three columns of XYZ coordinates. Mark My Bird usernames, documenting the contributing volunteer, are assigned to each landmark file. The dataset also includes a csv format file (MarkMyBird_manifest.csv) detaling taxonomy, museum accession number, and sex for each species.
DOI: 10.5281/zenodo.268456
title: Pc1

description: This is one of the NASA Metrics Data Program defect data sets.
description: {"references": ["\"How Good is Your Blind Spot Sampling Policy?\" Available from http://menzies.us/pdf/03blind.pdf."]}
DOI: 10.5281/zenodo.268458
title: Jedit

description: About the data

This dataset is one of the Marian Jureckzo Datasets.

This dataset uses the CK OO metrics.

Reference

@inproceedings{Jureczko:2010:TIS:1868328.1868342, author = {Jureczko, Marian and Madeyski, Lech}, title = {Towards Identifying Software Project Clusters with Regard to Defect Prediction}, booktitle = {Proceedings of the 6th International Conference on Predictive Models in Software Engineering}, series = {PROMISE '10}, year = {2010}, isbn = {978-1-4503-0404-7}, location = {Timi\şoara, Romania}, pages = {9:1--9:10}, articleno = {9}, numpages = {10}, url = {http://doi.acm.org/10.1145/1868328.1868342}, doi = {10.1145/1868328.1868342}, acmid = {1868342}, publisher = {ACM}, address = {New York, NY, USA}, keywords = {clustering, defect prediction, design metrics, size metrics}, }

Paper abstract

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.268455
title: Effort Estimation: Openeffort

description: Data

There are two types of data associated with this paper: author activity from OpenStack contributors and survey data from the contributors. In addition, the raw data from which the author activity data was extracted can be found here

Author Activity Data

-Rows represent individual authors (1626 total) -Columns represent months starting in Jan 2010 (these are 0-padded before and after project) -The actual author IDs can be found by cross-referencing output_authors_ids_nobots.csv: -Number of commits per month: output_commits_nobots.csv -Number of active days per month: output_activity_nobots.csv

Survey Response Data

This represents voluntary responses to a survey in which 131 individuals responded. Survey questions are as follows: ``` 1) Selection: On average, how many hours in a week have you spent in the project in the last six months? (&gt;40h, 40h, 30h, 20h, 10h, &lt;5h)

2) Selection: How much of the time you spent in the project is devoted to coding? (&gt;95%, approx. 75%, approx. 50%, approx. 25%, &lt;10%)

3) Selection: Do you make at least one commit to the repository the days you code? (yes, no)

4) Selection: What do you consider yourself in the project? (full-time, part-time, occasional contributor)

5) Free-text box: Did you always work on the project the same amount of hours, or did you have different phases of commitment? If you had different phases, could you tell us about the various phases? (the graph below may help you, as it is based in your recorded activity in the repository) ```

The anonymized survey response data is here

This survey data was cleaned with a few respondents being removed and some responses being edited. A description of the cleaning process as well as the cleaned response data is here.
DOI: 10.5281/zenodo.268459
title: Jdt

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

The data is present in 2 files:

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

“JDT.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.268460
title: Nrpclassic

description: The Next Release Problem (NRP) has been proposed to model the decision for customer profits and requirements costs in requirements engineering. The NRP seeks to maximize customer profits from a set of dependent requirements, under the constraint of a predefined budget bound. Assisted by the NRP, a requirements engineer can make a decision for software requirements to balance the profits of the company and the customers.

Note that all the files are text files in Windows Compatible Format. If you want to read these instances in Linux, Unix, or Mac, you should convert the \n\r in each line into \n (for Linux), \n (for Unix), or \r (for Mac).