Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
28
datasets available to search
ShareScore release 0.7.1
Dataset results
28 results for “Defect Prediction”
Defect Prediction Tool Validation Dataset 2
<p><strong>This dataset is used to address the Research Questions in the study at Transactions on Software Engineering</strong>: <strong>Within-Project</strong> <strong>Defect Prediction of Infrastructure-as-Code using Product and Process Metrics. </strong></p> <p><strong>See also: https://github.com/stefanodallapalma/TSE-2020-05-0217.</strong></p> <p>It provides</p> <p>* <strong>repositories.json</strong> - a list of repositories selected from open-source GitHub repositories based on the Ansible language.</p> <p>* <strong>fixing-commits.json</strong> - a list of defect-fixing commits extracted from those repositories.</p> <p>* <strong>fixed-files.json</strong> - a list of Ansible files fixed in those defect-fixing commits and respective bug-inducing commits.</p> <p>* <strong>failure-prone-files.json</strong> - a list of failure-prone files through the repository's commit history.</p> <p>* <strong>metrics.zip </strong>- csv files consisting of releases (set of files) and their IaC-oriented, delta and process metrics extracted from each analyzed repository</p> <p>* <strong>projects.zip </strong>- for each analyzed project, it contains the data (models, performance, and results of Recursive Feature Elimination) used to answer the Research Questions.</p> <p><strong>Context</strong></p> <p><em>Infrastructure-as-code (IaC)</em> is the DevOps strategy that allows management and provisioning of infrastructure through the definition of machine-readable files and automation around them, rather than physical hardware configuration or interactive configuration tools.</p> <p>On the one hand, although IaC represents an ever-increasing widely adopted practice nowadays, still little is known concerning how to best maintain, speedily evolve, and continuously improve the code behind the IaC strategy in a measurable fashion. <br> On the other hand, source code measurements are often computed and analyzed to evaluate the different quality aspects of the software developed.<br> In particular, Infrastructure-as-Code is simply "code", as such it is prone to defects as any other programming languages.</p> <p>This dataset targets the YAML-based Ansible language to devise <strong>within-project defects prediction</strong> approaches for IaC based on Machine-learning.</p> <p><strong>Content</strong></p> <p>The dataset contains metrics extracted from 85 open-source GitHub repositories based on the Ansible language that satisfied the following criteria:</p> <p>* The repository has at least one push event to its master branch in the last six months;<br> * The repository has at least 2 releases;<br> * At least 10% of the files in the repository are IaC scripts;<br> * The repository has at least 2 core contributors;<br> * The repository has evidence of continuous integration practice, such as the presence of a .travis.yaml file;<br> * The repository has a comments ratio of at least 0.1%;<br> * The repository has commit frequency of at least 2 per month on average;<br> * The repository has an issue frequency of at least 0.01 events per month on average;<br> * The repository has evidence of a license, such as the presence of a LICENSE.md file<br> * The repository has at least 100 source lines of code.</p> <p>Metrics are grouped into three categories:</p> <p>* <strong>IaC-Oriented:</strong> metrics of structural properties derived from the source code of infrastructure scripts. Click [here](https://www.sciencedirect.com/science/article/pii/S0164121220301618) for more info.</p> <p>* <strong>Delta</strong>: metrics that capture the amount of change in a file between two successive releases, collected for each IaC-oriented metric.</p> <p>* <strong>Process</strong>: metrics that capture aspects of the development process rather than aspects about the code itself. Description of the process metrics in this dataset can be found [here](https://pydriller.readthedocs.io/en/latest/processmetrics.html).</p> <p>In addition to the metrics, the dataset contains the pre-trained models (*.joblib) in the folders rq1 and rq2 of projects.zip.</p> <p>You can load the model in Python as follows:</p> <p>```<br> from joblib import load<br> model = load('projects/owner/repository/rq1/random_forest.joblib'), mmap_mode='r')</p> <p>best_estimator = model['estimator'] # The estimator that maximized the AUC-PR</p> <p>cv_results = model['cv_results'] # The results of each step of the validation procedure</p> <p>best_index = mode['best_index'] # The index to access the best cv_results<br> ```</p> <p> </p> <p><strong>Acknowledgements</strong></p> <p> </p> <p>This work is supported by the European Commission grants no. 825040 (RADON H2020).</p> <p><br> <strong>Inspiration</strong></p> <p>What source code properties and properties about the development process are good predictors of defects in Infrastructure-as-Code scripts?</p>
Extremely Imbalanced Smell-based Defect Prediction
<p><strong>Abstract: </strong>In continuous integration/continuous delivery, one of the main requirements for high-speed delivery of software is to find bugs efficiently. For this reason, multiple solutions were introduced in the literature. For instance, defect prediction approaches based on bad code smells detected in modules from each version of the software. Nevertheless, these approaches do not consider the problem where there may exist an extremely higher percentage of non-defective modules compared to defective modules. Given that, each version of the software may only have a small number of defects. As a result, in this thesis, we introduce a new model with an autoencoder algorithm that uses design and implementation smells to detect defective modules. Therefore, we trained five autoencoders with distinct architectures. Ad- ditionally, for evaluation, we compared each model against autoencoders with the same architecture, trained with traditional object-oriented metrics and the combination of both. Our analysis did not show promising results, as the use of only smells and the combination of features did not provide an improve- ment compared with the use of metrics. However, we introduce a starting point for smell-based defect prediction in the context of dataset imbalance. Furthermore, we introduce a baseline for future work.</p> <p> </p> <p><strong>Dataset Description:</strong></p> <p>We provide three datasets. The first results from the extraction of traditional object-oriented metrics (metric.csv). The second results from the extraction of design and implementation smells (smell.csv). The third is the combination of all the features (metricsmell.csv). Moreover, these features were extracted from Designite and Bugsdorjar software archives.</p>
Exploring Design Smells for Smell-Based Defect Prediction
<p>The archived file datasets.zip includes the datasets used for supporting the conclusions in the article <em>Exploring Design Smells for Smell-Based Defect Prediction.</em></p> <p>In this paper, we answer two research questions:</p> <p><strong>RQ1.</strong> Do Design code smells contribute to the performance of defect prediction models trained with Traditional code smells?</p> <p><strong>RQ2. </strong>How do the different categories of Design smells impact the performance of the defect prediction models?</p> <p>Therefore, after extracting the archived file documents, you will find two sub-directories, respectively named "RQ1" and "RQ2". They include the results obtained for each one of the research questions, thus supporting our conclusions.</p> <p>(You will also find a README.pdf file with these same instructions regarding the datasets.)</p> <p>Inside "RQ1," you will find two directories, respectively named "configuration_1" and "configuration_2". They represent the different configurations for the experiments. <strong>"configuration_1"</strong> contains the datasets with results for the ten classifiers configurations with the highest scores and <strong>"configuration_2" </strong>contains the datasets with the results classifier configuration with the overall best results - Support Vector Machine with C=0.1. Furthermore, within each directory, there are three sub-directories, respectively named "designite," "designite_traditional," and "traditional." These have the datasets for each of the considered smell sets in our study. Inside "RQ2," you will find four directories. Each corresponds to a category from the design smells for the dataset "designite_traditional." These datasets were build from the same configuration as "configuration_2".</p> <p>Then, within every directory, there are 97 sub-directories representing the 97 projects analyzed in this study.</p> <p>Every project folder follows the same structure, which we define as follows.</p> <ul> <li>The "dataset" directory contains the original training and testing dataset used.</li> <li>The "oversamples" directory contains the training dataset after oversampling for each of the feature selection approaches.</li> <li>The "score_summary" directory contains all classifier configurations considered, not only the 10 with the highest scores.</li> <li>The "scores.csv" file contains all the scores for the main classifier configurations studied in the particular experiment.</li> <li>The "selected_features" directory contains the selected features' information and the selected features dataset for each feature_selection method.</li> <li>The "selected_testing_X" directory contains the testing datasets.</li> <li>The "top_scores_summary" directory contains the classifier configurations and hyper-parameter scores for the top 10 highest scores.</li> </ul>
Defect Prediction: Xerces
<p>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.</p>
SLDeep: Statement-Level Software Defect Prediction Using Deep-Learning Models on Static Code Features
<p>Software defect prediction (SDP) seeks to estimate fault-prone areas of the code to focus testing activities on more suspicious portions. Consequently, high-quality software is released with less time and effort. The current SDP techniques however work at coarse-grained units, such as a module or a class, putting some burden on the developers to locate the fault. To address this issue, we propose Statement-Level software defect prediction using Deep-learning model (SLDeep). To reify our proposal, we defined a suite of 32 statement-level metrics, such as the number of binary and unary operators used in a statement. Then, we applied as learning model, long short-term memory (LSTM). The significance of SLDeep for intelligent and expert systems is that it demonstrates a novel use of deep-learning models to the solution of a practical problem faced by software developers. We conducted experiments using more than 100,000 C/C++ programs within the Code4Bench. The programs total 2,356,458 lines of code with 292,064 faulty lines. The benchmark comprises diverse set of programs and versions, written by thousands of developers. Therefore, it tends to give a model that can be used for cross-project SDP. In the experiments, our trained model could successfully classify the unseen data with average performance measures 0.945, 0.971, and 0.976 in terms of recall, precision, and accuracy, respectively. These experimental results suggest that SLDeep is effective for statement-level SDP. The impact of this work is twofold. Working at statement-level further alleviates developer’s burden in pinpointing the fault locations. Second, cross-project feature of SLDeep helps defect prediction research become more industrially-viable</p> <p>for more information visit <a href="https://github.com/sldeep/SLDeep">https://github.com/sldeep/SLDeep</a></p>
US-XGB Models for Defect Prediction
<p>These files contain two pickle models featuring thousands of machine learning models drawn from the Bug Prediction and Jureczko datasets. These models were trained on extensive data and are suitable for use in bug prediction research data. The models are easy to employ and can be integrated into existing systems with minimal effort. We believe that these models will be a valuable resource for researchers and practitioners working in the field of machine learning and software engineering.</p>
Paper Repository and References for "Early software defect prediction: A systematic map and review"
<p>Context: Software defect prediction is a trending research topic, and a wide variety of the published papers focus on coding phase or after. A limited number of papers, however, includes the prior (early) phases of the software development lifecycle (SDLC).<br> Objective: The goal of this study is to obtain a general view of the characteristics and usefulness of Early Software Defect Prediction (ESDP) models reported in scientific literature. <br> Method: A systematic mapping and systematic literature review study has been conducted. We searched for the studies reported between 2000 and 2016. We reviewed 52 studies and analyzed the trend and demographics, maturity of state-of-research, in-depth characteristics, success and benefits of ESDP models. <br> Results: We found that categorical models that rely on requirement and design phase metrics, and few continuous models including metrics from requirements phase are very successful. We also found that most studies reported qualitative benefits of using ESDP models.<br> Conclusion: We have highlighted the most preferred prediction methods, metrics, datasets and performance evaluation methods, as well as the addressed SDLC phases. We expect the results will be useful for software teams by guiding them to use early predictors effectively in practice, and for researchers in directing their future efforts.</p>
Defect Prediction: SPE
<p>Software process evaluation is essential to improve software development and the quality of software products in an organization. Conventional approaches based on manual qualitative evaluations (e.g., artifacts inspection) are deficient in the sense that (i) they are time-consuming, (ii) they suffer from the authority constraints, and (iii) they are often subjective. To overcome these limitations, this paper presents a novel semi-automated approach to software process evaluation using machine learning techniques. In particular, we formulate the problem as a sequence classification task, which is solved by applying machine learning algorithms. Based on the framework, we define a new quantitative indicator to objectively evaluate the quality and performance of a software process. To validate the efficacy of our approach, we apply it to evaluate the defect management process performed in four real industrial software projects. Our empirical results show that our approach is effective and promising in providing an objective and quantitative measurement for software process evaluation.</p> <p><strong>Reference: </strong>Chen, Ning, Steven CH Hoi, and Xiaokui Xiao. "Software process evaluation: A machine learning approach." <em>Proceedings of the 2011 26th IEEE/ACM International Conference on Automated Software Engineering</em>. IEEE Computer Society, 2011.</p>
Dataset and source code for ICSME2017 paper "Supervised vs Unsupervised Models: A Holistic Look at Effort-Aware Just-in-Time Defect Prediction"
<p>Dataset and source code for ICSME2017 paper “Supervised vs Unsupervised Models: A Holistic Look at Effort-Aware Just-in-Time Defect Prediction”</p> <p>There are four different models in the paper (i.e., EALR, LT, CBS and OneWay). Each model was implemented in a single Java file in the model package. To reproduce the experiment results of each model in the paper, just run the main method in the corresponding Java file. </p> <p> </p>
An Audit of Machine Learning Experiments on Software Defect Prediction - Dataset
<p><strong>ML_Audit_20250328_anon.csv</strong>:<br>This CSV file contains anonymized data used in the audit of machine learning experiments on software defect prediction. The dataset includes variables and performance metrics extracted from studies published between 2019 and 2023. It supports the audit's evaluation of study reproducibility and issues related to experimental design and statistical analysis. This data can be used for replication and further analysis of the trends and reproducibility issues identified in the paper.</p> <p><strong>ML_Audit_March2025.Rmd</strong>:<br>This RMarkdown file contains the analysis script used for the statistical analysis and audit of the machine learning experiments reviewed in the study. It includes the procedures for data preprocessing, statistical evaluations, and reproducibility assessments. The script is integral for replicating the audit results presented in the paper and can be used by other researchers to perform similar audits or extend the analysis on different datasets.</p>
ApacheJIT: A Large Dataset for Just-In-Time Defect Prediction
<p><strong>ApacheJIT: A Large Dataset for Just-In-Time Defect Prediction</strong></p> <p>This archive contains the <strong>ApacheJIT</strong> dataset presented in the paper "ApacheJIT: A Large Dataset for Just-In-Time Defect Prediction" as well as the replication package. The paper is submitted to <strong>MSR 2022 Data Showcase Track</strong>.</p> <p>The datasets are available under directory <em>dataset</em>. There are 4 datasets in this directory.</p> <ol> <li><strong>apachejit_total.csv</strong>: This file contains the entire dataset. Commits are specified by their identifier and a set of commit metrics that are explained in the paper are provided as features. Column <em>buggy</em> specifies whether or not the commit introduced any bug into the system.</li> <li><strong>apachejit_train.csv</strong>: This file is a subset of the entire dataset. It provides a balanced set that we recommend for models that are sensitive to class imbalance. This set is obtained from the first 14 years of data (2003 to 2016).</li> <li><strong>apachejit_test_large.csv</strong>: This file is a subset of the entire dataset. The commits in this file are the commits from the last 3 years of data. This set is not balanced to represent a real-life scenario in a JIT model evaluation where the model is trained on historical data to be applied on future data without any modification.</li> <li><strong>apachejit_test_small.csv</strong>: This file is a subset of the test file explained above. Since the test file has more than 30,000 commits, we also provide a smaller test set which is still unbalanced and from the last 3 years of data.</li> </ol> <p>In addition to the dataset, we also provide the scripts using which we built the dataset. These scripts are written in Python 3.8. Therefore, Python 3.8 or above is required. To set up the environment, we have provided a list of required packages in file <em>requirements.txt</em>. Additionally, one filtering step requires GumTree [1]. For Java, GumTree requires Java 11. For other languages, external tools are needed. Installation guide and more details can be found <a href="https://github.com/GumTreeDiff/gumtree/wiki/Getting-Started">here</a>.</p> <p>The scripts are comprised of Python scripts under directory <em>src</em> and Python notebooks under directory <em>notebooks</em>. The Python scripts are mainly responsible for conducting GitHub search via GitHub search API and collecting commits through PyDriller Package [2]. The notebooks link the fixed issue reports with their corresponding fixing commits and apply some filtering steps. The bug-inducing candidates then are filtered again using <em>gumtree.py</em> script that utilizes the GumTree package. Finally, the remaining bug-inducing candidates are combined with the clean commits in the <em>dataset_construction</em> notebook to form the entire dataset.</p> <p>More specifically, <em>git_token</em> handles GitHub API token that is necessary for requests to GitHub API. Script <em>collector</em> performs GitHub search. Tracing changed lines and git annotate is done in <em>gitminer</em> using PyDriller. Finally, <em>gumtree</em> applies 4 filtering steps (number of lines, number of files, language, and change significance).</p> <p>References:</p> <p><strong>1. GumTree</strong></p> <ul> <li> <p><a href="https://github.com/GumTreeDiff/gumtree">https://github.com/GumTreeDiff/gumtree</a></p> </li> <li> <p>Jean-Rémy Falleri, Floréal Morandat, Xavier Blanc, Matias Martinez, and Martin Monperrus. 2014. Fine-grained and accurate source code differencing. In ACM/IEEE International Conference on Automated Software Engineering, ASE ’14,Vasteras, Sweden - September 15 - 19, 2014. 313–324</p> </li> </ul> <p><strong>2. PyDriller</strong></p> <ul> <li> <p><a href="https://pydriller.readthedocs.io/en/latest/">https://pydriller.readthedocs.io/en/latest/</a></p> </li> <li> <p>Davide Spadini, Maurício Aniche, and Alberto Bacchelli. 2018. PyDriller: Python Framework for Mining Software Repositories. In Proceedings of the 2018 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering(Lake Buena Vista, FL, USA)(ESEC/FSE2018). Association for Computing Machinery, New York, NY, USA, 908–911</p> </li> </ul>
Towards Developing and Analysing The Metric-Based Software Defect Severity Prediction Model
<p>This is a metric based approach to solve software defect severity prediction problem. In addition to that, this work proposes a new evaluation scheme that comprised of five metrics to analyze the performances.</p>
The energy bands of charged defect predicted by the HamGNN-Q model
<p>The dataset contains graph representations of GaAs defects for testing in the study that were not present in the training set, including single-point vacancies, interstitial atom defects, defect clusters, substitution defects, and large-sized polarons with varying background charges. charged_defect_hamiltoian.ckpt is the network weights for the HamGNN-Q model. config_charge.yaml is the input file of the model.</p>
BEIRUT: Repository Mining for Defect Prediction
<p>This artifact includes two CSV files.</p> <p>The sample_metrics.csv contains a sample of 153 metrics extracted from project <a href="https://ratis.apache.org/">ratis</a>.</p> <p>The sample_prediction.csv contains a sample of the prediction results from the application of defect prediction to the extracted metrics.</p>
Defectors: A Large Scale Python Dataset for Defect Prediction
<p>Defect prediction has been a major research problem in the software engineering domain for the last five decades.<br> In recent years, large deep-learning models have shifted the performance of software engineering tasks to new limits and are gaining usage in defect prediction.<br> However, these defect prediction models are often limited by the quality of their datasets, which are not large or diverse enough.<br> In this paper, we present Defectors, a large dataset for both line-level and just-in-time defect prediction.<br> Defectors consist of $\approx$ 213K source code files ($\approx$ 93K defective and $\approx$ 120K defect-free files) from 25 popular python projects from various domains and organizations.<br> These projects come from a diverse set of domains including machine learning, automation, and internet-of-things.<br> Such a scale and diversity make Defectors a suitable dataset for deep learning models, especially transformer models that require large and diverse datasets to effectively generalize defect-inducing patterns to predict future defects.</p> <table> <caption>Dataset Description</caption> <tbody> <tr> <td>File Name</td> <td>Description</td> </tr> <tr> <td>defectors.zip</td> <td>The original Dataset. Find its description in Section II of the paper.</td> </tr> <tr> <td>bug_inducing_commits.zip</td> <td>Each yaml file contains a map of bugfix commits to bug-inducing commits.</td> </tr> <tr> <td>filtered_bug_inducing_commits.yaml</td> <td>A map in structure {repo_name: {bug_inducing_commits: [list of python files in the commit]}}. This file only contains the bug-inducing commits that match the filtering criteria from Section III.D.</td> </tr> <tr> <td>repo_links.yaml</td> <td>Links to the repositories we used to construct the dataset.</td> </tr> </tbody> </table> <p> </p>
Fine-Grained Just-In-Time Defect Prediction - Appendix
<p>Defect prediction models focus on identifying defect-prone code elements, for example to allow practitioners to allocate testing resources on specific subsystems and to provide assistance during code reviews. While the research community has been highly active in proposing metrics and methods to predict defects on long-term periods (i.e., at release time), a recent trend is represented by the so-called short-term defect prediction (i.e., at commit-level). Indeed, this strategy represents an effective alternative in terms of effort required to inspect files likely affected by defects. Nevertheless, the granularity considered by such models might be still too coarse. Indeed, existing commit-level models highlight an entire commit as defective even in cases where only specific files actually contain defects. </p> <p>In this paper, we first investigate to what extent commits are partially defective; then, we propose a novel fine-grained just-in-time defect prediction model to predict the specific files, contained in a commit, that are defective. Finally, we evaluate our model in terms of (i) performance and (ii) the extent to which it decreases the effort required to diagnose a defect. Our study highlights that: (1) defective commits are frequently composed of a mixture of defective and non- defective files, (2) our fine-grained model can accurately predict defective files with an AUC-ROC up to 82% and (3) our model would allow practitioners to save inspection efforts with respect to standard just-in-time techniques.</p>
The replication page for paper: Revisiting Supervised and Unsupervised Models for Effort-Aware Just-in-Time Defect Prediction
<p>The replication page for the paper submitted to EMSE: Revisiting Supervised and Unsupervised Models for Effort-Aware Just-in-Time Defect Prediction.</p> <p>There are four java files in the package named "model". Each file corresponds to one specific model (CBS and CBS+ are in the same file). Each file has a main function and you will get the experiment results when running the main function.</p> <p> </p>
Blood Based Assessment of sST2, Taken During and After Surgery, for Pediatric Patients With Heart Defects to Predict Heart Failure.
ClinicalTrials.gov study NCT07029230. IPD Sharing: NO. Countries: 1. Publications: 5.
Data from: The strategy of psychopathy: primary psychopathic traits predict defection on low-value relationships
Recent evidence suggests that psychopathy is a trait continuum. This has unappreciated implications for understanding the selective advantage of psychopathic traits. Whereas clinical psychopathy is typically construed as a strategy of unconditional defection, subclinical psychopathy may promote strategic conditional defection, broadening the adaptive niche of psychopathy within human societies. To test this, we focus on a ubiquitous real-life source of conditional behaviour: the expected relational value of social partners, both in terms of their quality and the likely quantity of future interactions with them. We allow for conversational interaction among participants prior to their playing an unannounced, one-shot prisoner's dilemma game, which fosters naturalistic interpersonal evaluation and conditional behavior, while controlling punishment and reputation effects. Individuals scoring higher on Factor 1 (callous affect, interpersonal manipulation) of the Levenson Self-Report Psychopathy Scale show two forms of conditional defection: one after being interrupted more frequently during the conversation, the other after failing to discover cues to future meetings with an interlocutor. Both interaction effects support the hypothesis that primary subclinical psychopathy potentiates defection on those with low expected relational value. These data clarify the function and form of psychopathic traits, while highlighting adaptive variation in human social strategies.
Replication kit for: Problems with SZZ and Features: An empirical study of the state of practice of defect prediction data collection
<p>This is the replication package for our article "Problems with SZZ and Features: An empirical study of the state of practice of defect prediction data collection". </p> <p>All relevant information is available in the replication-notebook, which is available as executable Jupyter Notebook and as HTML page.</p> <p>The archive release-level-data.tar.gz contains the defect prediction data labeled with IND-JLMIV+R for the 398 releases and is shared for re-use by other researcher for defect prediction experiments. </p> <p>The archive DO_NOT_USE_release-leve-data.tar.gz contains the contains the defect prediction data labeled with 6M-SZZ and should not be re-used. </p> <p>The raw data with the MongoDB required to run the Jupyter Notebook is contained in the SmartSHARK Database release 1.0 (https://smartshark.github.io/dbreleases/ / https://doi.org/10.5281/zenodo.4071448).</p> <p>All materials are licensed under the Apache 2.0 License (see LICENSE file). </p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.