Pith. sign in

REVIEW 3 major objections 5 minor 53 references

Gotta catch 'em all! Towards File Localisation from Issues at Large

T0 review · 3 major / 5 minor · reviewed 2026-08-15 · deepseek-v4-flash

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

Pith's one-line read For unrestricted issue types, plain BM25 beats bug-tuned localisation methods, and the bug-specific rVSM ranks last.

desk verdict The dataset and pipeline are a real contribution; the bug-specific-heuristics claim overreaches because it rests on one confounded method (rVSM) without ablation or significance testing. read the letter →

arxiv 2507.18319 v1 pith:3L3BCSTA submitted 2025-07-24 cs.SE

Jesse Maarleveld , Jiapan Guo , Daniel Feitosa This is my paper · ORCID
classification cs.SE
keywords filelocalisationissuetrackingsystemsinformationretrievalBM25bugdatasetconstructionJiraempiricalsoftwareengineering
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

The paper argues that file localisation should be studied for all issue types, not only bugs, and that methods tuned for bugs do not carry over to this broader task. To make that case, the authors built a new dataset of seven medium-sized open-source projects, linking commits to Jira issues without filtering by issue type, and evaluated five information-retrieval baselines against it. Their central finding is that BM25 outperforms every other method on every evaluation metric, while rVSM, a vector-space model modified with bug-specific heuristics such as file-length weighting, performs worst. Statistical tests show that issue type and the number of identifiers in an issue have small but often statistically significant effects, and that these effects vary from project to project. If the result holds, it implies that general-purpose localisation models, not bug-specialised ones, should be the target for future work.

What carries the argument

The carrying mechanism is the dataset-construction pipeline. It links commits to issues by matching a project key in the first line of the commit message, keeps only issues whose linked commits all lie on one path from the repository root to the current head, disambiguates merge commits by checking whether the merged branch already contains issue-linked commits, and uses the files changed by the first linked commit as ground truth for a 'first commit only' variant of the localisation problem. Against this corpus, the paper compares five retrieval methods. BM25, here used with a multi-field extension that scores file name and file content as separate weighted fields, is the strongest baseline, while rVSM's added file-length term is the bug-specific component that the results identify as harmful.

What would settle it

Manually untangle a sample of the issue-linked commits in these seven projects and rerun the same retrieval methods on the cleaned ground truth; if rVSM matches or beats BM25 once false links from tangled and revert commits are removed, the paper's main conclusion would be overturned. A second check: recompute the identifier correlation after removing issues that already name the target file; if the correlation vanishes, the identifier effect is label leakage rather than a real performance signal.

Watch

Extended reading notes

Core claim

On a new dataset containing unrestricted issue types from seven projects, the standard BM25 ranking function achieves the best average performance on every reported metric (for example P@1 of 0.321, hit@5 of 0.573, hit@10 of 0.666, and MRR of 0.438), while rVSM, which adapts TF-IDF with a logistic file-length weighting intended for bugs, ranks last on every metric. The authors interpret this as evidence that bug-specific heuristics degrade performance when the task is localising files for issues in general, and that dimensionality reduction via LSI does not help either. They further find that issue type and the presence of identifiers and file names in the issue text have statistically significant but small effects on performance, with the direction and size of the effects depending strongly on the project. No single issue type is detrimental to overall performance, and identifiers help most for bugs and improvements, not for new features.

Load-bearing premise

The labels assume that every file changed in a commit whose message mentions an issue is exactly a file that should be localised for that issue, and that all issues named in a commit share all of that commit's changes.

Editorial extensions

If this is right

  • New file-localisation work targeting general issue types should use BM25 as its reference baseline rather than bug-tuned models.
  • Dataset builders should avoid assuming a GitHub pull-request workflow; the proposed pipeline admits arbitrary branching and merging, making it usable across Git workflows.
  • Evaluating only on bugs can overstate the value of bug-specific heuristics, so future benchmarks should include a spread of issue types.
  • Small but real project-dependent differences in issue-type and identifier effects imply that adaptable, per-project models may be needed rather than one universal ranking method.
  • The 'first commit only' variant gives a tractable starting point; the harder variants defined in the paper, predicting all future files or exact successive commits, are left as open problems.

Reading between the lines

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

  • A natural extension is to test whether transformer-based or LLM rankers can beat BM25 on this unrestricted dataset; if they cannot, lexical term matching may be the practical ceiling for issue-to-file retrieval.
  • The pipeline's single-path requirement implicitly discards issues developed on parallel branches, which may bias the dataset toward linearly developed issues; quantifying what is excluded would clarify how far the results generalise.
  • The rVSM result could be probed by ablating its components individually, such as log term-frequency weighting versus file-length weighting, to isolate which bug-specific heuristic hurts most outside the bug setting.
  • For practitioners, the modest positive correlation between identifiers and performance suggests that prompting issue writers to mention file and symbol names could improve automated localisation, but the project-dependence of the effect means the gain is not guaranteed.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. This paper presents a pipeline for constructing issue-to-file localisation datasets from arbitrary Git branching and merging workflows, a new dataset of seven Jira-hosted projects with unrestricted issue types, and an evaluation of traditional IR baselines (VSM, LSI-500, LSI-1000, rVSM, BM25). RQ1 compares the methods, RQ2 tests the effect of issue type, and RQ3 tests the correlation between the number of identifiers/file names and retrieval performance. The paper reports that BM25 is the best method and rVSM the worst, that issue-type effects are small but statistically significant, that identifier presence has a weak effect, and that results are strongly project-dependent.

Significance. If the empirical claims hold, the main contribution is a reusable dataset-construction pipeline that removes bug-only filtering and deliberately addresses merge-commit ambiguity, together with baseline results for general-issue file localisation. The replication package, the temporal split, the reporting of effect sizes, and the explicit threats-to-validity discussion are strengths. However, the headline claim that 'methods designed using bug-specific heuristics perform poorly' is currently supported only by the behaviour of a single confounded method, rVSM, and the statistical claims in RQ2/RQ3 need a multiple-comparison check. With those points addressed, the paper would be a useful and appropriately cautious exploratory study.

major comments (3)
  1. [§4.1, §5.1, Table 3, Eqs. (2)-(3)] The conclusion that 'methods designed using bug-specific heuristics perform poorly on general issue types' (Abstract, RQ1 takeaways, and §5.1) is supported only by rVSM being the worst method in Table 3. rVSM differs from plain VSM in two coupled ways: it uses log(f(w,D)+1) instead of f(w,D)/|D|, and it multiplies the cosine similarity by the file-length sigmoid in Eqs. (2)-(3). Only the second modification encodes the bug-specific 'longer files are more likely to contain bugs' prior; the first is a general IR term-weighting choice. The paper does not ablate the length factor, so the observed deficit could be explained by rVSM's older term weighting or by the absence of BM25's term-frequency saturation and field weighting rather than by the bug-specific heuristic. Table 3 also reports only unweighted means over seven projects, with no paired significance test or confidence intervals for the method ordering. Please add an ablation isolating the length factor and a paired test across projects, or restrict the claim to 'rVSM performs worst on this dataset'.
  2. [§3.7.2, §3.7.3, Tables 5-7] RQ2 and RQ3 each perform a large number of statistical tests (seven projects times several metrics) at alpha = 0.05 without any multiple-comparison correction. Under this many tests, the observation that many correlations in Table 7 are 'almost always significant' is expected even under the null, and the same concern applies to the Kruskal-Wallis results in Table 5. The paper should apply a correction such as Benjamini-Hochberg, or explicitly label these analyses as exploratory and rely on effect sizes rather than raw p-values. This matters because 'small, but statistically significant differences' is stated as a finding in the abstract and conclusion.
  3. [§3.3.2, §5.2] The label construction assumes that all files changed in a commit are relevant to every issue mentioned in that commit's message, and that every mentioned issue is relevant to all changes in the commit. The paper acknowledges this in §5.2, which is commendable, but since the dataset is a core contribution and all performance numbers inherit this noise, the manuscript should include at least a sensitivity analysis, e.g., restricted to issues linked to exactly one commit, or a discussion of the likely direction of bias. Without such an analysis, the absolute performance numbers in Tables 3 and 4 should be read as noisy estimates rather than reliable benchmarks.
minor comments (5)
  1. [§3.5.4] There is a typo in 'documennt length'; it should read 'document length'.
  2. [§4.3] The phrase 'statically significant correlations' should be 'statistically significant correlations'.
  3. [References] Reference [28] lists the second author as 'Raghaven'; the correct spelling is 'Raghavan'.
  4. [Table 3] Please clarify whether Table 3 reports an unweighted mean over projects or a mean over all issues; because projects vary greatly in dataset size, the two averages can behave differently.
  5. [Tables 5 and 6] The project abbreviation is spelled 'TomEE' in Table 5 and the text but 'Tomee' in Table 6; please make the spelling consistent.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity; only a minor non-load-bearing self-citation in the dataset/preprocessing foundation.

full rationale

The paper's central claims are empirical evaluations on a freshly constructed dataset. The comparisons between BM25, rVSM, LSI, and TF-IDF are direct applications of deterministic information retrieval algorithms with fixed, recommended parameters; no parameter is fitted to the issue-localisation labels and then reported as a prediction. The headline result that BM25 outperforms rVSM on general issue types is therefore a measured outcome, not a consequence of any equation reducing to its own input. The only self-citation is reference [27], the authors' earlier Maestro work, used as the source of Jira issue data and as the basis for preprocessing ('The pre-processing is based on [27]' and 'We used the dataset from [27]'). This citation is not load-bearing for the central comparison: it supplies data and preprocessing choices, but it does not determine the ranking of BM25 relative to rVSM, nor does it define the evaluation metrics or the statistical tests. The rVSM interpretation is arguably confounded because rVSM differs from plain VSM in both term weighting and the file-length prior, and no ablation isolates the bug-specific length heuristic; however, this is a validity threat about causal attribution, not a circularity in the derivation. No self-definitional step, fitted-input-as-prediction, or imported uniqueness theorem appears in the paper. Accordingly, the appropriate finding is no significant circularity, with a score of 2 reflecting only the minor, non-load-bearing self-citation to prior work by the same authors.

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

The central claim rests on empirical label construction rather than on a theoretical derivation. The free parameters are retrieval hyperparameters and preprocessing choices, all selected transparently and not fitted to the test set. The four domain assumptions concern the validity of the ground-truth labels and the scope of the dataset; each is stated in the paper and at least partially discussed as a threat.

free parameters (3)
  • BM25 parameters k1, b, delta = k1=1.2, b=0.75, delta=1.0
    Set to widely recommended defaults (Manning et al., Lv and Zhai) and not tuned on the test split. They affect absolute scores but are unlikely to change the relative ordering of methods.
  • LSI latent dimensionality = 500 and 1000
    Two fixed dimensionalities chosen for exploration; the paper reports that lower dimensionality degrades performance. Not fitted to the test data.
  • Preprocessing configuration = lower-casing plus stemming, no sub-token splitting
    Selected using the validation split after comparing options. The main analysis uses the variant without sub-token splitting, while the replication package contains the other variant.
assumptions (4)
  • domain assumption Files changed in a commit whose message references an issue are the ground-truth files for resolving that issue, and all issue references in a commit are equally relevant to all changed files.
    This is the linking assumption that generates labels; stated in Section 3.3.2 and its failure modes (tangled commits, revert commits) are acknowledged as threats in Section 5.2.
  • domain assumption The first commit linked to an issue contains the bulk of the file changes needed to resolve it, so evaluating the First Commit Only variant captures the problem.
    Section 3.1 defines the problem variants and justifies focusing on First Commit Only, citing Figure 1 as supporting evidence. If later commits routinely touch different files, the dataset labels undercount the true set.
  • domain assumption Issue type labels from Jira can be manually consolidated into the four categories Bug, New Feature, Improvement, and Task without systematic error.
    Section 3.7.2 describes consolidation by the first author and a check by the third author, included in the replication package; misclassification would blur the RQ2 comparisons.
  • domain assumption Only files matching source-code extensions are relevant targets for localisation; documentation, configuration, and build files are excluded.
    Section 3.3.3 filters by extension when generating positive and negative samples, so issues whose only changes touch non-code files are discarded.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Gotta catch 'em all! Towards File Localisation from Issues at Large." pith.science (2026). https://pith.science/paper/3L3BCSTA

@misc{pith2026250718319,
  author       = {Pith},
  title        = {Pith review of: Gotta catch 'em all! Towards File Localisation from Issues at Large},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3L3BCSTA}},
  note         = {Machine review of arXiv:2507.18319}
}
read the original abstract

Bug localisation, the study of developing methods to localise the files requiring changes to resolve bugs, has been researched for a long time to develop methods capable of saving developers' time. Recently, researchers are starting to consider issues outside of bugs. Nevertheless, most existing research into file localisation from issues focusses on bugs or uses other selection methods to ensure only certain types of issues are considered as part of the focus of the work. Our goal is to work on all issues at large, without any specific selection. In this work, we provide a data pipeline for the creation of issue file localisation datasets, capable of dealing with arbitrary branching and merging practices. We provide a baseline performance evaluation for the file localisation problem using traditional information retrieval approaches. Finally, we use statistical analysis to investigate the influence of biases known in the bug localisation community on our dataset. Our results show that methods designed using bug-specific heuristics perform poorly on general issue types, indicating a need for research into general purpose models. Furthermore, we find that there are small, but statistically significant differences in performance between different issue types. Finally, we find that the presence of identifiers have a small effect on performance for most issue types. Many results are project-dependent, encouraging the development of methods which can be tuned to project-specific characteristics.

Figures

Figures reproduced from arXiv: 2507.18319 by the authors.

Figure 1
Figure 1. Proportion of the number of changes (as measured [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Examples of configurations of linked commits that adhere to or violate the path requirement. Linked commits are [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Example of how the merge commit a priori file resolution algorithm works. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Average performance per issue type of BM25 over [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 5
Figure 5. Figure 5: Average performance per held-out issue type of [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]
Figure 6
Figure 6. Figure 6: Spearman correlation per issue type (B – Bugs / F – New Feature / I – Improvement / Task – Task) between the different [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

53 extracted references · 16 canonical work pages

  1. [1]

    Abdelrahman Abdallah, Jamshid Mozafari, Bhawna Piryani, Mohammed Ali, and Adam Jatowt. 2025. From Retrieval to Generation: Comparing Different Approaches. doi:10.48550/arXiv.2502.20245 arXiv:2502.20245 [cs] version: 1

    work page Pith review arXiv doi:10.48550/arxiv.2502.20245 2025

  2. [2]

    Reem Aleithan, Haoran Xue, Mohammad Mahdi Mohajer, Elijah Nnorom, Gias Uddin, and Song Wang. 2024. SWE-Bench+: Enhanced Coding Benchmark for LLMs. doi:10.48550/arXiv.2410.06992 arXiv:2410.06992 [cs]

    arXiv doi:10.48550/arxiv.2410.06992 2024

  3. [3]

    Anonymous. 2025. Replication package for this study, containing both data and code. https://figshare.com/s/3ae7ea5147ad01780e4e Anonymised for peer review

    work page 2025

  4. [4]

    Egor Bogomolov, Aleksandra Eliseeva, Timur Galimzyanov, Evgeniy Glukhov, Anton Shapkin, Maria Tigina, Yaroslav Golubev, Alexander Kovrigin, Arie van Deursen, Maliheh Izadi, and Timofey Bryksin. 2024. Long Code Arena: a Set of Benchmarks for Long-Context Code Models. doi:10.48550/arXiv.2406.11612 arXiv:2406.11612 [cs]

    arXiv doi:10.48550/arxiv.2406.11612 2024

  5. [5]

    Soremekun, Sudipta Chattopadhyay, Emamurho Ugherughe, and Andreas Zeller

    Marcel Böhme, Ezekiel O. Soremekun, Sudipta Chattopadhyay, Emamurho Ugherughe, and Andreas Zeller. 2017. Where is the bug and how is it fixed? an experiment with practitioners. In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2017) . Association for Computing Machinery, New York, NY, USA, 117–128. doi:10.1145/...

    arXiv 2017

  6. [6]

    Canfora and L

    G. Canfora and L. Cerulo. 2005. Impact analysis by mining software and change request repositories. In 11th IEEE International Software Metrics Symposium (METRICS’05). 9 pp.–29. doi:10.1109/METRICS.2005.28 ISSN: 1530-1435

    doi:10.1109/metrics.2005.28 2005

  7. [7]

    Gerardo Canfora and Luigi Cerulo. 2006. Fine grained indexing of software repositories to support impact analysis. In Proceedings of the 2006 international workshop on Mining software repositories (MSR ’06) . Association for Computing Machinery, New York, NY, USA, 105–111. doi:10.1145/1137983.1138009

    arXiv 2006

  8. [8]

    Partha Chakraborty, Mahmoud Alfadel, and Meiyappan Nagappan. 2025. BLAZE: Cross-Language and Cross-Project Bug Localization via Dynamic Chunking and Hard Example Learning. IEEE Transactions on Software Engineering (2025), 1–14. doi:10.1109/TSE.2025.3579574

    work page arXiv 2025

Show all 53 references
  1. [9]

    Zhaoling Chen, Xiangru Tang, Gangda Deng, Fang Wu, Jialong Wu, Zhiwei Jiang, Viktor Prasanna, Arman Cohan, and Xingyao Wang. 2025. LocAgent: Graph-Guided LLM Agents for Code Localization. doi:10.48550/arXiv.2503.09089 arXiv:2503.09089 [cs]

    2025 doi arXiv

  2. [10]

    Agnieszka Ciborowska and Kostadin Damevski. 2022. Fast changeset-based bug localization with BERT. In Proceedings of the 44th International Conference on Software Engineering (ICSE ’22) . Association for Computing Machinery, New York, NY, USA, 946–957. doi:10.1145/3510003.3510042

    2022

  3. [11]

    Bogdan Dit, Latifa Guerrouj, Denys Poshyvanyk, and Giuliano Antoniol. 2011. Can Better Identifier Splitting Techniques Help Feature Location?. In 2011 IEEE 19th International Conference on Program Comprehension . 11–20. doi:10.1109/ ICPC.2011.47 ISSN: 1092-8138

    2011

  4. [12]

    Yali Du and Zhongxing Yu. 2023. Pre-training Code Representation with Semantic Flow Graph for Effective Bug Localization. In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2023) . As...

    2023

  5. [13]

    Mengdan Fan, Wei Zhang, Haiyan Zhao, Guangtai Liang, and Zhi Jin. 2024. Detect Hidden Dependency to Untangle Commits. In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering (Sacramento, CA, USA) (ASE ’24). Association for Computing Machi...

    2024

  6. [14]

    Cortés, and Lucas Monteiro

    Eliakim Gama, Matheus Paixao, Mariela I. Cortés, and Lucas Monteiro. 2024. Towards Realistic SATD Identification through Machine Learning Models: On- going Research and Preliminary Results. In Companion Proceedings of the 32nd ACM International Conference on the Foundations of...

    2024

  7. [15]

    Kim Herzig, Sascha Just, and Andreas Zeller. 2016. The impact of tangled code changes on defect prediction models. Empirical Software Engineering 21, 2 (01 Apr 2016), 303–336. doi:10.1007/s10664-015-9376-6

    2016 doi

  8. [16]

    Thomas Hirsch and Birgit Hofer. 2025. Best practices for evaluating IRFL ap- proaches. Journal of Systems and Software 222 (April 2025), 112342. doi:10.1016/ j.jss.2025.112342

    2025

  9. [17]

    Xuan Huo, Ferdian Thung, Ming Li, David Lo, and Shu-Ting Shi. 2021. Deep Transfer Bug Localization. IEEE Transactions on Software Engineering 47, 7 (July 2021), 1368–1380. doi:10.1109/TSE.2019.2920771 Conference Name: IEEE Transactions on Software Engineering

    2021

  10. [18]

    Maliheh Izadi, Pooya Rostami Mazrae, Tom Mens, and Arie van Deursen. 2023. An Empirical Study on Data Leakage and Generalizability of Link Prediction Models for Issues and Commits. doi:10.48550/arXiv.2211.00381 arXiv:2211.00381 [cs]

    2023 doi arXiv

  11. [19]

    Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan

    Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2024. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? doi:10.48550/arXiv.2310.06770 arXiv:2310.06770 [cs]

    2024 doi arXiv

  12. [20]

    René Just, Darioush Jalali, and Michael D. Ernst. 2014. Defects4J: a database of existing faults to enable controlled testing studies for Java programs. In Proceedings of the 2014 International Symposium on Software Testing and Analysis (ISSTA 2014). Association for Computing ...

    2014

  13. [21]

    Misoo Kim and Eunseok Lee. 2021. Are datasets for information retrieval- based bug localization techniques trustworthy? Empirical Software Engineering 26, 3 (May 2021), 1–66. doi:10.1007/s10664-021-09946-8 Company: Springer Distributor: Springer Institution: Springer Label: Sp...

    2021 doi

  14. [22]

    Ko, Brad A

    Amy J. Ko, Brad A. Myers, Michael J. Coblenz, and Htet Htet Aung. 2006. An Exploratory Study of How Developers Seek, Relate, and Collect Relevant In- formation during Software Maintenance Tasks. IEEE Transactions on Software Engineering 32, 12 (Dec. 2006), 971–987. doi:10.1109...

    2006 doi

  15. [23]

    Pavneet Singh Kochhar, Yuan Tian, and David Lo. 2014. Potential biases in bug localization: do they matter?. In Proceedings of the 29th ACM/IEEE International Conference on Automated Software Engineering (ASE ’14) . Association for Com- puting Machinery, New York, NY, USA, 803...

    2014

  16. [24]

    An Ngoc Lam, Anh Tuan Nguyen, Hoan Anh Nguyen, and Tien N. Nguyen. 2015. Combining Deep Learning with Information Retrieval to Localize Buggy Files for Bug Reports (N). In 2015 30th IEEE/ACM International Conference on Automated Software Engineering (ASE). 476–481. doi:10.1109...

    2015 doi

  17. [25]

    Yi Li, Shaohua Wang, and Tien N. Nguyen. 2022. UTANGO: untangling commits with context-aware, graph-based, code change clustering learning model. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineer...

    2022

  18. [26]

    Yuanhua Lv and ChengXiang Zhai. 2011. Lower-bounding term frequency nor- malization. In Proceedings of the 20th ACM international conference on Information and knowledge management (CIKM ’11) . Association for Computing Machinery, New York, NY, USA, 7–16. doi:10.1145/2063576.2063584

    2011

  19. [27]

    Jesse Maarleveld, Arjan Dekker, Sarah Druyts, and Mohamed Soliman. 2024. Maestro: A Deep Learning Based Tool to Find and Explore Architectural Design Decisions in Issue Tracking Systems. In Software Architecture. ECSA 2023 Tracks, Workshops, and Doctoral Symposium, Bedir Tekin...

    2024 doi

  20. [28]

    Manning, P

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

    2008

  21. [29]

    Lloyd Montgomery, Clara Lüders, and Walid Maalej. 2022. An alternative issue tracking dataset of public Jira repositories. InProceedings of the 19th International Conference on Mining Software Repositories (MSR ’22) . Association for Computing Machinery, New York, NY, USA, 73–...

    2022

  22. [30]

    Eashaan Rao, and Sridhar Chimalakonda

    Sandeep Muvva, A. Eashaan Rao, and Sridhar Chimalakonda. 2020. BuGL – A Cross-Language Dataset for Bug Localization. doi:10.48550/arXiv.2004.08846 arXiv:2004.08846 [cs]

    2020 doi arXiv

  23. [31]

    Fabio Palomba, Pasquale Salza, Adelina Ciurumelea, Sebastiano Panichella, Har- ald Gall, Filomena Ferrucci, and Andrea De Lucia. 2017. Recommending and Localizing Change Requests for Mobile Apps Based on User Reviews. In 2017 IEEE/ACM 39th International Conference on Software ...

    2017 doi

  24. [32]

    Profir-Petru Pârundefinedachi, Santanu Kumar Dash, Miltiadis Allamanis, and Earl T. Barr. 2020. Flexeme: untangling commits using lexical flows. InProceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software...

    2020

  25. [33]

    Yihao Qin, Shangwen Wang, Yiling Lou, Jinhao Dong, Kaixin Wang, Xiaoling Li, and Xiaoguang Mao. 2025. AgentFL: Scaling LLM-based Fault Localization to Project-Level Context. doi:10.48550/arXiv.2403.16362 arXiv:2403.16362 [cs]

    2025 doi arXiv

  26. [34]

    Revanth Gangi Reddy, Tarun Suresh, JaeHyeok Doo, Ye Liu, Xuan Phi Nguyen, Yingbo Zhou, Semih Yavuz, Caiming Xiong, Heng Ji, and Shafiq Joty. 2025. SweRank: Software Issue Localization with Code Ranking. doi:10.48550/arXiv. 2505.07849 arXiv:2505.07849 [cs]. Maarleveld et al

    2025 doi arXiv

  27. [35]

    Stephen Robertson, Hugo Zaragoza, and Michael Taylor. 2004. Simple BM25 extension to multiple weighted fields. In Proceedings of the thirteenth ACM in- ternational conference on Information and knowledge management (CIKM ’04) . Association for Computing Machinery, New York, NY...

    2004

  28. [36]

    Stephen E Robertson, Steve Walker, Susan Jones, Micheline M Hancock-Beaulieu, Mike Gatford, et al. 1995. Okapi at TREC-3. Nist Special Publication Sp 109 (1995), 109

    1995

  29. [37]

    O’Connor

    Sharon Ryan and Rory V. O’Connor. 2013. Acquiring and sharing tacit knowledge in software development teams: An empirical study. Information and Software Technology 55, 9 (Sept. 2013), 1614–1624. doi:10.1016/j.infsof.2013.02.013

    2013 doi

  30. [38]

    Saha, Yingjun Lyu, Wing Lam, Hiroaki Yoshida, and Mukul R

    Ripon K. Saha, Yingjun Lyu, Wing Lam, Hiroaki Yoshida, and Mukul R. Prasad

  31. [39]

    Karthik Shivashankar, Mili Orucevic, Maren Maritsdatter Kruke, and Antonio Martini. 2025. BEACon-TD: Classifying Technical Debt and its types across diverse software projects issues using transformers. Journal of Systems and Software 226 (Aug. 2025), 112435. doi:10.1016/j.jss....

    2025

  32. [40]

    Ratnadira Widyasari, Stefanus Agus Haryono, Ferdian Thung, Jieke Shi, Con- stance Tan, Fiona Wee, Jack Phan, and David Lo. 2022. On the Influence of Biases in Bug Localization: Evaluation and Benchmark. In2022 IEEE International Conference on Software Analysis, Evolution and R...

    2022

  33. [41]

    Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. 2025. Demystifying LLM-Based Software Engineering Agents. Proc. ACM Softw. Eng. 2, FSE (June 2025), FSE037:801–FSE037:824. doi:10.1145/3715754

    2025 doi

  34. [42]

    Hassan, and Shan- ping Li

    Xin Xia, Lingfeng Bao, David Lo, Zhenchang Xing, Ahmed E. Hassan, and Shan- ping Li. 2018. Measuring Program Comprehension: A Large-Scale Field Study with Professionals. IEEE Transactions on Software Engineering 44, 10 (Oct. 2018), 951–976. doi:10.1109/TSE.2017.2734091

    2018

  35. [43]

    Yan Xiao, Jacky Keung, Qing Mi, and Kwabena E. Bennin. 2017. Improving Bug Localization with an Enhanced Convolutional Neural Network. In 2017 24th Asia-Pacific Software Engineering Conference (APSEC) . 338–347. doi:10.1109/ APSEC.2017.40

    2017

  36. [44]

    Jimenez, Alex L

    John Yang, Carlos E. Jimenez, Alex L. Zhang, Kilian Lieret, Joyce Yang, Xindi Wu, Ori Press, Niklas Muennighoff, Gabriel Synnaeve, Karthik R. Narasimhan, Diyi Yang, Sida I. Wang, and Ofir Press. 2024. SWE-bench Multimodal: Do AI Systems Generalize to Visual Software Domains? d...

    2024 doi arXiv

  37. [45]

    Shouliang Yang, Junming Cao, Hushuang Zeng, Beijun Shen, and Hao Zhong

  38. [46]

    Xin Ye, Razvan Bunescu, and Chang Liu. 2014. Learning to rank relevant files for bug reports using domain knowledge. In Proceedings of the 22nd ACM SIG- SOFT International Symposium on Foundations of Software Engineering (FSE 2014). Association for Computing Machinery, New Yor...

    2014

  39. [47]

    Daoguang Zan, Zhirong Huang, Wei Liu, Hanwu Chen, Linhao Zhang, Shulin Xin, Lu Chen, Qi Liu, Xiaojian Zhong, Aoyan Li, Siyao Liu, Yongsheng Xiao, Liangqiang Chen, Yuyu Zhang, Jing Su, Tianyu Liu, Rui Long, Kai Shen, and Liang Xiang. 2025. Multi-SWE-bench: A Multilingual Benchm...

    2025 doi arXiv

  40. [48]

    Tao Zhang, Jiachi Chen, Xian Zhan, Xiapu Luo, David Lo, and He Jiang. 2021. Where2Change: Change Request Localization for App Reviews.IEEE Transactions on Software Engineering 47, 11 (Nov. 2021), 2590–2616. doi:10.1109/TSE.2019. 2956941 Conference Name: IEEE Transactions on So...

    2021 doi

  41. [49]

    Jian Zhou, Hongyu Zhang, and David Lo. 2012. Where should the bugs be fixed? More accurate information retrieval-based bug localization based on bug reports. In 2012 34th International Conference on Software Engineering (ICSE) . 14–24. doi:10.1109/ICSE.2012.6227210 ISSN: 1558-1225

    2012

  42. [50]

    Zhenhao Zhou, Zhuochen Huang, Yike He, Chong Wang, Jiajun Wang, Yijian Wu, Xin Peng, and Yiling Lou. 2025. Benchmarking and Enhancing LLM Agents in Localizing Linux Kernel Bugs. doi:10.48550/arXiv.2505.19489 arXiv:2505.19489 [cs]

    2025 doi arXiv

  43. [440]

    doi:10.1145/2610384.2628055

  44. [2018]

    In Pro- ceedings of the 15th International Conference on Mining Software Repositories (MSR ’18)

    Bugs.jar: a large-scale, diverse dataset of real-world Java bugs. In Pro- ceedings of the 15th International Conference on Mining Software Repositories (MSR ’18). Association for Computing Machinery, New York, NY, USA, 10–13. doi:10.1145/3196398.3196473

  45. [2021]

    In 2021 IEEE/ACM 29th International Conference on Program Comprehension (ICPC)

    Locating Faulty Methods with a Mixed RNN and Attention Model. In 2021 IEEE/ACM 29th International Conference on Program Comprehension (ICPC) . 207–218. doi:10.1109/ICPC52881.2021.00028 ISSN: 2643-7171

    2021

Pith tools

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