Pith. sign in

REVIEW 4 major objections 6 minor 102 references

Anticipating Bugs: Ticket-Level Bug Prediction and Temporal Proximity Effects

T0 review · 4 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Ticket-Level Prediction can flag, at ticket creation time, which open tickets will inject bugs once implemented, and its accuracy rises as the ticket moves from Open to In Progress to Closed.

desk verdict A genuinely new dataset and task formulation, but the central temporal-proximity claim is contaminated by target leakage at the Closed stage and an undefined baseline. read the letter →

arxiv 2506.14290 v1 pith:GD7HLQCF submitted 2025-06-17 cs.SE

Daniele La Prova , Emanuele Gentili , Davide Falessi This is my paper · ORCID
classification cs.SE
keywords defectpredictionticket-leveljust-in-timetemporalproximityfeatureimportancemachinelearningforsoftwareengineeringApacheJIRAticketsbuginjection
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Today’s defect prediction points at classes, methods, or commits that already contain bugs, so it supports fixing rather than prevention. This paper proposes Ticket-Level Prediction (TLP): predict, from ticket and project attributes available before implementation, whether a ticket will introduce bugs once it is implemented. On about 10,000 tickets from the HIVE and HBASE projects, TLP beats a random baseline even at the earliest Open stage, and its accuracy improves with temporal proximity to implementation, with the largest gain appearing only at closure. The paper also shows that the most informative features shift across lifecycle stages, so no single feature family dominates. If the results generalize, defect prediction can move upstream to ticket triaging and developer assignment before any code is written.

What carries the argument

The central object is the three temporal proximity points that define when a prediction is made: Open (one second before the ticket is assigned), In Progress (one second before its first linked commit), and Closed (one second after its last commit). The label “bug-inducing ticket” is a ticket with at least one linked commit classified as buggy in the reused ApacheJIT data, and the ticket-to-commit linkage is what connects the two. Prediction uses 72 features in seven families (code, developer, external temperature, internal temperature, intrinsic, ticket-to-ticket similarity, and JIT—just-in-time, i.e., change-level metrics computed from the commits that implement the ticket), evaluated with a sliding-window protocol that preserves temporal order and three classifiers (Random Forest, Logistic Regression, Neural Network). The mechanism carrying the argument is the comparison of accuracy and information-gain-ratio across the three proximity points: accuracy grows as features become more reliable, and Closed benefits from JIT features that describe the actual code change, including potentially the bug-inducing modification itself.

What would settle it

Two checks would settle it: re-run the Closed-stage model with all JIT features removed and see whether the accuracy gap over Open collapses (if the gain mostly vanishes, the “anticipation” is hindsight), and manually audit a sample of linked commits in HIVE and HBASE to verify that the buggy labels correspond to bugs actually caused by those changes rather than coincidentally associated with them.

Watch

Extended reading notes

Core claim

TLP accuracy increases with temporal proximity: with a sliding-window evaluation and three classifiers, average gains over a random baseline rise from Open to In Progress to Closed in both projects—for AUC, from about 25–30 percent at Open to 67–76 percent at Closed—and the differences are statistically significant for every accuracy metric except Recall. Even at Open, before a ticket is assigned, predictions are substantially better than random, so meaningful signal exists in ticket metadata and static attributes. The feature-power analysis shows the predictive value of families changes across stages: Intrinsic and Code features lead early, Internal Temperature features stand out in In Progress, and JIT features dominate at Closure, with the top six JIT features nearly identical across the two projects. An unexpected pattern is that In Progress behaves much more like Open than Closed, suggesting that the main accuracy leap happens only when code-level features become available.

Load-bearing premise

The study assumes that the reused “buggy commit” labels and the ticket-to-commit linkage are correct enough that a ticket labelled bug-inducing genuinely caused a bug; if either is noisy, every accuracy and feature-power result inherits that error.

Editorial extensions

If this is right

  • Defect prediction can move upstream: tickets can be triaged for risk before code is written, and developers can be assigned with bug risk in mind.
  • Open-stage models are already usable: even the weakest configuration beats random on most metrics, so early warnings are actionable.
  • Pre-closure models should not expect large gains from assignment alone: In Progress is statistically closer to Open than to Closed in accuracy, so the leap comes at closure, not at assignment.
  • Prediction systems should be lifecycle-aware: developer-centric features are strongest early, JIT features dominate at closure, and no single feature family wins across all stages.
  • Some JIT features are consistently uninformative (e.g., number of linked commits and author-date span), so feature selection within the dominant family still matters.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because the Closed-stage advantage is carried by JIT features describing the real change — possibly including the bug itself — part of the accuracy gap is hindsight information; a masked evaluation that removes JIT features at Closed would reveal how much genuine early signal remains.
  • The reused buggy-commit labels and ticket–commit linkage set the ceiling for all results; a sensitivity analysis that injects controlled label noise, or manual audits of linked commits, would test how robust the Open-to-Closed gradient is to label error.
  • Ticket type and priority are the strongest early predictors, and the paper notes the priority effect could be causal (time pressure) or correlational (high-visibility tickets attract more bug reports); distinguishing those would change what triage action the signal justifies.
  • The near-identical top JIT features across HIVE and HBASE suggest transferable signals; a direct cross-project transfer test, training on one Apache project and testing on another, would extend the paper’s closed-stage result.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper introduces Ticket-Level Prediction (TLP), a method to predict, at the ticket level, whether a JIRA ticket will induce a bug when implemented. Predictions are made at three lifecycle stages—Open, In Progress, and Closed—and the authors conjecture that (1) accuracy improves as the ticket moves closer to implementation due to improved feature reliability, and (2) the predictive power of feature families changes across stages. The approach uses 72 features from seven families, a sliding-window validation protocol, three classifiers, and is evaluated on about 10,000 tickets from HIVE and HBASE. The results show accuracy gains over a random baseline that increase from Open to InProgress to Closed, and feature-family importance that shifts from developer/intrinsic signals early to JIT metrics at closure.

Significance. The paper proposes a genuinely new granularity for defect prediction—the ticket—and targets a practically important question: can teams identify potentially bug-inducing tickets before implementation begins? If the early-stage (Open) results are robust, they offer concrete value for triage and risk-aware assignment. The authors provide a broad feature catalog, reuse established JIT labels, and make datasets and scripts publicly available (Section 8), which strengthens reproducibility. However, the significance of the central monotonic-proximity claim is currently limited by confounds: the Closed-stage accuracy gains are inflated by target leakage, and the statistical pairing underlying the significance tests is questionable. With the Open and InProgress analyses properly cleaned, the paper would still constitute a useful empirical benchmark for upstream defect prediction.

major comments (4)
  1. [Section 5.1 / Section 3.1.1 / Table 7] The large accuracy gains reported for the Closed proximity point (Table 9: AUC over random from 37% to 67% in HBASE and from 43% to 76% in HIVE) are confounded by target leakage. The Closed treatment adds 15 JIT features (Table 7) computed from the commits linked to the ticket, while the label is defined as 'at least one commit implementing the ticket is buggy' (Section 3.3). The paper itself acknowledges this in Section 5.1: 'in Closed, we can leverage JIT features, thus using data about the actual code changes possibly including the bug we aim to predict.' As a result, the Closed-vs-InProgress contrast does not test conjecture (1), which attributes accuracy gains to improved feature reliability over time; it compares two prediction tasks with different feature sets, one of which observes the artifact whose status is the target. Please either remove JIT features from the Closed model when testing the temporal-proximity conjecture, or explicitly frame Closed as a post-implementation oracle rather than as evidence for conjecture (1).
  2. [Section 3.1.2 / Table 3 / Table 12 / Appendix A.1.3] The InProgress proximity point is defined as 'one second before the first commit' (Section 3.1.2), and Section 3.3 states that the evaluation is designed to avoid using future information. However, Table 12 reports commits_while_in_progress-count and commits_while_in_progress-churn among the top-10 features in the InProgress stage with mean IGR around 0.024-0.036. At the stated measurement time, these features should be zero (or undefined) for every ticket, since no commit has yet been made for the ticket; a constant feature cannot yield non-zero IGR. This contradiction suggests that the InProgress dataset may have been constructed using information from commits that occur later in the ticket's life, which would also undermine the Open-versus-InProgress comparison. Please clarify the exact computation time for these features and verify the temporal ordering of the constructed datasets.
  3. [Section 3.1.4 / Section 3.1.5 / Table 10] The Friedman test is used to compare the three proximity points, with the paper stating that 'each sliding window provides measurements for each of the three proximity points.' But the sliding window is built separately for each of the six datasets (two projects x three proximity points), and each dataset is ordered by the date of its own proximity point. Consequently, the i-th window in the Open dataset and the i-th window in the Closed dataset do not correspond to the same tickets or the same time period; the paired repeated-measures structure that the Friedman test requires is not established. This threatens the validity of the p-values and Kendall's W in Table 10. Please either align the windows across proximity points (e.g., by ticket cohort or calendar time) or use a statistical test that does not assume pairing.
  4. [Section 3.2.4 / Table 11] The RQ2 analysis reports a test of 'FeatureFamily, Proximity and their interaction' and states that 'we use the same as RQ1,' i.e., the Friedman test. The Friedman test is not designed to test interactions, and the paper does not describe how the repeated-measures factor is structured when the within-window unit is a feature family rather than a proximity point. Please specify the exact statistical procedure used to produce Table 11, including how IGR values are aggregated within each family and how the interaction term is defined.
minor comments (6)
  1. [Abstract / Section 1] The Abstract and Section 1 state that TLP leverages 'six different families' but then list seven families (Code, Developer, External Temperature, Internal Temperature, Intrinsic, Ticket-to-Tickets, JIT); correct the count.
  2. [Section 3.3] The 'NoSnoring' filter is described as 'we remove a ticket if within the last 20% of the tickets'; clarify whether this means the last 20% chronologically and explain how this mitigates snoring.
  3. [Table 9] Define the random baseline and clarify whether the reported percentages are relative improvements or percentage-point differences.
  4. [Section 3.1.4 / Table 11] The paper uses both 'sliding window' and 'moving window' terminology; unify the terms.
  5. [Table 6] The feature 'Average TF-IDF Text' appears twice with the same code name (buggy_similarity-avg_similarity_tfidf_cosine_title); the second occurrence should likely be ..._text.
  6. [Figure 4 caption] The caption mentions 'max and mean IGR, and max and mean selection' without defining 'selection'; clarify the quantities shown.

Circularity Check

1 steps flagged · score 6.0 of 10

Closed-stage accuracy gain is inflated by JIT features computed from the same commits that define the bug-inducing label.

  1. self definitional [Section 3.3 (label definition), Section 2.7/Table 7 (JIT features), Section 5.1 (acknowledged leakage)]
    "One possible explanation is that in Closed, we can leverage JIT features, thus using data about the actual code changes possibly including the bug we aim to predict."

    The TLP label is defined as 'a ticket is bug-inducing if, and only if, at least a commit implementing the ticket is buggy' (Section 3.3). The Closed stage adds 15 JIT features (Table 7) computed from those same linked implementing commits: jit-la-SUM, jit-ld-SUM, jit-nf-MAX, jit-ent-MAX, jit-nd-MAX, jit-ns-MAX, etc. Thus a Closed-stage model is trained on aggregate properties of the very commits whose buggy/non-buggy status constitutes the target. The large Closed-vs-InProgress AUC gain over random (37% to 67% in HBASE; 43% to 76% in HIVE, Table 9) is therefore largely a feature-leakage artifact, not a measure of improved feature reliability. The paper's own explanation concedes this in the quoted sentence.

full rationale

The paper's Open and InProgress evaluations are genuine predictions from pre-implementation features, and those comparisons are not circular. The reused buggy-commit labels from ApacheJIT are external data, not self-citations. However, the central RQ1 conclusion that TLP accuracy increases with proximity is strongly driven by the Closed stage, where the features are measured from the same commits whose bugginess defines the ticket label. The paper is transparent about this ('possibly including the bug we aim to predict'), but that transparency does not remove the by-construction overlap: the label is 'at least one linked commit is buggy', and the top Closed features are aggregate properties of those linked commits. The Closed-vs-InProgress gap in Table 9 is therefore not solely attributable to temporal proximity. Because the strongest claim relies on this leaked Closed comparison, while the earlier-stage results retain independent content, the appropriate score is 6: partial circularity in a central prediction claim.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

No new entities are introduced. The central claim rests on borrowing JIT ground-truth labels and ticket-commit links, on operational definitions of lifecycle stages, and on a statistical pairing assumption that we believe is violated. Free parameters are limited to experimental design choices from prior work.

free parameters (2)
  • sliding window size and step = 1000 initial training instances; 200-instance step
    Evaluation protocol taken from Patel et al. [75]; it controls the number of test batches and therefore the statistical power, but is not fitted to the target result.
  • NoSnoring cutoff = last 20% of tickets removed
    Post-hoc data selection to reduce dormant-defect label noise; it changes the time span and class composition of each project's dataset.
assumptions (4)
  • domain assumption JIT buggy labels from ApacheJIT/LeveragingJIT and the ticket-to-commit links are correct and complete enough to define ground truth for ticket defectiveness.
    Section 3.3 reuses existing JIT datasets; the paper itself lists the absence of ticket defectiveness ground truth as an internal validity threat (Section 7.2).
  • domain assumption A ticket is bug-inducing iff at least one of its linked commits is buggy.
    This operational definition (Section 3.3) equates ticket-level and commit-level defectiveness; mislinked or dormant-defect commits would mislabel tickets.
  • domain assumption Features measured at each proximity point are the features that would be available to a real user at that lifecycle stage.
    Section 3.1.2 measures Open one second before assignment and InProgress one second before first commit; real deployments may not have exactly these values (e.g., assignment may happen later or never).
  • ad hoc to paper Sliding-window indices provide paired repeated measures for the Friedman test across the three proximity datasets.
    Section 3.1.5 uses each window as a subject, but the Open, InProgress, and Closed datasets contain different tickets ordered by different dates; the pairing is not grounded in shared tickets or aligned calendar time.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Anticipating Bugs: Ticket-Level Bug Prediction and Temporal Proximity Effects." pith.science (2026). https://pith.science/paper/GD7HLQCF

@misc{pith2026250614290,
  author       = {Pith},
  title        = {Pith review of: Anticipating Bugs: Ticket-Level Bug Prediction and Temporal Proximity Effects},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GD7HLQCF}},
  note         = {Machine review of arXiv:2506.14290}
}
read the original abstract

The primary goal of bug prediction is to optimize testing efforts by focusing on software fragments, i.e., classes, methods, commits (JIT), or lines of code, most likely to be buggy. However, these predicted fragments already contain bugs. Thus, the current bug prediction approaches support fixing rather than prevention. The aim of this paper is to introduce and evaluate Ticket-Level Prediction (TLP), an approach to identify tickets that will introduce bugs once implemented. We analyze TLP at three temporal points, each point represents a ticket lifecycle stage: Open, In Progress, or Closed. We conjecture that: (1) TLP accuracy increases as tickets progress towards the closed stage due to improved feature reliability over time, and (2) the predictive power of features changes across these temporal points. Our TLP approach leverages 72 features belonging to six different families: code, developer, external temperature, internal temperature, intrinsic, ticket to tickets, and JIT. Our TLP evaluation uses a sliding-window approach, balancing feature selection and three machine-learning bug prediction classifiers on about 10,000 tickets of two Apache open-source projects. Our results show that TLP accuracy increases with proximity, confirming the expected trade-off between early prediction and accuracy. Regarding the prediction power of feature families, no single feature family dominates across stages; developer-centric signals are most informative early, whereas code and JIT metrics prevail near closure, and temperature-based features provide complementary value throughout. Our findings complement and extend the literature on bug prediction at the class, method, or commit level by showing that defect prediction can be effectively moved upstream, offering opportunities for risk-aware ticket triaging and developer assignment before any code is written.

Figures

Figures reproduced from arXiv: 2506.14290 by the authors.

Figure 1
Figure 1. Example of the proximity points of the HIVE-21783 ticket, its commits and lifecycle. [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 2
Figure 2. Distributions of TLP accuracy in three proximity points. [PITH_FULL_IMAGE:figures/full_fig_p010_2.png] view at source ↗
Figure 3
Figure 3. Distributions of TLP accuracy in terms of AUC achieved by a single feature family, in different proximity [PITH_FULL_IMAGE:figures/full_fig_p011_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Distributions of feature family power, in different proximity points and projects, in terms of max and mean [PITH_FULL_IMAGE:figures/full_fig_p012_4.png]
Figure 5
Figure 5. Figure 5: Bug-inducing issue distribution by type (a) HBASE (b) HIVE [PITH_FULL_IMAGE:figures/full_fig_p016_5.png]
Figure 6
Figure 6. Figure 6: Bug-inducing issue distribution by priority [PITH_FULL_IMAGE:figures/full_fig_p016_6.png]
Figure 7
Figure 7. Figure 7: Average AUC accuracy: moving window approach with and without feature selection and with and without [PITH_FULL_IMAGE:figures/full_fig_p027_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

102 extracted references · 59 canonical work pages

  1. [1]

    H. A. Ahmed, N. Z. Bawany, and J. A. Shamsi. 2021. Capbug-a framework for automatic bug categorization and prioritiza- tion using NLP and machine learning algorithms.IEEE Access, 9, 50496–50512. DOI: 10.1109/ACCESS.2021.3069248

    arXiv 2021

  2. [2]

    J. J. Ahonen and P. Savolainen. 2010. Software engineering projects may fail before they are started: post-mortem analysis of five cancelled projects. J. Syst. Softw., 83, 11, 2175–2187. DOI: 10.1016/J.JSS.2010.06.023

    work page doi:10.1016/j.jss.2010.06.023 2010

  3. [3]

    Antoniol, K

    G. Antoniol, K. Ayari, M. D. Penta, F. Khomh, and Y . Guéhéneuc. 2018. Is it a bug or an enhancement?: a text-based approach to classify change requests. In Proceedings of the 28th Annual International Conference on Computer Science and Software Engineering, CASCON 2018, Markham, Ontario, Canada, October 29-31, 2018 . I. Onut, A. Jaramillo, G. Jourdan, D....

    2018

  4. [4]

    Anwer, L

    S. Anwer, L. Wen, Z. Wang, and S. Mahmood. 2019. Comparative analysis of requirement change management challenges between in-house and global software development: findings of literature and industry survey. IEEE Access, 7, 116585– 116611. DOI: 10.1109/ACCESS.2019.2936664

    arXiv 2019

  5. [5]

    T. W. W. Aung, H. Huo, and Y . Sui. 2020. A literature review of automatic traceability links recovery for software change impact analysis. In ICPC ’20: 28th International Conference on Program Comprehension, Seoul, Republic of Korea, July 13-15, 2020. ACM, 14–24. DOI: 10.1145/3387904.3389251

    arXiv 2020

  6. [6]

    Bacchelli, M

    A. Bacchelli, M. D’Ambros, and M. Lanza. 2010. Are popular classes more defect prone? In Fundamental Approaches to Software Engineering, 13th International Conference, FASE 2010, Held as Part of the Joint European Conferences on Theory and Practice of Software, ETAPS 2010, Paphos, Cyprus, March 20-28, 2010. Proceedings (Lecture Notes in Computer Science)....

    work page doi:10.1007/978-3-642-12 2010

  7. [7]

    Baeza-Yates, B

    R. Baeza-Yates, B. Ribeiro-Neto, et al. 1999. Modern information retrieval. Number 1999. V ol. 463. ACM press New York. 19 Anticipating Bugs: Ticket-Level Bug Prediction and Temporal Proximity Effects A PREPRINT

    1999

  8. [8]

    G. R. Bergersen, D. I. K. Sjøberg, and T. Dybå. 2014. Construction and validation of an instrument for measuring program- ming skill. IEEE Trans. Software Eng., 40, 12, 1163–1184. DOI: 10.1109/TSE.2014.2348997

    work page arXiv 2014

Show all 102 references
  1. [9]

    D. M. Berry and B. Lawrence. 1998. Requirements engineering. IEEE software, 15, 2, 26–29

    1998

  2. [10]

    Boehm and V

    B. Boehm and V . R. Basili. 2007. Software defect reduction top 10 list. Software engineering: Barry W. Boehm’s lifetime contributions to software development, management, and research, 34, 1, 75

    2007

  3. [11]

    A. S. Bordin and F. B. V . Benitti. 2018. Software maintenance: what do we teach and what does the industry practice? In Proceedings of the XXXII Brazilian Symposium on Software Engineering, SBES 2018, Sao Carlos, Brazil, September 17-21, 2018. U. Kulesza, (Ed.) ACM, 270–279. ...

    2018

  4. [12]

    G. E. Box, G. M. Jenkins, G. C. Reinsel, and G. M. Ljung. 2015. Time series analysis: forecasting and control. John Wiley & Sons

    2015

  5. [13]

    P. J. Brockwell and R. A. Davis. 2002. Introduction to time series and forecasting. Springer

    2002

  6. [14]

    G. G. Cabral, L. L. Minku, A. L. I. Oliveira, D. A. Pessoa, and S. Tabassum. 2023. An investigation of online and offline learning models for online just-in-time software defect prediction. Empir. Softw. Eng., 28, 5, 121. DOI: 10.1007/S10664 -023-10335-6

    2023 doi

  7. [15]

    A. S. Cairo, G. de Figueiredo Carneiro, and M. P. Monteiro. 2018. The impact of code smells on software bugs: A systematic literature review. Inf., 9, 11, 273. DOI: 10.3390/INFO9110273

    2018 doi

  8. [16]

    A. D. Carleton, D. Falessi, H. Zhang, and X. Xia. 2024. Generative AI: redefining the future of software engineering. IEEE Softw., 41, 6, 34–37. DOI: 10.1109/MS.2024.3441889

    2024

  9. [17]

    Carlson and P

    N. Carlson and P. A. Laplante. 2014. The NASA automated requirements measurement tool: a reconstruction. Innov. Syst. Softw. Eng., 10, 2, 77–91. DOI: 10.1007/S11334-013-0225-8

    2014 doi

  10. [18]

    N. V . Chawla, K. W. Bowyer, L. O. Hall, and W. P. Kegelmeyer. 2002. SMOTE: synthetic minority over-sampling tech- nique. J. Artif. Intell. Res., 16, 321–357. DOI: 10.1613/JAIR.953

    2002 doi

  11. [19]

    Choetkiertikul, H

    M. Choetkiertikul, H. K. Dam, T. Tran, T. Pham, A. Ghose, and T. Menzies. 2019. A deep learning model for estimating story points. IEEE Trans. Software Eng., 45, 7, 637–656. DOI: 10.1109/TSE.2018.2792473

    2019

  12. [20]

    Copeland

    T. Copeland. 2005. PMD applied. V ol. 10

    2005

  13. [21]

    Crespo Márquez

    A. Crespo Márquez. 2022. The curse of dimensionality. In Digital Maintenance Management: Guiding Digital Transfor- mation in Maintenance. Springer, 67–86

    2022

  14. [22]

    D’Ambros, M

    M. D’Ambros, M. Lanza, and R. Robbes. 2010. An extensive comparison of bug prediction approaches. In 2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010), 31–41. DOI: 10.1109/MSR.2010.5463279

    2010

  15. [23]

    Falessi, A

    D. Falessi, A. Ahluwalia, and M. D. Penta. 2022. The impact of dormant defects on defect prediction: A study of 19 apache projects. ACM Trans. Softw. Eng. Methodol., 31, 1, 4:1–4:26. DOI: 10.1145/3467895

    2022 doi

  16. [25]

    Falessi, J

    D. Falessi, J. Huang, L. Narayana, J. F. Thai, and B. Turhan. 2020. On the need of preserving order of data when validating within-project defect classifiers. Empir. Softw. Eng., 25, 6, 4805–4830. DOI: 10.1007/s10664-020-09868-x

    2020 doi

  17. [26]

    Falessi, S

    D. Falessi, S. M. Laureani, J. Çarka, M. Esposito, and D. A. da Costa. 2023. Enhancing the defectiveness prediction of methods and classes via JIT. Empir. Softw. Eng., 28, 2, 37. DOI: 10.1007/S10664-022-10261-Z

    2023 doi

  18. [27]

    Falessi, J

    D. Falessi, J. Roll, J. L. C. Guo, and J. Cleland-Huang. 2020. Leveraging historical associations between requirements and source code to identify impacted classes.IEEE Trans. Software Eng., 46, 4, 420–441. DOI: 10.1109/TSE.2018.2861735

    2020

  19. [28]

    Falessi, B

    D. Falessi, B. Russo, and K. Mullen. 2017. What if I had no smells? In 2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, ESEM 2017, Toronto, ON, Canada, November 9-10, 2017 . A. Bener, B. Turhan, and S. Biffl, (Eds.) IEEE Computer Society...

    2017 doi

  20. [29]

    Faragó, P

    C. Faragó, P. Hegedüs, and R. Ferenc. 2015. Cumulative code churn: impact on maintainability. In 15th IEEE International Working Conference on Source Code Analysis and Manipulation, SCAM 2015, Bremen, Germany, September 27-28, 2015. M. W. Godfrey, D. Lo, and F. Khomh, (Eds.) I...

    2015

  21. [30]

    Femmer, D

    H. Femmer, D. M. Fernández, S. Wagner, and S. Eder. 2017. Rapid quality assurance with requirements smells. J. Syst. Softw., 123, 190–213. DOI: 10.1016/J.JSS.2016.02.047

    2017 doi

  22. [31]

    Ferrari, G

    A. Ferrari, G. Gori, B. Rosadini, I. Trotta, S. Bacherini, A. Fantechi, and S. Gnesi. 2018. Detecting requirements defects with nlp patterns: an industrial experience in the railway domain. Empirical Software Engineering, 23, 6, 3684–3733

    2018

  23. [32]

    A. R. Florita and G. P. Henze. 2009. Comparison of short-term weather forecasting models for model predictive control. HVAC&R Research, 15, 5, 835–853

    2009

  24. [33]

    M. Fowler. 1999. Refactoring - Improving the Design of Existing Code. Addison Wesley object technology series. Addison- Wesley. ISBN : 978-0-201-48567-7. http://martinfowler.com/books/refactoring.html

    1999

  25. [34]

    Friedman

    M. Friedman. 1937. The use of ranks to avoid the assumption of normality implicit in the analysis of variance. Journal of the American Statistical Association, 32, 200, 675–701. Retrieved Apr. 10, 2025 from http://www.jstor.org/stable /2279372

    1937

  26. [35]

    W. Fu, T. Menzies, and X. Shen. 2016. Tuning for software analytics: is it really necessary? Inf. Softw. Technol., 76, 135–

    2016

  27. [36]

    Gentili, J

    E. Gentili, J. Çarka, and D. Falessi. 2024. A systematic mapping study on impact analysis. In Proceedings of the 19th International Conference on Software Technologies, ICSOFT 2024, Dijon, France, July 8-10, 2024. H. Fill, F. J. D. Mayo, M. van Sinderen, and L. A. Maciaszek, (...

    2024 doi

  28. [37]

    Gentili and D

    E. Gentili and D. Falessi. 2023. Characterizing requirements smells. In Product-Focused Software Process Improvement - 24th International Conference, PROFES 2023, Dornbirn, Austria, December 10-13, 2023, Proceedings, Part I (Lecture Notes in Computer Science). R. Kadgien, A. J...

    2023 doi

  29. [38]

    Ghezzi, M

    C. Ghezzi, M. Jazayeri, and D. Mandrioli. 1991. Fundamentals of software engineering. Prentice-Hall, Inc

    1991

  30. [39]

    Ghotra, S

    B. Ghotra, S. McIntosh, and A. E. Hassan. 2015. Revisiting the impact of classification techniques on the performance of defect prediction models. In 37th IEEE/ACM International Conference on Software Engineering, ICSE 2015, Florence, Italy, May 16-24, 2015, Volume 1. A. Berto...

    2015 doi

  31. [40]

    J. D. Gibbons and S. Chakraborti. 2014. Nonparametric statistical inference: revised and expanded. CRC press

    2014

  32. [41]

    Graves and A

    A. Graves and A. Graves. 2012. Long short-term memory. Supervised sequence labelling with recurrent neural networks, 37–45

    2012

  33. [42]

    Grover, A

    A. Grover, A. Kapoor, and E. Horvitz. 2015. A deep hybrid model for weather forecasting. In Proceedings of the 21th ACM SIGKDD international conference on knowledge discovery and data mining, 379–386

    2015

  34. [43]

    X. Gu, Y . Han, S. Kim, and H. Zhang. 2021. Do bugs propagate? an empirical analysis of temporal correlations among software bugs. A. Møller and M. Sridharan, (Eds.) (2021). DOI: 10.4230/LIPICS.ECOOP.2021.11

    2021 doi

  35. [44]

    Z. Gu, E. T. Barr, D. J. Hamilton, and Z. Su. 2010. Has the bug really been fixed? In Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 1, ICSE 2010, Cape Town, South Africa, 1-8 May 2010 . J. Kramer, J. Bishop, P. T. Devanbu, and S. Uc...

    2010

  36. [45]

    Herzig, S

    K. Herzig, S. Just, and A. Zeller. 2013. It’s not a bug, it’s a feature: how misclassification impacts bug prediction. In 35th International Conference on Software Engineering, ICSE ’13, San Francisco, CA, USA, May 18-26, 2013. D. Notkin, B. H. C. Cheng, and K. Pohl, (Eds.) IE...

    2013

  37. [46]

    Hou et al

    X. Hou et al. 2024. Large language models for software engineering: A systematic literature review. ACM Trans. Softw. Eng. Methodol., 33, 8, 220:1–220:79. DOI: 10.1145/3695988

    2024 doi

  38. [47]

    Huang, H

    Z. Huang, H. Yu, G. Fan, Z. Shao, Z. Zhou, and M. Li. 2024. On the effectiveness of developer features in code smell prioritization: a replication study. Journal of Systems and Software, 210, 111968. DOI: https://doi.org/10.1016/j.j ss.2024.111968

    2024

  39. [48]

    M. E. C. Hull, K. Jackson, and J. Dick, (Eds.) 2011. Requirements Engineering, Third Edition. Springer. ISBN : 978-1-8499- 6404-3. DOI: 10.1007/978-1-84996-405-0

    2011 doi

  40. [49]

    INCOSE. 2023. INCOSE systems engineering handbook. John Wiley & Sons

    2023

  41. [50]

    Iso/iec/ieee international standard - systems and software engineering – life cycle processes – requirements engineer- ing

    2018. Iso/iec/ieee international standard - systems and software engineering – life cycle processes – requirements engineer- ing. ISO/IEC/IEEE 29148:2018(E), 1–104. DOI: 10.1109/IEEESTD.2018.8559686

    2018

  42. [51]

    P. Jaccard. 1901. Étude comparative de la distribution florale dans une portion des alpes et des jura. Bull Soc Vaudoise Sci Nat, 37, 547–579

    1901

  43. [52]

    James, D

    G. James, D. Witten, T. Hastie, R. Tibshirani, and J. Taylor. 2023. An introduction to statistical learning: With applications in python. Springer Nature

    2023

  44. [53]

    Jiang, B

    Y . Jiang, B. Cukic, and T. Menzies. 2007. Fault prediction using early lifecycle data. In ISSRE 2007, The 18th IEEE International Symposium on Software Reliability, Trollhättan, Sweden, 5-9 November 2007. IEEE Computer Society, 237–

    2007

  45. [54]

    M. I. Kamata and T. Tamai. 2007. How does requirements quality relate to project success or failure? In 15th IEEE In- ternational Requirements Engineering Conference, RE 2007, October 15-19th, 2007, New Delhi, India . IEEE Computer Society, 69–78. DOI: 10.1109/RE.2007.31

    2007 doi

  46. [55]

    Kamei and E

    Y . Kamei and E. Shihab. 2016. Defect prediction: accomplishments and future challenges. In Leaders of Tomorrow Sym- posium: Future of Software Engineering, FOSE@SANER 2016, Osaka, Japan, March 14, 2016 . IEEE Computer Society, 33–45. DOI: 10.1109/SANER.2016.56

    2016 doi

  47. [56]

    Kamei, E

    Y . Kamei, E. Shihab, B. Adams, A. E. Hassan, A. Mockus, A. Sinha, and N. Ubayashi. 2013. A large-scale empirical study of just-in-time quality assurance. IEEE Trans. Software Eng., 39, 6, 757–773. DOI: 10.1109/TSE.2012.70

    2013 doi

  48. [57]

    M. J. Keeling and P. Rohani. 2008. Modeling infectious diseases in humans and animals. Princeton university press

    2008

  49. [58]

    M. G. Kendall and B. B. Smith. 1939. The problem of m rankings. The Annals of Mathematical Statistics, 10, 3, 275–287. Retrieved Apr. 10, 2025 from http://www.jstor.org/stable/2235668

    1939

  50. [59]

    Keshavarz and M

    H. Keshavarz and M. Nagappan. 2022. Apachejit: A large dataset for just-in-time defect prediction. In 19th IEEE/ACM International Conference on Mining Software Repositories, MSR 2022, Pittsburgh, PA, USA, May 23-24, 2022 . ACM, 191–195. DOI: 10.1145/3524842.3527996

    2022

  51. [60]

    P. S. Kochhar, D. Wijedasa, and D. Lo. 2016. A large scale study of multiple programming languages and code quality. In IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering, SANER 2016, Suita, Osaka, Japan, March 14-18, 2016 - Volume 1. IEEE Co...

    2016 doi

  52. [61]

    T. Lee, J. Nam, D. Han, S. Kim, and H. P. In. 2016. Developer micro interaction metrics for software defect prediction. IEEE Trans. Software Eng., 42, 11, 1015–1035. DOI: 10.1109/TSE.2016.2550458

    2016

  53. [62]

    S. Lehnert. 2011. A taxonomy for software change impact analysis. In Proceedings of the 12th International Workshop on Principles of Software Evolution and the 7th annual ERCIM Workshop on Software Evolution, EVOL/IWPSE 2011, Szeged, Hungary, September 5-6, 2011. A. Cleve and ...

    2011

  54. [63]

    Lessmann, B

    S. Lessmann, B. Baesens, C. Mues, and S. Pietsch. 2008. Benchmarking classification models for software defect predic- tion: A proposed framework and novel findings.IEEE Trans. Software Eng., 34, 4, 485–496. DOI: 10.1109/TSE.2008.35

    2008 doi

  55. [64]

    P. Li. 2018. Jira Software Essentials: Plan, track, and release great applications with Jira Software. Packt Publishing Ltd

    2018

  56. [65]

    Z. Li, Q. Du, H. Zhang, X. Jing, and F. Wu. 2024. An empirical study of data sampling techniques for just-in-time software defect prediction. Autom. Softw. Eng., 31, 2, 56. DOI: 10.1007/S10515-024-00455-8

    2024 doi

  57. [66]

    A. W. Lo and A. C. MacKinlay. 2011. A non-random walk down Wall Street. Princeton University Press

    2011

  58. [67]

    E. N. Lorenz. 1963. Deterministic nonperiodic flow. Journal of atmospheric sciences, 20, 2, 130–141

    1963

  59. [68]

    C. D. Manning, P. Raghavan, and H. Schütze. 2008. Introduction to Information Retrieval . Cambridge University Press, Cambridge, UK

    2008

  60. [69]

    Matsumoto, Y

    S. Matsumoto, Y . Kamei, A. Monden, K. Matsumoto, and M. Nakamura. 2010. An analysis of developer metrics for fault prediction. In Proceedings of the 6th International Conference on Predictive Models in Software Engineering, PROMISE 2010, Timisoara, Romania, September 12-13, 2...

    2010 doi

  61. [70]

    McIntosh and Y

    S. McIntosh and Y . Kamei. 2018. Are fix-inducing changes a moving target? A longitudinal case study of just-in-time defect prediction. IEEE Trans. Software Eng., 44, 5, 412–428. DOI: 10.1109/TSE.2017.2693980

    2018

  62. [71]

    Mikolov, K

    T. Mikolov, K. Chen, G. Corrado, and J. Dean. 2013. Linguistic regularities in continuous space word representations. In Proceedings of the International Conference on Learning Representations (ICLR). http://arxiv.org/abs/1301.3781

    2013 arXiv

  63. [72]

    Orrell, L

    D. Orrell, L. Smith, J. Barkmeijer, and T. N. Palmer. 2001. Model error in weather forecasting. Nonlinear processes in geophysics, 8, 6, 357–371

    2001

  64. [73]

    Osman, M

    H. Osman, M. Ghafari, and O. Nierstrasz. 2018. The impact of feature selection on predicting the number of bugs. arXiv preprint arXiv:1807.04486

    2018 arXiv

  65. [74]

    Ozakinci and A

    R. Ozakinci and A. Tarhan. 2018. Early software defect prediction: A systematic map and review. J. Syst. Softw., 144, 216–239. DOI: 10.1016/J.JSS.2018.06.025

    2018 doi

  66. [75]

    Patel, B

    H. Patel, B. Adams, and A. E. Hassan. 2024. Post deployment recycling of machine learning models. Empir. Softw. Eng., 29, 4, 100. DOI: 10.1007/S10664-024-10492-2

    2024 doi

  67. [76]

    D. E. Perry, H. P. Siy, and L. G. V otta. 2001. Parallel changes in large-scale software development: an observational case study. ACM Trans. Softw. Eng. Methodol., 10, 3, 308–337. DOI: 10.1145/383876.383878

    2001

  68. [77]

    Pinzger, N

    M. Pinzger, N. Nagappan, and B. Murphy. 2008. Can developer-module networks predict failures? In Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of Software Engineering, 2008, Atlanta, Georgia, USA, November 9-14, 2008. M. J. Harrold and G. C. Murphy...

    2008

  69. [78]

    Salton and C

    G. Salton and C. Buckley. 1988. Term-weighting approaches in automatic text retrieval. Information processing & man- agement, 24, 5, 513–523

    1988

  70. [79]

    R. H. Shumway, D. S. Stoffer, R. H. Shumway, and D. S. Stoffer. 2017. Arima models. Time series analysis and its applications: with R examples, 75–163

    2017

  71. [80]

    K. Smith. 2016. Managing electronic resource workflows using ticketing system software. Serials Review, 42, 1, 59–64

    2016

  72. [81]

    Song and L

    L. Song and L. L. Minku. 2023. A procedure to continuously evaluate predictive performance of just-in-time software defect prediction models during software development. IEEE Trans. Software Eng., 49, 2, 646–666. DOI: 10.1109/TSE.2 022.3158831

    2023 doi

  73. [82]

    W. Sun, Z. Guo, M. Yan, Z. Liu, Y . Lei, and H. Zhang. 2024. Method-level test-to-code traceability link construction by semantic correlation learning. IEEE Trans. Software Eng., 50, 10, 2656–2676. DOI: 10.1109/TSE.2024.3449917

    2024

  74. [83]

    S. B. Taieb, G. Bontempi, A. Sorjamaa, and A. Lendasse. 2009. Long-term prediction of time series by combining direct and MIMO strategies. In International Joint Conference on Neural Networks, IJCNN 2009, Atlanta, Georgia, USA, 14-19 June 2009. IEEE Computer Society, 3054–3061...

    2009

  75. [84]

    Takerngsaksiri et al

    W. Takerngsaksiri et al. 2025. Human-in-the-loop software development agents. (2025). https://arxiv.org/abs/241 1.12924 arXiv: 2411.12924 [cs.SE]

    2025 arXiv

  76. [85]

    Tantithamthavorn, A

    C. Tantithamthavorn, A. E. Hassan, and K. Matsumoto. 2020. The impact of class rebalancing techniques on the perfor- mance and interpretation of defect prediction models. IEEE Trans. Software Eng. , 46, 11, 1200–1219. DOI: 10 . 1109 /TSE.2018.2876537

    2020

  77. [86]

    Tantithamthavorn, S

    C. Tantithamthavorn, S. McIntosh, A. E. Hassan, and K. Matsumoto. 2016. An empirical comparison of model validation techniques for defect prediction models. IEEE Transactions on Software Engineering, 43, 1, 1–18

    2016

  78. [87]

    Tantithamthavorn, S

    C. Tantithamthavorn, S. McIntosh, A. E. Hassan, and K. Matsumoto. 2019. The impact of automated parameter optimization on defect prediction models. IEEE Trans. Software Eng., 45, 7, 683–711. DOI: 10.1109/TSE.2018.2794977

    2019

  79. [88]

    Valdez, H

    A. Valdez, H. Oktaba, H. Gómez, and A. Vizcaíno. 2020. Sentiment analysis in jira software repositories. In 2020 8th International Conference in Software Engineering Research and Innovation (CONISOFT), 254–259. DOI: 10.1109/CONI SOFT50191.2020.00043. 22 Anticipating Bugs: Tick...

    2020

  80. [89]

    C. Wang, Y . Li, L. Chen, W. Huang, Y . Zhou, and B. Xu. 2020. Examining the effects of developer familiarity on bug fixing. J. Syst. Softw., 169, 110667. DOI: 10.1016/J.JSS.2020.110667

    2020

  81. [90]

    K. E. Wiegers and J. Beatty. 2013. Software requirements. Pearson Education

    2013

  82. [91]

    W. M. Wilson, L. H. Rosenberg, and L. E. Hyatt. 1997. Automated analysis of requirement specifications. In Pulling Together, Proceedings of the 19th International Conference on Software Engineering, Boston, Massachusetts, USA, May 17-23, 1997. W. R. Adrion, A. Fuggetta, R. N. ...

    1997 doi

  83. [92]

    Winter, D

    E. Winter, D. Bowes, S. Counsell, T. Hall, S. O. Haraldsson, V . Nowack, and J. R. Woodward. 2023. How do developers really feel about bug fixing? directions for automatic program repair. IEEE Trans. Software Eng., 49, 4, 1823–1841. DOI: 10.1109/TSE.2022.3194188

    2023

  84. [93]

    I. H. Witten and E. Frank. 2002. Data mining: practical machine learning tools and techniques with java implementations. Acm Sigmod Record, 31, 1, 76–77

    2002

  85. [94]

    C. Wohlin. 2014. Guidelines for snowballing in systematic literature studies and a replication in software engineering. In 18th International Conference on Evaluation and Assessment in Software Engineering, EASE ’14, London, England, United Kingdom, May 13-14, 2014. M. J. Shep...

    2014

  86. [95]

    Wohlin, P

    C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, and A. Wesslén. 2024. Experimentation in Software Engineer- ing, Second Edition. Springer. ISBN : 978-3-662-69305-6. DOI: 10.1007/978-3-662-69306-3

    2024 doi

  87. [96]

    H. Zhang. 2009. An investigation of the relationships between lines of code and defects. In 25th IEEE International Con- ference on Software Maintenance (ICSM 2009), September 20-26, 2009, Edmonton, Alberta, Canada . IEEE Computer Society, 274–283. DOI: 10.1109/ICSM.2009.5306304

    2009

  88. [97]

    Zhang and B

    L. Zhang and B. Liu. 2017. Sentiment analysis and opinion mining. In Encyclopedia of Machine Learning and Data Mining. C. Sammut and G. I. Webb, (Eds.) Springer, 1152–1161. DOI: 10.1007/978-1-4899-7687-1\_907

    2017 doi

  89. [98]

    Zhang, J

    T. Zhang, J. Chen, G. Yang, B. Lee, and X. Luo. 2016. Towards more accurate severity prediction and fixer recommendation of software bugs. J. Syst. Softw., 117, 166–184. DOI: 10.1016/J.JSS.2016.02.034

    2016 doi

  90. [99]

    K. Zhao, Z. Xu, M. Yan, T. Zhang, D. Yang, and W. Li. 2021. A comprehensive investigation of the impact of feature selection techniques on crashing fault residence prediction models. Information and Software Technology, 139, 106652. DOI: https://doi.org/10.1016/j.infsof.2021.106652

    2021

  91. [100]

    Y . Zhao, K. Damevski, and H. Chen. 2023. A systematic survey of just-in-time software defect prediction. ACM Comput. Surv., 55, 10, 201:1–201:35. DOI: 10.1145/3567550

    2023 doi

  92. [101]

    if," "when,

    T. Zimmermann, N. Nagappan, H. C. Gall, E. Giger, and B. Murphy. 2009. Cross-project defect prediction: a large scale experiment on data vs. domain vs. process. In Proceedings of the 7th joint meeting of the European Software Engineering Conference and the ACM SIGSOFT Internat...

    2009

  93. [146]

    20 Anticipating Bugs: Ticket-Level Bug Prediction and Temporal Proximity Effects A PREPRINT

    DOI: 10.1016/J.INFSOF.2016.04.017. 20 Anticipating Bugs: Ticket-Level Bug Prediction and Temporal Proximity Effects A PREPRINT

    2016 doi

  94. [246]

    DOI: 10.1109/ISSRE.2007.24

    2007 doi

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.