arXiv subjects

Pragyan KC

Publications and source records attributed to Pragyan KC.

5 recordsLinked to original sources

arXiv2026

From Community Forums to Issue Trackers: A Moodle Case Study

Sustaining open-source software (OSS) requires effective practices for evolution and change management. In OSS projects, evolution is largely driven by feature requests and enhancements proposed by diverse stakeholders. These requests are often discussed across multiple communication channels, particularly community forums and issue trackers, where stake-holders negotiate intent, clarify requirements, and coordinate development. Despite prior research on OSS forums and issue trackers, we lack an empirical understanding of who creates and maintains links between forum posts and tracker issues, and how these links support clarification, feedback, and coordination throughout feature request lifecycles. To address these questions, we conduct an in-depth case study of Moodle, a widely used open-source learning management system. Our study combines (1) an empirical analysis of cross-channel trace links between Moodle's community forum and its Jira issue tracker, (2) semi-structured interviews with developers, and (3) semi-structured interviews with forum participants. Our results show that cross-channel traceability is rare: only 818 of 23,169 (~3.5%) feature request issues in Moodle's Jira link back to a community forum, and authorship differs by channel, with developers authoring 52.8% of tracker issues, while forum feature requests are predominantly authored by users, and only 230 linked pairs share the same author. The qualitative findings further reveal that the transition from forum posts to issues is largely ad hoc, with limited tool support and unclear role ownership, and that users often experience the process as opaque or weakly responsive.

cs.SE↗

arXiv2025

Towards Better Requirements from the Crowd: Developer Engagement with Feature Requests in Open Source Software

As user demands evolve, effectively incorporating feature requests is crucial for maintaining software relevance and user satisfaction. Feature requests, typically expressed in natural language, often suffer from ambiguity or incomplete information due to communication gaps or the requester's limited technical expertise. These issues can lead to misinterpretation, faulty implementation, and reduced software quality. While seeking clarification from requesters is a common strategy to mitigate these risks, little is known about how developers engage in this clarification process in practice-how they formulate clarifying questions, seek technical or contextual details, align on goals and use cases, or decide to close requests without attempting clarification. This study investigates how feature requests are prone to NL defects (i.e. ambiguous or incomplete) and the conversational dynamics of clarification in open-source software (OSS) development, aiming to understand how developers handle ambiguous or incomplete feature requests. Our findings suggest that feature requests published on the OSS platforms do possess ambiguity and incompleteness, and in some cases, both. We also find that explicit clarification for the resolution of these defects is uncommon; developers usually focus on aligning with project goals rather than resolving unclear text. When clarification occurs, it emphasizes understanding user intent/goal and feasibility, rather than technical details. By characterizing the dynamics of clarification in open-source issue trackers, this work identifies patterns that can improve user-developer collaboration and inform best practices for handling feature requests effectively.

cs.SE↗

arXiv2025

Demystifying Feature Requests: Leveraging LLMs to Refine Feature Requests in Open-Source Software

The growing popularity and widespread use of software applications (apps) across various domains have driven rapid industry growth. Along with this growth, fast-paced market changes have led to constantly evolving software requirements. Such requirements are often grounded in feature requests and enhancement suggestions, typically provided by users in natural language (NL). However, these requests often suffer from defects such as ambiguity and incompleteness, making them challenging to interpret. Traditional validation methods (e.g., interviews and workshops) help clarify such defects but are impractical in decentralized environments like open-source software (OSS), where change requests originate from diverse users on platforms like GitHub. This paper proposes a novel approach leveraging Large Language Models (LLMs) to detect and refine NL defects in feature requests. Our approach automates the identification of ambiguous and incomplete requests and generates clarification questions (CQs) to enhance their usefulness for developers. To evaluate its effectiveness, we apply our method to real-world OSS feature requests and compare its performance against human annotations. In addition, we conduct interviews with GitHub developers to gain deeper insights into their perceptions of NL defects, the strategies they use to address these defects, and the impact of defects on downstream software engineering (SE) tasks.

cs.SE↗

arXiv2024

An Analysis of Automated Use Case Component Extraction from Scenarios using ChatGPT

Mobile applications (apps) are often developed by only a small number of developers with limited resources, especially in the early years of the app's development. In this setting, many requirements acquisition activities, such as interviews, are challenging or lower priority than development and release activities. Moreover, in this early period, requirements are frequently changing as mobile apps evolve to compete in the marketplace. As app development companies move to standardize their development processes, however, they will shift to documenting and analyzing requirements. One low-cost source of requirements post-deployment are user-authored scenarios describing how they interact with an app. We propose a method for extracting use case components from user-authored scenarios using large language models (LLMs). The method consists of a series of prompts that were developed to improve precision and recall on a ground truth dataset of 50 scenarios independently labeled with UC components. Our results reveal that LLMs require additional domain knowledge to extract UC components, and that refining prompts to include this knowledge improves the quality of the extracted UC components.

cs.SE↗

arXiv2024

Toward Regulatory Compliance: A few-shot Learning Approach to Extract Processing Activities

The widespread use of mobile applications has driven the growth of the industry, with companies relying heavily on user data for services like targeted advertising and personalized offerings. In this context, privacy regulations such as the General Data Protection Regulation (GDPR) play a crucial role. One of the GDPR requirements is the maintenance of a Record of Processing Activities (RoPA) by companies. RoPA encompasses various details, including the description of data processing activities, their purposes, types of data involved, and other relevant external entities. Small app-developing companies face challenges in meeting such compliance requirements due to resource limitations and tight timelines. To aid these developers and prevent fines, we propose a method to generate segments of RoPA from user-authored usage scenarios using large language models (LLMs). Our method employs few-shot learning with GPT-3.5 Turbo to summarize usage scenarios and generate RoPA segments. We evaluate different factors that can affect few-shot learning performance consistency for our summarization task, including the number of examples in few-shot learning prompts, repetition, and order permutation of examples in the prompts. Our findings highlight the significant influence of the number of examples in prompts on summarization F1 scores, while demonstrating negligible variability in F1 scores across multiple prompt repetitions. Our prompts achieve successful summarization of processing activities with an average 70% ROUGE-L F1 score. Finally, we discuss avenues for improving results through manual evaluation of the generated summaries.

cs.SE↗