Pith. sign in

REVIEW 2 major objections 1 minor 38 references

G-Issue: Analyzing Lifetime and Evolution of Issue-related Artifacts from Open Source Repositories

T0 review · 2 major / 1 minor · reviewed 2026-06-26 · grok-4.3

Pith's one-line read G-Issue mines issue artifacts faster than standard Python APIs while using more memory and supports prioritization by issue lifetime.

desk verdict G-Issue is a new mining tool with performance numbers and lifetime observations, but the work provides no validation of extraction accuracy so the claims rest on unverified output. read the letter →

arxiv 2606.21837 v1 pith:VSWP62WX submitted 2026-06-20 cs.SE

classification cs.SE
keywords issueminingopensourcerepositoriessoftwareissueslifetimeevolutionqualityG-Issuetool
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 presents G-Issue, a tool designed to extract issue-related artifacts such as bugs, errors, and documentation gaps from open source repositories. It benchmarks G-Issue against general Python APIs, showing faster extraction speeds offset by higher memory consumption. The work further tracks how issues evolve and persist over time across well-known repositories, demonstrating that lifetime patterns can guide which issues receive priority attention. These capabilities are positioned to support more effective issue management, developer assignment, and overall software quality improvements.

What carries the argument

G-Issue tool, which performs mining of issue artifacts and tracks their lifetime and evolution patterns to support prioritization.

What would settle it

Direct head-to-head timing and memory measurements of G-Issue versus a standard Python API on identical large repositories, plus manual spot-checks of extracted artifacts against the original repository contents.

Watch

Extended reading notes

Core claim

G-Issue extracts issue-related artifacts more quickly than general Python APIs during mining tasks but requires more memory, and the resulting data on issue lifetime and evolution across maintained repositories enables prioritization of issues for better management and quality outcomes.

Load-bearing premise

The selected well-known and maintained repositories provide representative data and that G-Issue accurately extracts all relevant issue artifacts without systematic omissions or errors.

Editorial extensions

If this is right

  • Faster mining allows larger-scale analysis of issue data without proportional time increases.
  • Lifetime and evolution metrics can be used to rank issues for developer attention.
  • Improved prioritization supports more targeted developer assignment and quality management.
  • The approach offers a practical way to monitor software health through issue behavior over time.

Reading between the lines

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

  • Similar lifetime tracking could be applied to other project artifacts such as pull requests or commits.
  • The memory trade-off might be mitigated by selective data loading in future versions of the tool.
  • Patterns identified in well-known repositories could serve as baselines for comparing newer or less-maintained projects.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

2 major / 1 minor

Summary. The paper introduces G-Issue, a tool for mining issue-related artifacts from open source repositories. It compares the tool's performance against state-of-the-art alternatives, reporting that G-Issue is faster but uses more memory. It further examines issue lifetime and evolution patterns across well-known maintained repositories and concludes that these patterns support issue prioritization for management and developer assignment.

Significance. If the extraction accuracy were validated and the performance/prioritization analyses rested on documented datasets and statistical procedures, the work could supply practical empirical guidance for issue tracking in open-source projects.

major comments (2)
  1. [Abstract] Abstract: performance and prioritization conclusions are stated without any description of the datasets used, statistical methods, error handling, or validation procedures, so the claims cannot be assessed from the given text.
  2. [Results] Results (performance and prioritization sections): both the claim that G-Issue is faster yet higher-memory than the general Python API and the claim that lifetime/evolution data enable prioritization presuppose that G-Issue extracts issue artifacts completely and correctly; no ground-truth validation step (manual audit, cross-check against GitHub REST responses, or duplicate-handling audit) is described, which is load-bearing for the reported timings and evolution statistics.
minor comments (1)
  1. [Abstract] Abstract: the phrase 'during mining issue mining' is redundant and should be rephrased for clarity.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive comments and the recommendation for major revision. The points raised about the abstract and the need for validation of extraction accuracy are important for strengthening the manuscript. We address each major comment below and will incorporate revisions accordingly.

read point-by-point responses
  1. Referee: [Abstract] Abstract: performance and prioritization conclusions are stated without any description of the datasets used, statistical methods, error handling, or validation procedures, so the claims cannot be assessed from the given text.

    Authors: We agree that the abstract would benefit from greater specificity to allow assessment of the claims. In the revised version, we will expand the abstract to reference the specific well-known open-source repositories examined, the direct timing and memory measurements against the Python GitHub API, and the descriptive (rather than inferential) nature of the lifetime and evolution patterns used for prioritization. This change will improve transparency without exceeding abstract length limits. revision: yes

  2. Referee: [Results] Results (performance and prioritization sections): both the claim that G-Issue is faster yet higher-memory than the general Python API and the claim that lifetime/evolution data enable prioritization presuppose that G-Issue extracts issue artifacts completely and correctly; no ground-truth validation step (manual audit, cross-check against GitHub REST responses, or duplicate-handling audit) is described, which is load-bearing for the reported timings and evolution statistics.

    Authors: The referee correctly identifies that the performance and prioritization results rest on the assumption of accurate extraction. The manuscript describes G-Issue's use of the GitHub REST API but does not present an explicit validation procedure. We will add a dedicated validation subsection that reports a manual audit of a random sample of extracted issues against direct GitHub API responses, along with discussion of duplicate handling. This will directly address the load-bearing concern for both the timing results and the evolution statistics. revision: yes

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: empirical tool comparison and repository analysis are self-contained

full rationale

The paper reports an empirical evaluation of the G-Issue mining tool against Python APIs on selected repositories, followed by descriptive statistics on issue lifetime and evolution. No equations, fitted parameters, predictions, or derivations appear in the provided text. Performance claims rest on direct runtime and memory measurements rather than any self-referential definition or input-as-output reduction. Issue prioritization suggestions are presented as observational outcomes from the extracted data, not as a mathematical result forced by prior self-citations or ansatzes. The analysis is therefore independent of the circularity patterns enumerated in the instructions.

Assumptions & free parameters 0 free parameters · 0 assumptions · 1 invented entities

The paper introduces a new tool and reports empirical observations without specifying mathematical parameters, background axioms, or new postulated entities beyond the tool itself.

invented entities (1)
  • G-Issue
    purpose: Mining issue-related artifacts from open source repositories
    The tool is presented as the central contribution of the paper.

how reviews work

0 comments
Cite this review

Pith. "Pith review of G-Issue: Analyzing Lifetime and Evolution of Issue-related Artifacts from Open Source Repositories." pith.science (2026). https://pith.science/paper/VSWP62WX

@misc{pith2026260621837,
  author       = {Pith},
  title        = {Pith review of: G-Issue: Analyzing Lifetime and Evolution of Issue-related Artifacts from Open Source Repositories},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/VSWP62WX}},
  note         = {Machine review of arXiv:2606.21837}
}
read the original abstract

Software developers or contributors report issues related to bugs, errors, and missing documentation during community-based software development. These issues are treated as feedback and are crucial to enhancing software new features, documentation, and quality. If software issues are not being addressed with a correct developer, software quality degrades and is unable to use in the end. Hence, it is essential to analyze the software issue-related artifacts to understand the behavior of the software. This paper investigates the performance of the proposed issue-related artifacts mining tool G-Issue with other state-of-the-art tools. We also investigate issue lifetime and evolution of issues over time among well-known and maintained repositories. The results show that G-Issue is faster in mining issue-related artifacts but takes more memory than general Python API during mining issue mining. The results depict that we can prioritize issues based on issue lifetime and evolution. Such results may provide a new horizon about issues that can help in issue management, developer assignment, and quality management. G-Issue URL: https://www.smreza.com/projects/modelmine/issues.php

Figures

Figures reproduced from arXiv: 2606.21837 by the authors.

Figure 1
Figure 1. Architecture of G-Issue Tool With these research questions, we aim to provide a more pro￾found knowledge of the capabilities of G-Issue in mining and anal￾ysis of issue-related artifacts. The following subsections report the architecture of G-Issue and the steps that we conducted to collect the dataset. 3.2 G-Issue Architecture In this section, we discuss the architecture of the issue mining tool G-Issue that we bui… view at source ↗
Figure 2
Figure 2. Search & result screenshot of G-Issue Tool [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Box plot of days it takes to solve issues among [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: evolution of issue-related artifacts over time among [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 3 canonical work pages

  1. [1]

    Andrew Begel, Jan Bosch, and Margaret-Anne Storey. 2013. Social networking meets software development: Perspectives from github, msdn, stack exchange, and topcoder.IEEE software30, 1 (2013), 52–66

  2. [2]

    Dane Bertram, Amy Voida, Saul Greenberg, and Robert Walker. 2010. Commu- nication, collaboration, and bugs: the social nature of issue tracking in small, collocated teams. InProceedings of the 2010 ACM conference on Computer supported cooperative work. 291–300

  3. [3]

    Shikhar Bharadwaj and Tushar Kadam. 2022. Github issue classification us- ing bert-style models. In2022 IEEE/ACM 1st International Workshop on Natural Language-Based Software Engineering (NLBSE). IEEE, 40–43

  4. [4]

    Tegawendé F Bissyandé, David Lo, Lingxiao Jiang, Laurent Réveillere, Jacques Klein, and Yves Le Traon. 2013. Got issues? who cares about it? a large scale inves- tigation of issue trackers from github. In2013 IEEE 24th international symposium on software reliability engineering (ISSRE). IEEE, 188–197

  5. [5]

    John D Blischak, Emily R Davenport, and Greg Wilson. 2016. A quick introduction to version control with Git and GitHub.PLoS computational biology12, 1 (2016), e1004668

  6. [6]

    Farias, Renato Novais, Methanias Colaço Júnior, Luís Paulo da Silva Carvalho, Manoel Mendonça, and Rodrigo Oliveira Spínola

    Mário André de F. Farias, Renato Novais, Methanias Colaço Júnior, Luís Paulo da Silva Carvalho, Manoel Mendonça, and Rodrigo Oliveira Spínola. 2016. A systematic mapping study on mining software repositories. InProceedings of the 31st Annual ACM Symposium on Applied Computing. 1472–1479

  7. [7]

    Jin Ding, Hailong Sun, Xu Wang, and Xudong Liu. 2018. Entity-level sentiment analysis of issue comments. InProceedings of the 3rd International Workshop on Emotion A wareness in Software Engineering. 7–13

  8. [8]

    Santiago Dueñas, Valerio Cosentino, Gregorio Robles, and Jesus M Gonzalez- Barahona. 2018. Perceval: software project data at your will. InProceedings of the 40th International Conference on Software Engineering: Companion Proceeedings. 1–4

Show all 38 references
  1. [9]

    Robert Dyer, Hoan Anh Nguyen, Hridesh Rajan, and Tien N Nguyen. 2013. Boa: A language and infrastructure for analyzing ultra-large-scale software repositories. In2013 35th International Conference on Software Engineering (ICSE). IEEE, 422– 431

  2. [10]

    Aron Fiechter, Roberto Minelli, Csaba Nagy, and Michele Lanza. 2021. Visualizing github issues. In2021 Working Conference on Software Visualization (VISSOFT). IEEE, 155–159

  3. [11]

    2013.Utilizing Atlassian JIRA for large- scale software development management

    John Fisher, D Koning, and AP Ludwigsen. 2013.Utilizing Atlassian JIRA for large- scale software development management. Technical Report. Lawrence Livermore National Lab.(LLNL), Livermore, CA (United States)

  4. [12]

    Mehdi Golzadeh, Alexandre Decan, Damien Legay, and Tom Mens. 2021. A ground-truth dataset and classification model for detecting bots in GitHub issue and PR comments.Journal of Systems and Software175 (2021), 110911

  5. [13]

    Georgios Gousios and Diomidis Spinellis. 2012. GHTorrent: GitHub’s data from a firehose. In2012 9th IEEE Working Conference on Mining Software Repositories (MSR). IEEE, 12–21

  6. [14]

    Georgios Gousios, Bogdan Vasilescu, Alexander Serebrenik, and Andy Zaidman

  7. [15]

    InProceedings of the 11th working conference on mining software repositories

    Lean GHTorrent: GitHub data on demand. InProceedings of the 11th working conference on mining software repositories. 384–387

  8. [16]

    Emitza Guzman, David Azócar, and Yang Li. 2014. Sentiment analysis of commit comments in GitHub: an empirical study. InProceedings of the 11th working conference on mining software repositories. 352–355

  9. [17]

    Les Hatton, Diomidis Spinellis, and Michiel van Genuchten. 2017. The long-term growth rate of evolving software: Empirical results and implications.Journal of Software: Evolution and Process29, 5 (2017), e1847

  10. [18]

    Francisco Jurado and Pilar Rodriguez. 2015. Sentiment Analysis in monitoring software development processes: An exploratory case study on GitHub’s project issues.Journal of Systems and Software104 (2015), 82–89

  11. [19]

    Rafael Kallis, Andrea Di Sorbo, Gerardo Canfora, and Sebastiano Panichella

  12. [20]

    In2019 IEEE International Conference on Software Maintenance and Evolution (ICSME)

    Ticket tagger: Machine learning driven issue classification. In2019 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 406–409

  13. [21]

    Riivo Kikas, Marlon Dumas, and Dietmar Pfahl. 2016. Using dynamic and con- textual features to predict issue lifetime in github projects. In2016 ieee/acm 13th working conference on mining software repositories (msr). IEEE, 291–302

  14. [22]

    Zhifang Liao, Dayu He, Zhijie Chen, Xiaoping Fan, Yan Zhang, and Shengzong Liu. 2018. Exploring the characteristics of issue-related behaviors in github using visualization techniques.IEEE Access6 (2018), 24003–24015

  15. [23]

    Mitch Rees-Jones, Matthew Martin, and Tim Menzies. 2017. Better predictors for issue lifetime.arXiv preprint arXiv:1702.07735(2017)

  16. [24]

    Sayed Mohsin Reza, Omar Badreddin, and Khandoker Rahad. 2020. Modelmine: a tool to facilitate mining models from open source repositories. InProceed- ings of the 23rd ACM/IEEE International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings. 1–5

  17. [25]

    2022.CSIQ: A Synthesized Dataset of Code Smells, Issues and Quality related Artifacts from Open Source Repositories

    Sayed Mohsin Reza, Saif Uddin Mahmud, Khandoker Rahad, and Omar Badreddin. 2022.CSIQ: A Synthesized Dataset of Code Smells, Issues and Quality related Artifacts from Open Source Repositories. https://doi.org/10.17632/77p6rzb73n

  18. [26]

    Julio César Cortés Ríos, Kamilla Kopec-Harding, Sukru Eraslan, Christopher Page, Robert Haines, Caroline Jay, and Suzanne M Embury. 2019. A methodology for using GitLab for software engineering learning analytics. In2019 IEEE/ACM 12th International Workshop on Cooperative and ...

  19. [27]

    Gema Rodríguez-Pérez, Jesús M Gonzalez-Barahona, Gregorio Robles, Dorealda Dalipaj, and Nelson Sekitoleko. 2016. Bugtracking: A tool to assist in the identifi- cation of bug reports. InIFIP International Conference on Open Source Systems. Springer, 192–198

  20. [28]

    Simone Romano, Maria Caulo, Matteo Buompastore, Leonardo Guerra, Anas Mounsif, Michele Telesca, Maria Teresa Baldassarre, and Giuseppe Scanniello

  21. [29]

    In2021 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER)

    G-Repo: a Tool to Support MSR Studies on GitHub. In2021 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 551– 555

  22. [30]

    Francisco Zigmund Sokol, Mauricio Finavaro Aniche, and Marco Aurélio Gerosa

  23. [31]

    In 2013 IEEE 13th International Working Conference on Source Code Analysis and Manipulation (SCAM)

    MetricMiner: Supporting researchers in mining software repositories. In 2013 IEEE 13th International Working Conference on Source Code Analysis and Manipulation (SCAM). IEEE, 142–146

  24. [32]

    Davide Spadini, Maurício Aniche, and Alberto Bacchelli. 2018. Pydriller: Python framework for mining software repositories. InProceedings of the 2018 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 908–911

  25. [33]

    Xiaobing Sun, Bixin Li, Hareton Leung, Bin Li, and Yun Li. 2015. MSR4SM: Using topic models to effectively mining software repositories for software maintenance tasks.Information and Software Technology66 (2015), 1–12

  26. [34]

    José Apolinário Teixeira and Helena Karsten. 2019. Managing to release early, often and on time in the OpenStack software ecosystem.Journal of Internet Services and Applications10, 1 (2019), 1–22

  27. [35]

    Jun Wang, Xiaofang Zhang, and Lin Chen. 2021. How well do pre-trained contex- tual language representations recommend labels for GitHub issues?Knowledge- Based Systems232 (2021), 107476

  28. [36]

    Jun Wang, Xiaofang Zhang, Lin Chen, and Xiaoyuan Xie. 2022. Personalizing label prediction for GitHub issues.Information and Software Technology145 (2022), 106845

  29. [37]

    Bo Yang, Xinjie Wei, and Chao Liu. 2017. Sentiments analysis in GitHub reposito- ries: An empirical study. In2017 24th Asia-Pacific Software Engineering Conference Workshops (APSECW). IEEE, 84–89

  30. [38]

    Ting Zhang, Ivana Clairine Irsan, Ferdian Thung, DongGyun Han, David Lo, and Lingxiao Jiang. 2022. itiger: An automatic issue title generation tool.arXiv preprint arXiv:2206.10811(2022)

Pith tools

Reviewed June 26, 2026 · model on record in the stance chip above.