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.
63
datasets available to search
ShareScore release 0.9.0
Dataset results
63 results for “technical debt”
An Empirical Evaluation of the Relationship between Technical Debt and Software Security
<p>This dataset contains the static analysis results of 50 open source software applications retrieved from Github. The results were produced by using SonarQube, PMD, CKJM Extended and Findbugs tools. Further details can be found in the relevant publication: </p> <ul> <li>Siavvas, M., Tsoukalas, D., Janković, M., Kehagias, D., Chatzigeorgiou, A., Tzovaras, D., Aničić, N., Gelenbe, E. <em>An Empirical Evaluation of the Relationship between Technical Debt and Software Security</em>. In: Konjović, Z., Zdravković, M., Trajanović, M. (Eds.) ICIST 2019 Proceedings Vol.1, pp.199-203, 2019</li> </ul>
Monitoring Technical Debt in an Industrial Setting
<p>The dataset includes the answers on a survey with 60 software engineers (i.e., architects, developers, etc.) working for 11 software development companies located in 9 countries, to understand their needs for Technical Debt Management.</p> <p>The questionnaire is organized into an introductory section and three main ones. It begins with some demographic information (Name of Company and Role in the Company). Next, participants are asked to rate in a Likert scale (1) a group of questions based on the usefulness of Technical Debt (TD) principal indicators, and (2) a group of questions based on the usefulness of TD interest indicators, and then, they are asked (3) to consider the optimal strategy for mitigating TD. In the beginning of each Section some basic TD definitions have been provided, so as to establish a common understanding and terminology among participants.</p>
Technical Debt using SonarQube, CodeClimate and Codiga of Qualitas.class Corpus
<p>The Qualitas.<em>class</em> Corpus data is available at: http://java.labsoft.dcc.ufmg.br/qualitas.class/index.html</p> <p>R. Terra; L. F. Miranda; M. T. Valente; Roberto S. Bigonha. <a href="http://java.labsoft.dcc.ufmg.br/qualitas.class/files/2013_sen.pdf">Qualitas.<em>class</em> Corpus: A compiled version of the Qualitas Corpus</a>. Software Engineering Notes, pages 1–4, 2013.</p>
Report on Transformers interpretability for Natural Language Processing: A case study on Technical Debt classification
<p>Transformer models have significantly advanced the field of natural language processing (NLP), achieving exceptional results in various tasks. However, these models are often seen as "black boxes", providing limited insight into the factors influencing their predictions. It has become crucial to develop and utilise methods for interpreting and explaining these models to uncover their complex inner workings. This report discusses the latest techniques and tools that aid in a more profound understanding of transformer models within NLP. Additionally, it explores a vital industrial use case: Technical Debt (TD) classification. In this context, the report leverages transformer model interpretability tools and Retrieval Augmented Generation (RAG) to analyse and understand the characteristics of text in Github issues, distinguishing between TD and non-TD.</p> <p>This report thoroughly outlines an approach to improve the transparency and reproducibility of machine learning models, with a special emphasis on TD classification. It integrates the RAG approach and exploits feature attribution techniques, presenting a route to create AI systems that are not only high-performing but also demonstrably trustworthy and comprehensible. Through a detailed examination of word patterns in TD classification and the innovative use of the RAG approach, the research highlights a strong dedication to promoting transparency and responsibility in AI systems, potentially ushering in a new phase in machine learning research that focuses on clarity and dependability.</p>
Technical Debt Prioritization Using Machine Learning
<p>Technical debt (TD) identification tools can find thousands of technical debt items (TDIs) in a software project. Remedying all of them would take months or even years, so prioritization and decision-making are needed to make this process efficient. On the other hand, advances in machine learning over the last few decades have allowed researchers to apply methods to cluster behaviors and identify patterns in software engineering data. In this study, we aim to develop machine learning methods to decide whether and when a given TDI should be paid off in \st{real} software projects. We performed a survey to collect data from Java open-source software projects hosted on GitHub. From the 2,616 survey responses, we created a dataset using three different labeling strategies - "pay or not", 3-classes, and priority. We applied nine well-known machine learning methods over 27 source code metrics to build models to predict if and when a TDI should be paid off. The best methods for determining whether an item should be paid off achieved a mean accuracy of 0.86 and an F1-score of 0.85. For when to make the payment, we applied four approaches. Their performance achieved an accuracy of 0.59 using traditional analysis and 0.83 with tuned analysis for the most flexible method.</p>
TDMentions: A Dataset of Technical Debt Mentions in Online Posts
<p># TDMentions: A Dataset of Technical Debt Mentions in Online Posts (version 1.0)</p> <p>TDMentions is a dataset that contains mentions of technical debt from Reddit, Hacker News, and Stack Exchange. It also contains a list of blog posts on Medium that were tagged as technical debt. The dataset currently contains approximately 35,000 items. </p> <p>## Data collection and processing</p> <p>The dataset is mainly collected from existing datasets. We used data from:</p> <p>- the archive of Reddit posts by Jason Baumgartner (available at [https://pushshift.io](https://pushshift.io), <br> - the archive of Hacker News available at Google's BigQuery (available at [https://console.cloud.google.com/marketplace/details/y-combinator/hacker-news](https://console.cloud.google.com/marketplace/details/y-combinator/hacker-news)), and the Stack Exchange data dump (available at [https://archive.org/details/stackexchange](https://archive.org/details/stackexchange)). <br> - the [GHTorrent](http://ghtorrent.org) project <br> - the [GH Archive](https://www.gharchive.org)</p> <p>The data set currently contains data from the start of each source/service until 2018-12-31. For GitHub, we currently only include data from 2015-01-01.</p> <p>We use the regular expression `tech(nical)?[\s\-_]*?debt` to find mentions in all sources except for Medium. We decided to limit our matches to variations of technical debt and tech debt. Other shorter forms, such as TD, can result in too many false positives. For Medium, we used the tag `technical-debt`. </p> <p>## Data Format</p> <p>The dataset is stored as a compressed (bzip2) JSON file with one JSON object per line. Each mention is represented as a JSON object with the following keys.</p> <p>- `id`: the id used in the original source. We use the URL path to identify Medium posts.<br> - `body`: the text that contains the mention. This is either the comment or the title of the post. For Medium posts this is the title and subtitle (which might not mention technical debt, since posts are identified by the tag).<br> - `created_utc`: the time the item was posted in seconds since epoch in UTC. <br> - `author`: the author of the item. We use the username or userid from the source.<br> - `source`: where the item was posted. Valid sources are:<br> - HackerNews Comment<br> - HackerNews Job<br> - HackerNews Submission<br> - Reddit Comment<br> - Reddit Submission<br> - StackExchange Answer<br> - StackExchange Comment<br> - StackExchange Question<br> - Medium Post<br> - `meta`: Additional information about the item specific to the source. This includes, e.g., the subreddit a Reddit submission or comment was posted to, the score, etc. We try to use the same names, e.g., `score` and `num_comments` for keys that have the same meaning/information across multiple sources.</p> <p>This is a sample item from Reddit:</p> <p>```JSON<br> {<br> "id": "ab8auf",<br> "body": "Technical Debt Explained (x-post r/Eve)",<br> "created_utc": 1546271789,<br> "author": "totally_100_human",<br> "source": "Reddit Submission",<br> "meta": {<br> "title": "Technical Debt Explained (x-post r/Eve)",<br> "score": 1,<br> "num_comments": 0,<br> "url": "http://jestertrek.com/eve/technical-debt-2.png",<br> "subreddit": "RCBRedditBot"<br> }<br> }<br> ```</p> <p>## Sample Analyses</p> <p>We decided to use JSON to store the data, since it is easy to work with from multiple programming languages. In the following examples, we use [`jq`](https://stedolan.github.io/jq/) to process the JSON.</p> <p>### How many items are there for each source?</p> <p>```<br> lbzip2 -cd postscomments.json.bz2 | jq '.source' | sort | uniq -c<br> ```</p> <p>### How many submissions that mentioned technical debt were posted each month?</p> <p>```<br> lbzip2 -cd postscomments.json.bz2 | jq 'select(.source == "Reddit Submission") | .created_utc | strftime("%Y-%m")' | sort | uniq -c<br> ```</p> <p>### What are the titles of items that link (`meta.url`) to PDF documents?</p> <p>```<br> lbzip2 -cd postscomments.json.bz2 | jq '. as $r | select(.meta.url?) | .meta.url | select(endswith(".pdf")) | $r.body'<br> ```</p> <p>### Please, I want CSV!</p> <p>```<br> lbzip2 -cd postscomments.json.bz2 | jq -r '[.id, .body, .author] | @csv'<br> ```</p> <p>Note that you need to specify the keys you want to include for the CSV, so it is easier to either ignore the meta information or process each source.</p> <p>Please see [https://github.com/sse-lnu/tdmentions](https://github.com/sse-lnu/tdmentions) for more analyses</p> <p># Limitations and Future updates</p> <p>The current version of the dataset lacks GitHub data and Medium comments. GitHub data will be added in the next update. Medium comments (responses) will be added in a future update if we find a good way to represent these.</p>
Who (Self) Admits Technical Debt?
<p>Self-Admitted Technical Debt (SATD) are comments, left by developers in the source code or elsewhere, aimed at describing the presence of TD, i.e., source code "not ready yet''. <br> Although this was never stated in the original paper by Potdar and Shihab, the term SATD might suggest that it refers to a ``self-admission'' by whoever has written or changed the source code.<br> This paper empirically investigates, using a curated SATD dataset from five Java open source projects, (i) the extent to which SATD comments are introduced by authors different from those who have done last changes to the related source code, and (ii) when this happens, what is the level of ownership those developers have about the commented source code. <br> Results of the study indicate that, depending on the project, the percentage of SATD admissions introduced or changed without modifying the related source code varies between 0% and 16%, and therefore represent a small, yet not negligible, phenomenon. The level of ownership of those developers is not particularly low, with a median value per project between 10% and 42%.<br> This indicates the possible use of SATD as a different way to perform code review, although this behavior should be considered sub-optimal to the use of more traditional tools, which entail suitable notification mechanisms.</p> <p>This dataset contains data used to compute the paper's results.</p>
Technical Debt: A Clean Architecture Implementation
<p>Technical Debt (TD) and Technical Debt Management (TDM) are terms that are receiving increasing attention from practitioners and researchers. They reflect a concern on how shortcuts taken during the software development process can incur negative impacts on software maintainability and how practitioners may use tools and techniques to mitigate the effects of the debt over time. A widely used tool to manage TD on an implementation level is SonarQube with the SQALE method, as it allows developers and managers to track debt over time. However, even SonarQube has its weaknesses since it only provides a set of architecture agnostic rules for TD, and the implementation of new rules can prove to be a challenging job. In this paper, we discuss how, during a real industrial project on a Brazilian software house, we developed a set of rules based on the Clean Architecture model, created a plug-in for SonarQube, and integrated it into our development cycle. At last, the preliminary results show that using a rigorous set of rules allows keeping track of TD on an implementation level.</p>
Dataset: an empirical study on architectural smells through a pipeline for continuous technical debt assessment
<h2><strong>Dataset of the study "An empirical study on architectural smells through a pipeline for continuous technical debt assessment"</strong></h2> <h3><strong>Abstract</strong></h3> <p>In recent years, researchers spent an increasing amount of effort investigating technical debt, with quantitative methods, and in particular static analysis, being the most common approach to investigate such a topic.</p> <p>However, quantitative studies are susceptible, to varying degrees, to external validity threats, which hinder the generalisation of their findings.<br>In response to this concern, researchers strive to expand the scope of their studies by incorporating a larger number of projects into their analyses. This practice is typically executed on a case-by-case basis, necessitating substantial data collection efforts that have to be repeated for each new study.</p> <p>To address this issue, this paper presents an approach for tackling this problem and enabling researchers to study architectural smells, a well-known indicator of architectural technical debt, at a large scale. Specifically, we introduce a novel approach to a data collection pipeline that leverages Apache Airflow to continuously generate up-to-date, large-scale datasets with any static analysis tool.</p> <p>Finally, we use the data collected through the pipeline to study the correlation between architectural smells and logical coupling in order to understand how smells influence maintenance efforts.</p>
SANER 2022 - Industrial Track - Investigating the Point of View of Project Management Practitioners on Technical Debt - A Preliminary Study on Stack Exchange
<p>Dataset related to the paper Investigating the Point of View of Project Management Practitioners on Technical Debt - A Preliminary Study on Stack Exchange. </p> <p> </p> <p>Saner 2022 Industrial Track</p>
Preventing technical debt with the TAP framework for Technical Debt Aware Management
<p><br> This zip file contains twelve files and one folder to replicate and verify the study evaluating the TAP Framework (for Technical debt Aware Project management).</p> <p> * TDframework_ticket_rawdata_revised_anonymised.xlsx: <br> revised and anonymized raw data for tickets statistic containing two sheets for TD ticket and maintenance ticket</p> <p> * TDframework_survey_questions_and_SPSSvariable_definition.xlsx: <br> excel sheet with all survey questions in German and English language, SPSS variable names, and short names<br> <br> <br> * TDframework_survey_results.sav:<br> survey results already in SPSS format, variables with suffix "D" are dichotomized versions of the variables as explained in the paper.</p> <p> * TDframework_survey_results.xslx:<br> Excel-Export of TDframework_survey_results.sav<br> <br> <br> * MannWhitneyUTest.spv:<br> results of the Mann-Whitney U-Test, which show the significances of the hypothesis mentioned in the paper (Section 5.2.2)<br> <br> * MannWhitneyUTest.xslx:<br> Excel-Export of MannWhitneyUTest.sav<br> <br> * Correlations.spv<br> results of the Chi-square test for correlations and the significances mentioned in the paper (Section 5.2.3)<br> <br> * Correlations.xslx:<br> Excel-Export of Correlations.sav<br> <br> <br> * Management-Survey_2021_en.pdf:<br> - original survey with englisch translation of the questions<br> <br> * Management-Survey_2021_XXX.pdf:<br> results of the management survey from <br> - team manager of the observed unit (TMO), participant A<br> - team manager of the comparison unit (TMC), participant B<br> - unit manager of the observed unit (UMO), participant C<br> - unit manager of the comparison unit (UMC), participant C<br> UMC => no survey, but email conversation between author and UMC to get the answers for the comparison unit<br> <br> * Fig6_Cause-Effect-Diagram_arrow_details.xslx<br> details about sources for the arrows in this figure<br> <br> * folder "Case Study Protocol"<br> contains the case study protocol according to Runeson's guidelines.<br> </p>
Refactoring Debt: Myth or Reality? An Exploratory Study on the Relationship Between Technical Debt and Refactoring
<p>This is the dataset that accompanies the study: "<strong>Refactoring Debt: Myth or Reality? An Exploratory Study on the Relationship Between Technical Debt and Refactoring</strong>." This study has been accepted for publication at the 2022 Mining Software Repositories Conference.</p> <p><strong><em>Following is the abstract of the study:</em></strong></p> <p>To meet project timelines or budget constraints, developers intentionally deviate from writing optimal code to feasible code in what is known as incurring \textit{Technical Debt} (TD). Furthermore, as part of planning their correction, developers document these deficiencies as comments in the code (i.e., self-admitted technical debt or SATD). As a means of improving source code quality, developers often apply a series of refactoring operations to their codebase. In this study, we explore developers repaying this debt through refactoring operations by examining occurrences of SATD removal in the code of 76 open-source Java systems. Our findings show that TD payment usually occurs with refactoring activities and developers refactor their code to remove TD for specific reasons. We envision our findings supporting vendors in providing tools to better support developers in the automatic repayment of technical debt.</p> <p> </p>
Technical Debt in Mathematical Programming Dataset
<p>The replication package includes the complete survey structure and the email invitation (with the Qualtrics' embedded fields). The participant collection sheet used for the convenience sample is shared empty, to disclose the data that was collected; note that we cannot provide the completed sheet (which included name, email and affiliation of invited participants) because we are restricted by our Ethical Protocol to preserve the participant's identity. This is a problem known as the `privacy vs utility paradox' (Li et al., 2009), and its study was out of scope for this investigation.</p>
Dataset: An Experience Report on Technical Debt in Pull Requests: Challenges and Lessons Learned
<p>This dataset contains the related data for the paper titled: "An Experience Report on Technical Debt in Pull Requests: Challenges and Lessons Learned". </p>
Technical Debt Classification in Issue Trackers using Natural Language Processing based on Transformers
<p>In order to ensure transparency and reproducibility, we have made everything available publicly here, including the Code, Models, Datasets and more. All the files and their functionality used in this paper are explained clearly in the <strong>README.md</strong> file.</p> <p>Background: Technical Debt (TD) needs to be controlled and tracked during software development. Support to automatically track TD in issue trackers is limited. </p> <p>Aim: We explore the usage of a large dataset of developer-labeled TD issues in combination with cutting-edge Natural Language Processing (NLP) approaches to automatically classify TD in issue trackers.</p> <p>Method: We mine and analyze more than 160GB of textual data from GitHub projects, collecting over 55,600 TD issues and consolidating them into a large dataset (GTD dataset). We use such datasets to train and test Transformer ML models. Then we test the model's generalization ability by testing them on six unseen projects. Finally, we re-train the models including part of the TD issues from the target project to test their adaptability. </p> <p>Results and Conclusion: (i) We create and release the GTD dataset, a comprehensive dataset including TD issues from 6,401 public repositories with various contexts; (ii) By training Transformers using the GTD dataset, we achieve performance metrics that are promising; (iii) Our results are a significant step forward towards supporting the automatic classification of TD in issue trackers, especially when the models are adapted to the context of unseen projects after fine-tuning.</p>
Technical Debt Tools: a Survey and an Empirical Evaluation
<p>Background: The life cycle of a technical debt from its identification to its payment is long and may include several<br> activities, such as identification and management. There is a lot of research in the literature to address different sets of<br> these activities by different means. Specifically, several tools have already tackled such technical debt identification<br> problem. However, only a few studies empirically assessed those tools. Method: In this article, we carried a multi-<br> method research. We first surveyed the literature for the technical debt tools available an then we evaluated two of<br> them, which aim at identification of self-admitted technical debt. Thy are named eXcomment e DebtHunter. Results:<br> We found 92 tools employing different approaches to support technical debt life cycle management. Most of them<br> (59%) address only the high level task of management, instead of actually identify and pay the debt. Additionally,<br> as for our empirical evaluation of tools, our results show that DebtHunter found only 7% of debt identified by<br> eXcomment. In the other way around, eXcomment found 19.9% the debt find by DebtHunter. Besides, both tools<br> have low levels of precision and recall. Conclusion: It is hard to find technical debt through comments. Both tools<br> can find indicators of debt items, however they struggle on the precision and recall. In fact, although eXcomment<br> and DebtHunter diverge on the amount of debt identified, they seem to converge with regard to the type o debt<br> present in the system under evaluation.</p>
Dataset and replication information for Temporal Discounting in Technical Debt: How do Software Practitioners Discount the Future?
<p>Dataset and replication information for the paper Temporal Discounting in Technical Debt: How do Software Practitioners Discount the Future? (Becker, C., Fagerholm, F., Mohanani, R., Chatzigeorgiou, A., 2009). The dataset consists of answers to a questionnaire on temporal discounting in a technical debt context. The respondents are from two companies. The raw data from the two companies is given separately. Information showing how to replicate the calculations required for analysis is given for each company. The dataset and replication information are given in both Excel (xlsx) and Open Document (ods) formats.</p>
Replication package for the paper: "Technical Debt's State of Practice on Stack Overflow: a Preliminary Study"
<p>This is the replication package for the paper "Technical Debt’s State of Practice on Stack Overflow: a Preliminary Study", published (in Portuguese) in the preliminary results track of SBQS, the Brazilian Symposium on Software Quality.</p> <p> </p> <p>We provide the data for all steps of our methodology and final analysis. Each file is numbered, indicating the order in which they were produced in our study. </p>
Dataset of the paper "Self-Admitted Technical Debt Practices: A Comparison Between Industry and Open-Source"
<p>This repository contains the dataset of the manuscript "Self-Admitted Technical Debt Practices: A Comparison Between Industry and Open-Source" accepted in the Empirical Software Engineering Journal, edited by Springer</p>
Replication package for the paper: "Machine Learning for the Identification and Classification of Technical Debt Types on StackOverflow Discussions"
<p>This is the replication package for the article "Machine Learning for the Identification and Classification of Technical Debt Types on StackOverflow Discussions". The article was published in the Research Track of the third Brazilian Workshop on Intelligent Software Engineering (ISE'23).</p> <p>The replication package consists of 8 files:<br> 1) dataset.csv, 2) code_anayses.ipynb and 3) example_test_balanced.csv and the others are results of word cloud generation.</p> <p>In dataset.csv, we provide the data for future replications.</p> <p>In code_anayses.ipynb, we provide the code we use to arrive at the results.</p> <p>In example_test_balanced.csv, we provide an example input dataset for training the models.</p> <p>For future references in this article, please contact lead author Eliakim Gama, or one of the co-authors.</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.