Qunhong Zeng

Issue localization, the process of identifying code locations that need modification to resolve software issues, is a critical yet challenging task in software development. The semantic gap between natural language issue descriptions and faulty code requires complex multi-hop reasoning through code dependencies. Existing LLM-based agents attempt to address this by integrating repository retrieval tools, which poses a higher demand for LLMs to effectively utilize various tools during multi-step reasoning for issue localization. To tackle this challenge, we present ToolTrain, a two-stage tool-interactive training framework combining rejection-sampled supervised fine-tuning and tool-interactive reinforcement learning to enhance LLMs’ ability to use retrieval tools for issue localization. Experimental results show that ToolTrain-trained models achieve state-of-the-art performance among same-size LLMs, with our 32B model even surpassing Claude-3.7-Sonnet on function-level localization. The results also show that improved localization performance translates to better end-to-end issue resolution performance. This further demonstrates that training for issue localization is a viable and effective strategy for improving automated software development.

Open source software (OSS) development widely adopts modern code review to identify issues and guarantee code quality. As reported repeatedly, maintainers are under heavy workloads when reviewing code changes. Meanwhile, we notice that some code reviews were overlooked by the authors of the code changes, i.e., neither causing code modification nor being replied to. These code reviews, if requiring responses but not receiving any, might represent a significant inefficiency, risk of overlooking critical issues, and problematic social exchange. Moreover, leaving code reviews publicly unanswered may cause a negative impression on both the corresponding OSS contributors and the OSS projects. Existing literature on code review mainly focuses on the usefulness of code reviews, reviewer recommendations, factors affecting PR acceptance, and review comment generation; the nature of overlooked reviews has not been explored. To this end, we focus on a widely-used modern code review mechanism, i.e., reviewing Pull Request (PR) code before merge, and conduct the first empirical study on 80 Java OSS projects to explore the prevalence, characteristics, rationales, and possible impact of the overlooked code reviews. We find that approximately 7.5% of PRs have at least one review comment being ignored. We further show that pull requests containing no-response comments are significantly associated with longer review lifecycles and lower acceptance rates, indicating measurable negative outcomes beyond their modest prevalence. Then, we categorize these no-response comments through thematic analysis and find two main categories with seven subcategories: Review inquiry and PR management. We also extract four subcategories in Review inquiry, e.g., Give suggestions about code implementation, Point out implementation issues, and Additional task requests. PR management consists of three subcategories, i.e., PR status checks, PR merge conflict notifications, and Reject PR with uncertain reasons. To better understand the existence of no-response comments, we surveyed developers and received 45 responses. We found that the reasons for the existence of no-response comments are diverse, such as prolonged review times and a lack of consensus on opinions. Developers also hold the consensus that ignored reviews will have negative effects on software projects. These findings emphasize the need for attention from both academia and industry to the responses to review comments and optimization of the reminder mechanism.

An increasing number of companies are contributing to open source software (OSS) projects by assigning their employees to advance their business objectives. These paid developers collaborate with volunteer contributors, but the differing motivations of these two groups can sometimes lead to conflicts, which might endanger the OSS project's sustainability. This article presents a multi-method comparative study of paid developers and volunteers in Rust, currently one of the most popular open source programming languages. We compare volunteers and paid developers through contribution behavior, social collaboration, and long-term participation. Then, we solicit volunteers’ perceptions of paid developers and explore the emotions caused when volunteers transition to paid roles. We find that core paid developers tend to contribute more frequently; peripheral paid developers contribute bigger commits and focus more on implementing features; both core and peripheral paid developers collaborate more with volunteers but less intensively than expected; and being paid correlates positively with becoming a long-term contributor. Our study also reveals existing unfamiliarity and prejudices among volunteers towards paid developers, and that volunteer-to-paid transitions can evoke negative community sentiments. This study suggests that the dichotomous view of paid vs. volunteer developers is too simplistic and that further subgroups could be identified. Contributing organizations should become more sensitive to how OSS communities perceive them when they attempt to get involved and make improvements.