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”
Replication Package for the Paper: "Potential Technical Debt and Its Resolution in Code Reviews: An Exploratory Study of the OpenStack and Qt Communities"
<p>This is the replication package for the paper: "Potential Technical Debt and Its Resolution in Code Reviews: An Exploratory Study of the OpenStack and Qt Communities", including the dataset and its description (README.md):</p> <ul> <li><strong>PTD-related Comments in Code Review and Data Extraction Results.xlsx</strong> is the dataset of our paper, which contains 2,030 review comments collected from the Nova project and Neutron project of OpenStack community. Among all the review comments, 163 review comments indicate PTD. For the rows of review comments that are related to PTD, we filled them with blue color as an indicator.</li> <li> <p><strong>README.md</strong></p> </li> </ul>
Additional Material for Beyond SonarQube: A Case Study on Technical Debt in a Large-Scale Industrial Microservice Architecture
<p>This upload contains the replication package for the study "Beyond SonarQube: A Case Study on Technical Debt in a Large-Scale Industrial Microservice Architecture" submitted for review on the ECSA 2024 Industry Track.<br><br>It contains the following:<br>Focus group-plan.pdf - The plan for the focus group discussion created by the authors.<br>Focus group slides.pdf - The slides used during the focus group discussion.<br>SonarQube measurement results.xlsx - Detailed results of the SonarQube analysis for each microservice in the researched system.</p>
Technical Debt Awareness: Measuring the Success of Technical Debt Management Approaches
<p>The additional material for the paper "Technical Debt Awareness: Measuring the Success of Technical Debt Management Approaches" comprises the following documents:<br>(Sec_XX is refering to the paper's sections)<br>* Sec_II_Semi_SLR_papers.xlsx<br> All excluded and included papers of our smei-SLR whit resons for exclusion and extracted data for included papers.<br>* Sec_III_Literature review in Psychology.pdf<br> Types of Awareness found with their respective definitions<br>* Sec_III_Guideline_to_Use_TD-SAGAT.pdf<br> A short guideline on how the use the TD-SAGAT method.* Participant_and_Meetings.xslx<br> overview of all participants with role and years of experience <br> overview of all meetings, we used for analysis<br>* Sec_III_SAGAT_for_TD_from_Goals_to_Queries.pdf<br> Determination of survey questions by following the SAGAT approach of following the hierarchy of goals, subgoals, decisions, requirements, queries <br>* Sec_IV_Delphi_Surveys.pdf<br> List of all questions asked and explanations given during the Delphi panel study<br>* Sec_IV_Delphi_Ranking_of_metrics.xslx<br> resulting ranking from third Delphi survey <br>* Sec_V_Survey_and_Observation_Template.xlsx<br> Templates for: questions for surveys and TD-SAGAT survey plus empty observation protocol</p>
[Replication] The Dual-Edged Sword of Technical Debt: Benefits and Issues Analyzed Through Developer Discussions
<p>This is the replication package for the submission with the title "The Dual-Edged Sword of Technical Debt: Benefits and Issues Analyzed Through Developer Discussions". This package includes the following artifacts.</p> <ul> <li>Original dataset</li> <li>Preprocessed dataset</li> <li>Source code for obtaining the article results</li> <li>Topic models</li> </ul>
The Temporality of Technical Debt Introduction on New Code and Confounding Factors
<p>Code Technical Debt (TD) is intentionally or unintentionally created when developers introduce inefficiencies in the codebase. This can be attributed to various reasons such as heavy workload, tight delivery schedule, or developers' lack of experience. Since a software system grows mostly through the addition of new code, it is interesting to study how TD fluctuates along this process. Specifically, in this paper we investigate: (a) the temporality of code TD introduction in new code, i.e., whether the introduction of TD is stable across the lifespan of the project, or if its evolution presents spikes; and (b) the relation of TD introduction to the development team’s workload in a given period, as well as to the experience of the development team. To answer these questions, we have performed a case study on 47 open source projects from two well-known ecosystems (Apache and Eclipse) as well as additional isolated projects from GitHub (not selected from a specific ecosystem) and inspected the number of TD issues introduced in 6-month sliding temporal windows. The results of the study suggested that: (a) overall, the number of TD issues introduced through new code is a stable measure, although it presents spikes; and (b) the number of commits performed, as well as developers' experience are not strongly correlated to the number of introduced TD issues.</p>
Dataset: An empirical study on self-admitted technical debt in modern code review
<pre>This data was used in the IST paper "An Empirical Study on Self-Admitted Technical Debt in Modern Code Review". The program to use this data is published in GitHub (https://github.com/Yutaro-Kashiwa/ReviewSATD_RP) When you use this data in your research, please cite the following papers: ``` @article{Kashiwa:IST:2022:SATD_Review, author = {Yutaro Kashiwa and Ryoma Nishikawa and Yasutaka Kamei and Masanari Kondo and Emad Shihab and Ryosuke Sato and Naoyasu Ubayashi}, title = {An empirical study on self-admitted technical debt in modern code review}, journal = {Information and Software Technology}, volume = {146}, pages = {106855}, year = {2022}, url = {https://doi.org/10.1016/j.infsof.2022.106855}, doi = {10.1016/j.infsof.2022.106855} } ``` </pre>
Replication Package for Automatically Identifying Relations Between Self-Admitted Technical Debt Across Different Sources
<p>This dataset includes a trained weight file for identifying the relations between self-admitted technical debt items.</p>
Evaluating the Agreement among Technical Debt Measurement Tools: Building an Empirical Benchmark of Technical Debt Liabilities
<p>Dataset containing TD measurements, at file level, from three TD tools. The Dataset served as the input for Archetypal Analysis.</p>
An Empirical Study of Refactorings and Technical Debt in Machine Learning Systems
<p>Machine Learning (ML), including Deep Learning (DL), systems, i.e., those with ML capabilities, are pervasive in today's data-driven society. Such systems are complex; they are comprised of ML models and many subsystems that support learning processes. As with other complex systems, ML systems are prone to classic technical debt issues, especially when such systems are long-lived, but they also exhibit debt specific to these systems. Unfortunately, there is a gap of knowledge in how ML systems actually evolve and are maintained. In this paper, we fill this gap by studying refactorings, i.e., source-to-source semantics-preserving program transformations, performed in real-world, open-source software, and the technical debt issues they alleviate. We analyzed 26 projects, consisting of 4.2 MLOC, along with 327 manually examined code patches. The results indicate that developers refactor these systems for various reasons, both specific and tangential to ML; some refactorings correspond to established technical debt categories. In contrast, others do not, and code duplication is a major cross-cutting theme that particularly involved ML configuration and model code, which was also the most refactored. We also introduce 14 and 7 new ML-specific refactorings and technical debt categories, respectively, and put forth several recommendations, best practices, and anti-patterns. The results can potentially assist practitioners, tool developers, and educators in facilitating long-term ML system usefulness.</p>
Replication Package for Automating Technical Debt Management: Insights from Practitioner Discussions in Stack Exchange
Open the record for dataset details and reuse information.
Technical Debt on Agile Projects: Managers' point of view at Stack Exchange
<p>Technical Debt on Agile Projects: Managers’ point of view at Stack Exchange</p> <p>XXI Simpósio Brasileiro de Qualidade de Software (SBQS '22), Nov 07--10, 2022, 2022, Curitiba, Paraná, Brasil.</p>
Software Practitioners' Point of View on Technical Debt Payment (Supporting Material)
<p>The InsighTD data set with answers on technical debt payment. </p>
Exploring Community Smells in Machine Learning Applications: Analytical Insights and Their Association with Self-Admitted Technical Debt
Open the record for dataset details and reuse information.
Exploring Community Smells in Machine Learning Applications: Analytical Insights and Their Association with Self-Admitted Technical Debt
Open the record for dataset details and reuse information.
Hearing the Voice of Software Practitioners on Technical Debt Monitoring: Understanding Monitoring Practices and the Practices' Avoidance Reasons: Data set
Open the record for dataset details and reuse information.
Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems
<p>Self-admitted technical debt (SATD) is a particular case of Technical Debt (TD) where developers explicitly acknowledge their sub-optimal implementation decisions. Previous studies mine SATD by searching for specific TD-related terms in source code comments.By contrast, in this paper we argue that developers can admit technical debt by other means, e.g., by creating issues in tracking systems and labelling them as referring to TD. We refer to this type of SATD as issue-based SATD or just SATD-I. We study a sample of 286 SATD-I instances collected from five open source projects, including Microsoft Visual Studio and GitLab Community Edition. We show that only 29% of the studied SATD-I instances can be tracked to source code comments. We also show that SATD-I issues take more time to be closed, compared to other issues, although they are not more complex in terms of code churn. Besides, in 45% of the studied issues TD was introduced to ship earlier, and in almost 60%it refers to Design flaws. Finally, we report that most developers pay SATD-I to reduce its costs or interests (66%). Our findings suggest that there is space for designing novel tools to support technical debt management, particularly tools that encourage developers to create and label issues containing TD concerns.</p>
Data for Investigating the Technical Debt in Procedural Model Transformation Languages
<p>The content presents the data for Investigating the Technical Debt in Procedural Model Transformation Languages </p>
Replication package for the paper: "Using Stack Overflow to Assess Technical Debt Identification on Software Projects".
<p>This is the replication package for the paper "Using Stack Overflow to Assess Technical Debt Identification on Software Projects". The paper was published on the Technical Research Track of the Bralizian Symposium on Software Engineering. </p> <p> </p> <p>The replication package is composed of 3 files: 1) data.zip, 2) tables.zip, and 3) clarifications.zip</p> <p> </p> <p>In data.zip, we provide the outputs of our methodological procedure to select the discussions from StackOverflow to include in our empirical analysis. </p> <p>In tables.zip, we provide additional and detailed data regarding all tables included in the paper/</p> <p>In clarifications.zip, we provide additional clarification regarding concepts we did not fully discuss in the manuscript. </p> <p> </p> <p>For future references in this paper, please contact the main author Eliakim Gama, or one of the co-authors.</p>
Anticipating Identification of Technical Debt Items in Model-Driven Software Projects
<p>Model-driven development (MDD) and Technical Debt (TD) are software engineering approaches that look for promoting quality on systems under development. MDD uses high-level abstraction models that can be transformed into application code, potentially improving system understanding and maintainability. TD, on the other hand, promotes quality through the use of strategies for detecting, quantifying, monitoring, and correcting software development problems that may hinder its maintenance and evolution. Most research on TD focuses on the application code as primary TD sources. In an MDD project, however, dealing with technical debt only on the source code may not be an adequate strategy because MDD projects should focus their software building efforts on models instead of source code. Besides, in MDD projects, code generation is often done at a later stage than creating models, then dealing with TD only in source code can lead to unnecessary interest payments due to unmanaged debts, such as model and source codes artifacts desynchronization. The use of TD concept in an MDD context is also known as Model-Driven Technical Debt (MDTD). Recent works concluded that MDD project codes are not technical debt free, making it necessary to investigate the possibility and benefits of applying TD identification techniques in earlier stages of the development process, such as in modeling phases. This paper intends to analyze whether it is possible to use source code technical debt detection strategies to identify TD on code-generating models in the context of model-driven development projects. A catalog of nine different model technical debt items for platform-independent code-generating models was specified. Each catalog item provides a detection strategy to automatically find elements suspected to incur the corresponding TD type in the models. An evaluation was performed in order to observe the effectiveness of the proposed catalog compared to existing source code identification techniques found in the literature. Through three different open source software projects, more than 78 thousand lines of code were investigated. Results revealed that, although the catalog items present different precision rates, it is possible to identify and deal with these model-driven technical debts before source code is generated. We hope that sharing this initial version provides future contributions and improvements for this catalog.</p>
Self-Admitted Technical Debt in Scientific Software
<p># Title<br>Self-Admitted Technical Debt (SATD) in Scientific Software Projects</p> <p># Description<br>## Abstract<br>This dataset contains annotated code comments from nine open-source scientific software projects: Astropy, Biopython, CESM, Firedrake, MOOSE, GROMACS, Elmer, Athena, and Root. The comments are labeled to identify instances of Self-Admitted Technical Debt (SATD), with a focus on a novel category termed Scientific Debt (SD). The dataset supports research on the nature and management of technical debt in scientific software.</p> <p>## Purpose<br>The dataset was created to explore the prevalence and characteristics of SATD in scientific software, with the aim of improving software maintainability and scientific validity.</p> <p>## Content<br>The dataset includes over 28,680 annotated code comments, with labels indicating various types of technical debt such as Code Debt, Design Debt, and Scientific Debt. Each comment is accompanied by metadata including the project name, file path, comment introduction date, and comment removal date.</p> <p>## Scope<br>The dataset covers nine projects across different scientific domains, including astronomy, molecular biology, and climate modeling. Data was collected from publicly available repositories and spans from the inception of each project to the present.</p> <p>## Methodology<br>Data was extracted using GitPython to access the version control histories of the selected projects. Comments were manually labeled for SATD, with a focus on identifying Scientific Debt indicators such as assumptions, missing edge cases, computational inaccuracies, translation challenges, and new scientific findings.</p> <p>## Usage Notes<br>This dataset can be used for research on technical debt management, software maintenance, and scientific software development. Users should have a basic understanding of programming and version control systems. Recommended tools for analysis include Python and Pandas.</p> <p>## Ethical Considerations<br>All data was collected from publicly available sources. No personal or sensitive information is included.</p> <p># Technical Details<br>## File Formats<br>- CSV: Contains the annotated comments and metadata</p> <p>## Size<br>- Number of records: 28,680<br>- Total file size: 15MB</p> <p>## Version<br>- Version 1.0, July 2024</p> <p># Access and Use<br>## Access<br>The dataset can be downloaded from Zenodo: [Zenodo Link](https://doi.org/10.5281/zenodo.13174322)</p> <p>## License<br>This dataset is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0).</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.