Pith. sign in

REVIEW 3 major objections 4 minor 48 references

BugsRepo: A Comprehensive Curated Dataset of Bug Reports, Comments and Contributors Information from Bugzilla

T0 review · 3 major / 4 minor · reviewed 2026-08-16 · deepseek-v4-flash

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

Pith's one-line read BugsRepo presents a curated Mozilla Bugzilla resource that pairs 119,585 bug records and comments with contributor profiles, and offers a 10,351-report quality-filtered subset.

desk verdict BugsRepo's raw integrated dataset is a real, useful resource, but the 'higher-quality structured subset' claim is not yet supported and needs validation before it is cited for that purpose. read the letter →

arxiv 2504.18806 v1 pith:CXJNAY2S submitted 2025-04-26 cs.SE

Jagrit Acharya , Gouri Ginde This is my paper · ORCID
classification cs.SE
keywords Bug-FixDatasetMiningSoftwareRepositoriesMaintenanceBugreportqualityBugzillaCTQRSContributorinformationtriage
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

BugsRepo is a dataset paper that claims a single curated resource can give a "holistic view" of Mozilla bug history by joining three kinds of Bugzilla data: metadata and comment threads for 119,585 resolved bugs, account profiles for 19,351 contributors, and a 10,351-report subset that passes a two-stage quality filter. The authors argue that existing bug datasets focus on metadata or comment text separately, so they miss the connection between a bug's characteristics, its discussion, and the expertise of the people involved. If the curation works, software maintenance tasks such as bug triage, summarization, and severity prediction get both cleaner training data and a new contributor-information dimension.

What carries the argument

The load-bearing machinery is CTQRS (Crowdsourced Test Report Quality Score), a dependency-parsing-based scoring framework that rates a report on morphological, relational, and analytical indicators to a maximum of 17 points. Applied with a 75 percent threshold after the regular-expression section check, it is what converts the raw Bugzilla dump into the curated subset. The framework supplies the objective-looking quality gate that the paper's "higher-quality corpus" claim depends on.

What would settle it

Draw a random sample of 100 reports from the 10,351-report subset, have independent annotators judge whether each report truly contains clear steps to reproduce, actual behavior, and expected behavior, and compare those judgments against the CTQRS scores and the regex pass. A weak match would show the filter is not measuring what the paper says it measures.

Watch

Extended reading notes

Core claim

The paper's central claim is that the 10,351-report subset "can be regarded as a higher-quality corpus compared to typical Bugzilla data." The claim rests on a filter that first uses regular expressions to keep reports containing Steps to Reproduce, Actual Behavior, and Expected Behavior sections, then applies the CTQRS quality score with a 75 percent threshold, reducing an initial 119,585 reports to 12,614 and finally to 10,351. The companion datasets—bug metadata with comment threads and 19,351 contributor profiles with activity metrics such as bugs filed, comments made, and patches reviewed—are presented as enabling tasks the structured subset alone cannot support, such as developer recommendation and workload-aware triage.

Load-bearing premise

The claim collapses if the regular expressions that detect section labels, combined with a CTQRS score above 75 percent borrowed from crowdsourced mobile test reports, do not actually identify well-structured Mozilla bug reports.

Editorial extensions

If this is right

  • Models for bug triage and severity prediction can be trained on the 10,351 structured reports, reducing the noise that incomplete descriptions introduce.
  • Contributor activity metrics allow developer recommendation by matching a bug to members whose past bugs, comments, and reviewed patches fit the task.
  • Comment threads combined with structured S2R/ER/AR sections give summarization systems both discussion context and a reproducibility skeleton.
  • Coverage of more than 50 Mozilla projects lets triage policies be evaluated for cross-project generalization.

Reading between the lines

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

  • Beyond the paper: the CTQRS threshold was designed for crowdsourced mobile test reports, so a direct validation against human ratings of Mozilla reports would test whether the transferred threshold marks quality or merely template adherence.
  • Beyond the paper: the regex step likely over-selects reports whose authors followed the Bugzilla template closely; the subset may be skewed by project, reporter, or report age, so users should check representativeness before training.
  • Beyond the paper: the contributor data admits a testable prediction—if the holistic view is valuable, bugs filed by high-activity contributors should show measurably different severity assignment and resolution patterns than those from one-time reporters.
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 / 4 minor

Summary. BugsRepo is a data paper that introduces a Mozilla Bugzilla dataset in three parts: a metadata/comment collection for 119,585 resolved bugs, a contributor profile collection for 19,351 users, and a filtered subset of 10,351 reports claimed to be well-structured. The mining pipeline uses the Bugzilla REST API and BeautifulSoup, and the filtering pipeline first applies regular expressions for Steps-to-Reproduce, Actual Behavior, and Expected Behavior sections and then applies the CTQRS quality score with a 75% threshold. The paper reports dataset sizes, gives a schema overview, lists applications such as triage and summarization, and provides Zenodo and GitHub links.

Significance. The raw resource is a plausible and potentially valuable contribution: the combination of metadata, comment threads, and contributor activity in one downloadable archive is not common among the existing Bugzilla datasets listed in Table 1, and the publication of both the data and the mining code supports reproducibility. If the dataset is as large and as complete as described, it can support work on triage, severity prediction, summarization, and developer recommendation. However, the paper's flagship claim that the 10,351-report subset is a 'higher-quality corpus' is not yet supported by the evidence presented, and the central filtering step needs validation before this claim can be accepted.

major comments (3)
  1. [Section 4 (CTQRS paragraph) and Section 2] The central claim that the 10,351-report subset is a higher-quality corpus (Section 2, final paragraph) depends on the CTQRS filtering step in Section 4, but this step is not validated for Mozilla Bugzilla reports. The CTQRS framework was developed for crowdsourced mobile test reports, and the paper provides no evidence that its indicators or the 75% threshold transfer to long, log-heavy Mozilla reports. In particular, the paper does not report the CTQRS score distribution on the 12,614 regex-passing reports, does not report manual inspection of a sample, and does not compare the filtered subset with an independent quality label. Without this evidence, the 10,351-report subset may simply be a set of long reports that satisfy the score's length-related components, not necessarily well-structured reports. I ask the authors to add a validation section with a score distribution, a manual precision check (ideally with inter-rater agreement), and a justification or recalibration of the 75% threshold on Mozilla data.
  2. [Section 4 (regular-expression filtering, Figure 4)] The regular expressions used to detect S2R, AR/AB, and ER are not specified, and the paper's own counterexample suggests that naive section-label detection is insufficient. Figure 4, labeled as a low-quality/unstructured report, contains the literal heading 'Steps to reproduce:' followed by a long narrative description; a regex that merely checks for the presence of that label would admit this report. The paper reports that 119,585 reports reduce to 12,614 after regex filtering, but without the actual patterns, the set of reports that pass is not precisely defined. Please make the regular expressions available in the text or appendix and report a precision estimate for the regex step on a manually labeled sample.
  3. [Section 6 (Limitations)] The limitations section discusses scraping challenges and data inclusion criteria (enhancement excluded, resolved only) but does not acknowledge or discuss the absence of validation for the 'well-structured' subset. Since the paper's third contribution is exactly this subset, the limitation is load-bearing rather than peripheral. The authors should either provide the validation evidence in Section 4 or explicitly state in Section 6 that the structured subset has not yet been manually validated and should be treated as a large candidate set of structured reports.
minor comments (4)
  1. [Section 3, text before Table 1] The sentence '... often focus primarily on bug metadata or comment text [21? ]' contains a malformed citation marker '[21? ]' that should be corrected to a proper reference.
  2. [Sections 1, 2, and 4] The paper uses both 'AR' and 'AB' for actual behavior; for example, Section 2 uses 'AR' while Section 1 and Figure 3 use 'AB'. Choose one abbreviation and use it consistently.
  3. [Section 4 (Figure 2)] The text says 'using a regular expression as shown in ➌ of Figure 2', but the regular expression itself is not shown in the figure or elsewhere; include the actual patterns in the text, appendix, or repository.
  4. [References [29], [30], and [31]] References [29], [30], and [31] all point to the same Mozilla Bug Writing Guidelines page; consolidate them into a single reference.

Circularity Check

1 steps flagged · score 2.0 of 10

Mild operational circularity: the paper defines the 10,351-report subset by the CTQRS and regex filter, then labels that same subset 'higher-quality'; no fitted parameter, self-citation chain, or derived prediction is involved.

  1. self definitional [Section 2 'Novelty of BugsRepo' and Section 4 'Data Collection' (CTQRS filtering paragraph)]
    "We apply dual filtering of bug reports to retain only those containing well-written S2R, AR, and ER sections, thereby removing the reports that lack the important information needed for the various bug report management tasks... As a result, the curated subset of 10,351 reports can be regarded as a higher-quality corpus compared to typical Bugzilla data. ... we applied filtering based on the CTQRS score [42], as demonstrated in ➍ of Figure 2, reducing the dataset to 10,351 reports."

    The subset's defining property—passing the regex detection of S2R/AR/ER and scoring at least 75% on CTQRS—is the same criterion used to assert that the subset is 'higher-quality'. The conclusion restates the selection rule in evaluative language rather than validating the subset against an independent benchmark of report quality. The 75% threshold is imported from the external CTQRS paper by Zhang et al. and is not fitted to these Mozilla reports, so there is no fitted parameter being relabeled as a prediction; the circularity is limited to the evaluative claim being co-extensive with the filter's definition.

full rationale

The paper is a dataset description rather than a derivation-based study. Its central artifacts are the metadata, comment, contributor, and structured-report datasets. The only loaded claim is that the 10,351-report subset is a 'higher-quality corpus compared to typical Bugzilla data'. That claim is operationally defined by the filtering pipeline itself: reports that contain regex-detected Steps-to-Reproduce, Actual Behavior, and Expected Behavior sections and score above the CTQRS 75% threshold are labeled 'well-structured' and 'high-quality'. This is a mild self-definitional labeling: the quality predicate is co-extensive with the filter's inclusion rule. However, this is not a fitted-input-called-prediction situation, because the CTQRS threshold comes from an external source (Zhang et al., DSA 2022) and is not optimized on the present data. There are no self-citations that carry the argument, no uniqueness theorem imported from the authors' own prior work, and no ansatz smuggled in through self-citation. The dataset's raw metadata and comments are independently useful regardless of the quality subset. The paper does not claim to predict external outcomes from fitted parameters, so no statistical circularity arises. The main risk—that the CTQRS instrument may not transfer cleanly to Mozilla Bugzilla reports—is a validity threat, not a circularity, and the paper acknowledges general limitations about data collection without addressing this transfer explicitly. Overall, the derivation chain is self-contained; the only circular element is the evaluative label attached to the filter output, which warrants a score of 2.

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

The central claim is a data artifact, not a derivation. The two filters (regex and CTQRS threshold) are the main hand-chosen controls and directly determine the size and contents of the "high-quality" subset. All other assumptions are standard data-source reliability assumptions.

free parameters (2)
  • CTQRS quality threshold = 75% of maximum CTQRS score (12.75 out of 17)
    Adopted from the original CTQRS paper by Zhang et al. [42] without re-calibration for Mozilla bug reports; it determines the final 10,351-report subset.
  • Section-label regular expressions = Hand-crafted patterns for 'Steps to Reproduce', 'Actual Behavior', 'Expected Behavior'
    Used in Section 4 to reduce 119,585 reports to 12,614; the patterns are not specified in the paper, so their precision cannot be assessed.
assumptions (4)
  • domain assumption Presence of the S2R, AB, and EB section labels in a report is a valid indicator that the report is well-structured and follows Bugzilla guidelines.
    Section 4 uses regex detection of these labels as the first filtering layer; the paper's own Figure 4 counterexample undermines this.
  • domain assumption CTQRS, a quality metric for crowdsourced mobile test reports, transfers to Mozilla Bugzilla bug reports with the same 75% threshold and without validation.
    Section 4: "We implemented the CTQRS framework... to assess bug report quality" and adopted the 75% benchmark from Zhang et al.
  • domain assumption Contributor profile scraping via BeautifulSoup produces accurate counts of bugs filed, comments made, patches reviewed, and other metrics.
    Section 4 describes multi-iteration scraping but reports no checks against Bugzilla data or ground truth.
  • domain assumption Bugzilla REST API responses correctly capture status, resolution, severity, and comment history for the selected period.
    The whole dataset is built on this API (Section 4); no consistency checks are reported.

how reviews work

0 comments
Cite this review

Pith. "Pith review of BugsRepo: A Comprehensive Curated Dataset of Bug Reports, Comments and Contributors Information from Bugzilla." pith.science (2026). https://pith.science/paper/CXJNAY2S

@misc{pith2026250418806,
  author       = {Pith},
  title        = {Pith review of: BugsRepo: A Comprehensive Curated Dataset of Bug Reports, Comments and Contributors Information from Bugzilla},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CXJNAY2S}},
  note         = {Machine review of arXiv:2504.18806}
}
read the original abstract

Bug reports help software development teams enhance software quality, yet their utility is often compromised by unclear or incomplete information. This issue not only hinders developers' ability to quickly understand and resolve bugs but also poses significant challenges for various software maintenance prediction systems, such as bug triaging, severity prediction, and bug report summarization. To address this issue, we introduce \textnormal{{\fontfamily{ppl}\selectfont BugsRepo}}, a multifaceted dataset derived from Mozilla projects that offers three key components to support a wide range of software maintenance tasks. First, it includes a Bug report meta-data & Comments dataset with detailed records for 119,585 fixed or closed and resolved bug reports, capturing fields like severity, creation time, status, and resolution to provide rich contextual insights. Second, {\fontfamily{ppl}\selectfont BugsRepo} features a contributor information dataset comprising 19,351 Mozilla community members, enriched with metadata on user roles, activity history, and contribution metrics such as the number of bugs filed, comments made, and patches reviewed, thus offering valuable information for tasks like developer recommendation. Lastly, the dataset provides a structured bug report subset of 10,351 well-structured bug reports, complete with steps to reproduce, actual behavior, and expected behavior. After this initial filter, a secondary filtering layer is applied using the CTQRS scale. By integrating static metadata, contributor statistics, and detailed comment threads, {\fontfamily{ppl}\selectfont BugsRepo} presents a holistic view of each bug's history, supporting advancements in automated bug report analysis, which can enhance the efficiency and effectiveness of software maintenance processes.

Figures

Figures reproduced from arXiv: 2504.18806 by the authors.

Figure 2
Figure 2. Overview of the methodology used to develop vari [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 4
Figure 4. This is an example of a low-quality bug report, as it [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 5
Figure 5. Bug reports vs. projects distribution, showing Core [PITH_FULL_IMAGE:figures/full_fig_p005_5.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

48 extracted references · 38 canonical work pages

  1. [1]

    Beautiful Soup Documentation; Beautiful Soup 4.12.0 documentation

    2024. Beautiful Soup Documentation; Beautiful Soup 4.12.0 documentation. Avail- able at https://www.crummy.com/software/BeautifulSoup/bs4/doc/. [Accessed 19-Nov-2024]

    work page 2024

  2. [2]

    Bugzilla

    2024. Bugzilla. https://www.bugzilla.org. Accessed: 2024-11-17

    work page 2024

  3. [3]

    How to write a good bug report — github.com

    2024. How to write a good bug report — github.com. https://github.com/OpenSC/ OpenSC/wiki/How-to-write-a-good-bug-report. [Accessed 10-11-2024]

    work page 2024

  4. [4]

    R: The R Project for Statistical Computing — r-project.org

    2024. R: The R Project for Statistical Computing — r-project.org. https://www.r- project.org/. [Accessed 23-11-2024]

    work page 2024

  5. [5]

    Hira Anis Ahmed et al. 2021. CapBug—A Framework for Automatic Bug Catego- rization and Prioritization Using NLP and Machine Learning Algorithms. IEEE Access 9 (2021), 50496–50512

    work page 2021

  6. [6]

    S Ahsan et al. 2010. Mining effort data from the oss repository of developer’s bug fix activity. Journal of Information Technology in Asia 3 (2010), 67–80

    work page 2010

  7. [7]

    John Anvik et al . 2006. Who should fix this bug?. In Proc. of the 28th Inter. Conference on Software Engineering (Shanghai, China) (ICSE ’06). Association for Computing Machinery, New York, NY, USA, 361–370. doi:10.1145/1134285. 1134336

    doi:10.1145/1134285 2006

  8. [8]

    Pasquale Ardimento and Andrea Dinapoli. 2017. Knowledge extraction from on- line open source bug tracking systems to predict bug-fixing time. In Proceedings of the 7th international conference on web intelligence, mining and semantics . 1–9

    work page 2017

Show all 48 references
  1. [9]

    Hani Bani-Salameh et al. 2021. A Deep-Learning-Based Bug Priority Prediction Using RNN-LSTM Neural Networks. e-Informatica Software Engineering Journal 15, 1 (2021), 66

    2021

  2. [10]

    Xin Chen, He Jiang, Xiaochen Li, Tieke He, and Zhenyu Chen. 2018. Auto- mated quality assessment for crowdsourced test reports of mobile applications. In 2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 368–379

    2018

  3. [11]

    Jie Dai et al. 2023. Graph collaborative filtering-based bug triaging. Journal of Systems and Software 200 (2023), 111667. doi:10.1016/j.jss.2023.111667

    2023

  4. [12]

    Mona Erfani Joorabchi et al. 2014. Works for me! characterizing non-reproducible bug reports. In Proc. of the 11th working conference on mining software repositories . 62–71

    2014

  5. [13]

    Shikai Fang, , et al. 2021. Effective Prediction of Bug-Fixing Priority via Weighted Graph Convolutional Networks. IEEE Transactions on Reliability 70, 2 (2021), 563–574

    2021

  6. [14]

    Mattia Fazzini et al. 2018. Automatically translating bug reports into test cases for mobile apps. In Proc. of the 27th ACM SIGSOFT Inter. Symposium on Software Testing and Analysis. 141–152

    2018

  7. [15]

    Mayy Habayeb et al. 2015. The firefox temporal defect dataset. In 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories . IEEE, 498–501

    2015

  8. [16]

    Rui Hao, Yang Feng, James A Jones, Yuying Li, and Zhenyu Chen. 2019. CTRAS: Crowdsourced test report aggregation and summarization. In 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE) . IEEE, 900–911

    2019

  9. [17]

    Jianjun He, Ling Xu, Yuanrui Fan, Zhou Xu, Meng Yan, and Yan Lei. 2020. Deep learning based valid bug reports determination and explanation. In 2020 IEEE 31st International Symposium on Software Reliability Engineering (ISSRE) . IEEE, 184–194

    2020

  10. [18]

    Jingxuan He JIANG et al . 2017. Mining authorship characteristics in bug repositories. SCIENCE CHINA Information Sciences 60, 1 (2017), 012107–. "http://www.sciengine.com/publisher/ScienceChinaPress/journal/ SCIENCECHINAInformationSciences/60/1/10.1007/s11432-014-0372-y,

    2017 doi

  11. [19]

    Zhangyuan Huang, Zhiyi Shao, Guisheng Fan, Hao Yu, Yang Kng, and Zhi Zhou

  12. [20]

    Hadi Jahanshahi et al. 2021. DABT: A Dependency-aware Bug Triaging Method. In Proc. of the 25th Inter. Conference on Evaluation and Assessment in Software Engi- neering (Trondheim, Norway) (EASE ’21). Association for Computing Machinery, New York, NY, USA, 221–230. doi:10.1145...

    2021

  13. [21]

    Elia Kouzari et al . 2018. Process Mining for Process Conformance Checking in an OSS Project: An Empirical Research. In Open Source Systems: Enterprise Software and Solutions, Ioannis Stamelos, Jesus M. Gonzalez-Barahoña, Iraklis Varlamis, and Dimosthenis Anagnostopoulos (Eds....

    2018

  14. [22]

    Rajesh Kumar et al. 2020. A Comparative Analysis of Multiple Defect Tracking Systems. Fuzzy Systems and Soft Computing (2020)

    2020

  15. [23]

    Ahmed Lamkanfi et al. 2013. The Eclipse and Mozilla defect tracking dataset: A genuine dataset for mining bug information. In 2013 10th Working Conference on Mining Software Repositories (MSR) . 203–206. doi:10.1109/MSR.2013.6624028

    2013

  16. [24]

    Dong-Gun Lee et al. 2019. Systematic Review of Bug Report Processing Tech- niques to Improve Software Management Performance. Journal of Information Processing Systems 15, 4 (2019), 967–985. doi:10.3745/JIPS.04.0130

    2019 doi

  17. [25]

    Xiaochen Li et al. 2018. Unsupervised deep bug report summarization. In Proc. of the 26th Conference on Program Comprehension . 144–155

    2018

  18. [26]

    Haoran Liu et al . 2020. Bugsum: Deep context understanding for bug report summarization. In Proc. of the 28th Inter. Conference on Program Comprehension . 94–105

    2020

  19. [27]

    Senthil Mani et al . 2019. DeepTriage: Exploring the Effectiveness of Deep Learning for Bug Triaging. In Proc. of the ACM India Joint Inter. Conference on Data Science and Management of Data (Kolkata, India) (CODS-COMAD ’19). Association for Computing Machinery, New York, NY, ...

    2019

  20. [28]

    Kevin Moran. 2015. Enhancing Android application bug reporting. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (Bergamo, Italy) (ESEC/FSE 2015). Association for Computing Machinery, New York, NY, USA, 1045–1047. doi:10.1145/2786805.2807557

    2015

  21. [29]

    Mozilla. [n. d.]. Bug Writing Guidelines. https://bugzilla.mozilla.org/page.cgi? id=bug-writing.html. [Accessed 10-11-2024]

    2024

  22. [30]

    Mozilla. [n. d.]. Bug Writing Guidelines. Available at https://bugzilla.mozilla.org/ page.cgi?id=bug-writing.html. [Accessed 10-Oct-2024]

    2024

  23. [31]

    Mozilla. 2024. Bug Writing Guidelines. https://bugzilla.mozilla.org/page.cgi?id= bug-writing.html Accessed: 2024-11-10

    2024

  24. [32]

    Mozilla Wiki. 2024. Bugzilla: REST API. https://wiki.mozilla.org/Bugzilla:REST_ API. Accessed: 19-Nov-2024

    2024

  25. [33]

    Ehsan Paikari. 2023. Bug Report Quality Prediction and the Impact of Includ- ing Videos on the Bug Reporting Process . Ph.D. dissertation. University of California, Irvine. https://escholarship.org/uc/item/9tn4t5gs ProQuest ID: Paikari_uci_0030D_18226, Merritt ID: ark:/13030/m5bm23hd

    2023

  26. [34]

    Waheed Yousuf Ramay, Qasim Umer, Xu-Cheng Yin, Chao Zhu, and Inam Illahi

  27. [35]

    Gregorio Robles. 2010. Replicating MSR: A study of the potential replicability of papers published in the Mining Software Repositories Proc.. In 2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010) . 171–180. doi:10. 1109/MSR.2010.5463348

    2010

  28. [36]

    Mohammad Qasem Shatnawi et al. 2022. An assessment of eclipse bugs’ priority and severity prediction using machine learning. Inter. Journal of Communication Networks and Information Security 14, 1 (2022), 62–69

    2022

  29. [37]

    Dingbang Wang, Zhaoxu Zhang, Sidong Feng, William G. J. Halfond, and Tingting Yu. 2025. An Empirical Study on Leveraging Images in Automated Bug Report Reproduction. arXiv:2502.15099 [cs.SE] https://arxiv.org/abs/2502.15099

    2025 arXiv

  30. [38]

    Q. Q. Wang et al. 2015. Evaluating the usefulness of ir-based fault localization techniques. Proc. of the 2015 Inter. Symposium on Software Testing and Analysis (2015). doi:10.1145/2771783.2771797

    2015

  31. [39]

    Hongrun Wu, , et al. 2022. A spatial–temporal graph neural network framework for automated software bug triaging.Knowledge-Based Systems 241 (2022), 108308. doi:10.1016/j.knosys.2022.108308

    2022

  32. [40]

    Bangmeng Xiang et al. 2024. SUMLLAMA: Efficient Contrastive Representations and Fine-Tuned Adapters for Bug Report Summarization. IEEE Access (2024)

    2024

  33. [41]

    Syed Farhan Alam Zaidi et al. 2022. A Graph Convolution Network-Based Bug Triage System to Learn Heterogeneous Graph Representation of Bug Reports. IEEE Access 10 (2022), 20677–20689. doi:10.1109/ACCESS.2022.3153075

    2022

  34. [42]

    Huan Zhang, Yuan Zhao, Shengcheng Yu, and Zhenyu Chen. 2022. Automated Quality Assessment for Crowdsourced Test Reports Based on Dependency Pars- ing. In 2022 9th International Conference on Dependable Systems and Their Appli- cations (DSA). 34–41. doi:10.1109/DSA56465.2022.00014

    2022

  35. [43]

    Jie Zhang, XiaoYin Wang, Dan Hao, Bing Xie, Lu Zhang, and Hong Mei. 2015. A survey on bug-report analysis. Science China Information Sciences 58, 2 (2015), 1–24. doi:10.1007/s11432-014-5241-2

    2015 doi

  36. [44]

    Jiaxin Zhu et al . 2016. Multi-extract and Multi-level Dataset of Mozilla Issue Tracking History. In 2016 IEEE/ACM 13th Working Conference on Mining Software Repositories (MSR). 472–475

    2016

  37. [45]

    Thomas Zimmermann et al . 2010. What Makes a Good Bug Report? IEEE Transactions on Software Engineering 36 (09 2010), 618–643. doi:10.1109/TSE.2010. 63

    2010 doi

  38. [46]

    Thomas Zimmermann et al. 2012. Characterizing and predicting which bugs get reopened. In 2012 34th Inter. Conference on Software Engineering (ICSE) . IEEE, 1074–1083

    2012

  39. [2019]

    https://api.semanticscholar.org/CorpusID:131776833

    Deep Neural Network-Based Severity Prediction of Bug Reports.IEEE Access 7 (2019), 46846–46857. https://api.semanticscholar.org/CorpusID:131776833

    2019

  40. [2022]

    Bug report priority prediction using developer-oriented socio-technical features. In Proc. of the 13th Asia-Pacific Symposium on Internetware . 202–211

Pith tools

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