# Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems

arXiv: https://arxiv.org/abs/2003.09418 · HTML: https://mlsanity.com/paper/2003.09418/

## Key facts

- Cited by 5 papers in the map (data through 14 Oct 2026).
- First posted on arXiv 20 Mar 2020.

## Built on by (most cited first, 5 of 5)

- [Automatic Identification of Self-Admitted Technical Debt from Four Different Sources](https://mlsanity.com/paper/2202.02387/) (2022)
- [Identifying Self-Admitted Technical Debt in Issue Tracking Systems using Machine Learning](https://mlsanity.com/paper/2202.02180/) (2022)
- [Self-Admitted Technical Debt Detection Approaches: A Decade Systematic Review](https://mlsanity.com/paper/2312.15020/) (2023)
- [SATDAUG -- A Balanced and Augmented Dataset for Detecting Self-Admitted Technical Debt](https://mlsanity.com/paper/2403.07690/) (2024)
- [Deep Learning and Data Augmentation for Detecting Self-Admitted Technical Debt](https://mlsanity.com/paper/2410.15804/) (2024)

## Abstract (arXiv)

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.