Collaborative Software Development Research Articles

ConflictBench: A benchmark to evaluate software merge tools

In collaborative software development, programmers create branches for simultaneous program editing, and merge branches to integrate edits. When branches divergently edit the same text, the edits conflict and cannot get co-applied. Tools were built to automatically merge software branches, to detect conflicts, and to resolve conflicts along the way. However, there is no third-party benchmark or metric to comprehensively evaluate or compare those tools.This paper presents ConflictBench, our novel benchmark to evaluate software merge tools. ConflictBench consists of 180 merging scenarios extracted from 180 open-source Java projects. For each scenario, we sampled a conflicting chunk (i.e., conflict) reported by git-merge. Because git-merge sometimes wrongly reports conflicts, with our manual inspection, we labeled 136 of the 180 chunks as true conflicts, and 44 chunks as false conflicts. To facilitate tool evaluation, we also defined a systematic method of manual analysis toanalyze all program versions involved in each merging scenario, and to summarize the root causes as well as developers’ resolution strategies. We further defined three novel metrics to evaluate merge tools. By applying five state-of-the-art tools to ConflictBench, we observed that ConflictBench is effective to characterize different tools. It helps reveal limitations of existing tools and sheds light on future research.

Accessibility issues in establishing awareness on remote collaborative software development

The COVID-19 pandemic impacted the work dynamics of software development teams with the sudden adoption and subsequent continuation of remote work. New practices were adopted to maintain relationships between team members, mediated by computational tools. However, this presents an additional challenge for people with visual or hearing impairments. This study identifies different experiences of professionals with and without these disabilities in maintaining awareness when working remotely. To achieve this objective, 93 responses were collected through an online form from professionals, with and without visual or hearing impairments, and the supervision of a collaboration tool, among the most mentioned due to the lack of accessibility for people with visual impairments, using the Semiotic Inspection Method with Screen Reader (MIS-LT). The results point to different groups’ experiences with the use of collaborative tools on the social aspects of remote collaboration and an assessment of the communicability and accessibility of the inspected tool.

Probabilistic Model Checking GitHub Repositories for Software Project Analysis

GitHub serves as a platform for collaborative software development, where contributors engage, evolve projects, and shape the community. This study presents a novel approach to analyzing GitHub activity that departs from traditional methods. Using Discrete-Time Markov Chains and probabilistic Computation Tree Logic for model checking, we aim to uncover temporal dynamics, probabilities, and key factors influencing project behavior. By explicitly modeling state transitions, our approach provides transparency and explainability for sequential properties. The application of our method to five repositories demonstrates its feasibility and scalability and provides insights into the long-term probabilities of various activities. In particular, the analysis provides valuable perspectives for project managers to optimize team dynamics and resource allocation. The query specifications developed for model checking allow users to generate and execute queries for specific aspects, demonstrating scalability beyond the queries we present. In conclusion, our analysis provides an understanding of GitHub repository properties, branch management, and subscriber behavior. We anticipate its applicability to various open-source projects, revealing trends among contributors based on the unique characteristics of repositories.

Two different methods to digitally visualize continuous electrocochleography potentials during cochlear implantation: a first description of feasibility

PurposeThe study explores the potential of real-time electrocochleographic potentials (ECochG) visualization during electrode insertion using digital microscopes such as RoboticScope (BHS®). Collaborative software development of the MAESTRO Software (MED-EL®) offers continuous ECochG monitoring during implantation and postoperative hearing evaluation, addressing previous time constraints. The study aims to assess software applicability and the impact of real-time visualization on long-term residual hearing preservation.MethodsEight patients with residual hearing underwent cochlear implantation with Flex26 or Flex28 electrode according to the Otoplan evaluation. ECochG responses were measured and visualized during electrode insertion, with insertion times recorded. Two randomized display methods (graph and arrows) tracked ECochG potentials. Postoperative behavioral thresholds determined hearing preservation. Successful real-time intraoperative ECochG visualization was achieved in all cases, enabling surgeon adaptation. Mean electrode insertion time was 114 s, with postoperative thresholds comparable to preoperative values. Visualization did not affect surgeon workload. ECochG amplitudes differed between patients with and without residual hearing.ConclusionThe study demonstrates effective implementation of advanced ECochG software combined with real-time visualization, enabling residual hearing preservation during CI. Visualization had no apparent effect on surgeon performance or workload. Future investigation involving a larger population will assess the long-term impact of ECochG on hearing threshold and structure preservation.

Agcounts: An R Package to Calculate ActiGraph Activity Counts From Portable Accelerometers

Portable accelerometers are used to capture physical activity in free-living individuals with the ActiGraph being one of the most widely used device brands in physical activity and health research. Recently, in February 2022, ActiGraph published their activity count algorithm and released a Python package for generating activity counts from raw acceleration data for five generations of ActiGraph devices. The nonproprietary derivation of the ActiGraph count improved the transparency and interpretation of accelerometer device-measured physical activity, but the Python release of the count algorithm does not integrate with packages developed by the physical activity research community using the R Statistical Programming Language. In this technical note, we describe our efforts to create an R-based translation of ActiGraph’s Python package with additional extensions to make data processing easier and faster for end users. We call the resulting R package agcounts and provide an inside look at its key functionalities and extensions while discussing its prospective impacts on collaborative open-source software development in physical behavior research. We recommend that device manufacturers follow ActiGraph’s lead by providing open-source access to their data processing algorithms and encourage physical activity researchers to contribute to the further development and refinement of agcounts and other open-source software.

Looking for related posts on GitHub discussions

Software teams increasingly adopt different tools and communication channels to aid the software collaborative development model and coordinate tasks. Among such resources, software development forums have become widely used by developers. Such environments enable developers to get and share technical information quickly. In line with this trend, GitHub announced GitHub Discussions—a native forum to facilitate collaborative discussions between users and members of communities hosted on the platform. Since GitHub Discussions is a software development forum, it faces challenges similar to those faced by systems used for asynchronous communication, including the problems caused by related posts (duplicated and near-duplicated posts). These related posts can add noise to the platform and compromise project knowledge sharing. Hence, this article addresses the problem of detecting related posts on GitHub Discussions. To achieve this, we propose an approach based on a Sentence-BERT pre-trained general-purpose model: the RD-Detector. We evaluated RD-Detector using data from three communities hosted in GitHub. Our dataset comprises 16,048 discussion posts. Three maintainers and three Software Engineering (SE) researchers manually evaluated the RD-Detector results, achieving 77–100% of precision and 66% of recall. In addition, maintainers pointed out practical applications of the approach, such as providing knowledge to support merging the discussion posts and converting the posts to comments on other related posts. Maintainers can benefit from RD-Detector to address the labor-intensive task of manually detecting related posts.

Automatic prediction of developers’ resolutions for software merge conflicts

In collaborative software development, developers simultaneously work in parallel on different branches that they merge periodically. When edits from different branches textually overlap, conflicts may occur. Manually resolving conflicts can be tedious and error-prone. Researchers proposed tool support for conflict resolution, but these tools barely consider developers’ preferences. Conflicts can be resolved by: keeping the local version only KL, keeping the remote version only (KR), or manually editing them (ME). Recent studies show that developers resolved the majority of textual conflicts by KL or KR. Thus, we created a machine learning-based approach RPredictor to predict developers’ resolution strategy (KL, KR, or ME) given a merge conflict. We did large-scale experiments on the historical resolution of 74,861 conflicts. Our experiments show that RPredictor achieved 63% F-score for within-project prediction and 46% F-score for cross-project prediction. Compared with other classifiers, RPredictor provides the highest effectiveness when using a random forest (RF) classifier. Finally, we proposed a variant technique RPredictorv, which enables developers to customize its prediction conservativeness. For a highly conservative setting, RPredictorv achieved 34% effort saving while minimizing the risk of producing incorrect prediction labels.

FORMATION OF COMPETENCIES OF COLLECTIVE SOFTWARE DEVELOPMENT OF STUDENTS IN THE FIELD OF INFORMATION TECHNOLOGY IN THE PROCESS OF USING FREE SOFTWARE

The article analyzes the existing systems that provide an opportunity for collective software development by students of information technology and offers recommendations for their use in the educational process. In the authors' opinion, it is advisable to use free versions of the Atlassian stack (Jira, Bitbucket, Confluence), which allows forming professional competencies in collaborative software development of future specialists, while the limitations of free versions are not critical for educational purposes.
 The concept of the competence of collective software development of an information technology specialist is formulated, by which we mean the integrated ability of an individual to effectively solve software development tasks in the process of teamwork in professional activities.
 It has been found that software development requires the implementation of many steps, from defining requirements to testing and releasing a product. In the process of forming a collective software development of an information technology specialist, cloud services and other systems (Bitbucket, GitHub, GitLab, Jira, Asana, Basecamp, Mantis, Bugzilla, etc.) are used.
 Training future IT professionals in the development process and involvement in real software development projects will help them acquire, develop, and improve their collaborative software development competencies.

Sistem Rancangan Pendataan Yatim, Fakir Miskin dan Lansia pada Kantor Desa Baet Kecamatan Baitussalam Kabupaten Aceh Besar

This study discusses the design of a data collection system for orphans, the poor, and the elderly at the Baet Village Office, Baitussalam District, Aceh Besar. The problem discussed is how to use computer technology to enter data into the data collection system. The purpose of this study was to determine the use of the data collection system. The data for this study were collected through a literature study which involved reviewing books and materials related to the topic. In addition, field studies were also carried out by conducting interviews and direct observation of objects related to this research report. Apart from that, in this study, the authors also utilized the Extreme Programming (XP) method in the process of developing a data collection system. The XP method is an Agile method that enables adaptive, collaborative, and iterative software development. The results showed that the use of computer technology and the XP method in the development of a data collection system was able to speed up the process of collecting and processing data, as well as increasing work efficiency and effectiveness. In addition, the developed data collection system is also able to produce more accurate and integrated data, so that it can assist the village government in planning and making more appropriate decisions related to community services, especially orphans, the poor, and the elderly.

DeepMerge: Learning to Merge Programs

In collaborative software development, program merging is <i>the</i> mechanism to integrate changes from multiple programmers. Merge algorithms in modern version control systems report a conflict when changes interfere textually. Merge conflicts require manual intervention and frequently stall modern continuous integration pipelines. Prior work found that, although costly, a large majority of resolutions involve re-arranging text without writing any new code. Inspired by this observation we propose the <i>first data-driven approach</i> to resolve merge conflicts with a machine learning model. We realize our approach in a tool DEEPMERGE that uses a novel combination of (i) an edit-aware embedding of merge inputs and (ii) a variation of pointer networks, to construct resolutions from input segments. We also propose an algorithm to localize manual resolutions in a resolved file and employ it to curate a ground-truth dataset comprising 8,719 non-trivial resolutions in JavaScript programs. Our evaluation shows that, on a held out test set, DEEPMERGE can predict correct resolutions for 37&#x0025; of non-trivial merges, compared to only 4&#x0025; by a state-of-the-art semistructured merge technique. Furthermore, on the subset of merges with upto 3 lines (comprising 24&#x0025; of the total dataset), DEEPMERGE can predict correct resolutions with 78&#x0025; accuracy.

A Characterization Study of Merge Conflicts in Java Projects

In collaborative software development, programmers create software branches to add features and fix bugs tentatively, and then merge branches to integrate edits. When edits from different branches textually overlap (i.e., textual conflicts ) or lead to compilation and runtime errors (i.e., build and test conflicts ), it is challenging for developers to remove such conflicts. Prior work proposed tools to detect and solve conflicts. They investigate how conflicts relate to code smells and the software development process. However, many questions are still not fully investigated, such as what types of conflicts exist in real-world applications and how developers or tools handle them. For this article, we used automated textual merge, compilation, and testing to reveal three types of conflicts in 208 open-source repositories: textual conflicts, build conflicts (i.e., conflicts causing build errors), and test conflicts (i.e., conflicts triggering test failures). We manually inspected 538 conflicts and their resolutions to characterize merge conflicts from different angles. Our analysis revealed three interesting phenomena. First, higher-order conflicts (i.e., build and test conflicts) are harder to detect and resolve, while existing tools mainly focus on textual conflicts. Second, developers manually resolved most higher-order conflicts by applying similar edits to multiple program locations; their conflict resolutions share common editing patterns implying great opportunities for future tool design. Third, developers resolved 64% of true textual conflicts by keeping complete edits from either a left or right branch. Unlike prior studies, our research for the first time thoroughly characterizes three types of conflicts, with a special focus on higher-order conflicts and limitations of existing tool design. Our work will shed light on future research of software merge.

Nudge: Accelerating Overdue Pull Requests toward Completion

Pull requests are a key part of the collaborative software development and code review process today. However, pull requests can also slow down the software development process when the reviewer(s) or the author do not actively engage with the pull request. In this work, we design an end-to-end service, Nudge, for accelerating overdue pull requests toward completion by reminding the author or the reviewer(s) to engage with their overdue pull requests. First, we use models based on effort estimation and machine learning to predict the completion time for a given pull request. Second, we use activity detection to filter out pull requests that may be overdue but for which sufficient action is taking place nonetheless. Last, we use actor identification to understand who the blocker of the pull request is and nudge the appropriate actor (author or reviewer(s)). The key novelty of Nudge is that it succeeds in reducing pull request resolution time, while ensuring that developers perceive the notifications sent as useful, at the scale of thousands of repositories. In a randomized trial on 147 repositories in use at Microsoft, Nudge was able to reduce pull request resolution time by 60% for 8,500 pull requests, when compared to overdue pull requests for which Nudge did not send a notification. Furthermore, developers receiving Nudge notifications resolved 73% of these notifications as positive. We observed similar results when scaling up the deployment of Nudge to 8,000 repositories at Microsoft, for which Nudge sent 210,000 notifications during a full year. This demonstrates Nudge’s ability to scale to thousands of repositories. Last, our qualitative analysis of a selection of Nudge notifications indicates areas for future research, such as taking dependencies among pull requests and developer availability into account.

Software Development Practice as Baradian Entanglement

Software development practice is a messy, complicated, and constantly shifting human endeavor. Barad’s concept of “entanglement” helps to theorize complex sociotechnical systems. We are testing the application of this theory to understand and explain software development practices, as our work appears to be the only ethnographic research using Barad in any technology industry. Our continual aim is to understand large-scale, collaborative software development more deeply in practice and to discover appropriate theories that describe our observations and insights. Both authors are experienced software engineers and researchers. Through an ongoing longitudinal ethnographic study at a large Australian software development company, we explore, support, and improve the lived experience and practice of the software developers that work there. Ethnographic insights and an appreciation of the mutual constitution of situated phenomena have expanded over several years into an elaboration of entanglement as a more insightful explanation of software development practice. This research is having a significant impact on the participant developers and organization, including changes in measurement practices, mentoring, knowledge management, and innovation.

Co-Designing for a Hybrid Workplace Experience in Software Development

To achieve productive engineering practice, collaborative product innovation, and effective mentorship in hybrid work, we introduce a workshop approach on co-designing for a hybrid workplace experience and provide recommendations for continuously improving collaborative software development at scale.

CsdRec: Accuracy and Diversity-Awared Team Recommendation for Collaborative Software Development

CsdRec: Accuracy and Diversity-Awared Team Recommendation for Collaborative Software Development

INNOVATIONS IN TECHNOLOGY FOR SOCIAL ENGAGEMENT AMONG OLDER ADULTS AND TO IMPROVE CAREGIVER COMMUNICATION AND TRAINING

Abstract Music-based interventions (MBIs) have been shown to benefit persons with dementia. To develop new MBIs and build the evidence base for motor, cognitive, emotional, and behavioral outcomes, accurate measures of music exposure (e.g., content, dose, and duration) are critically important. However, most commercial music services require internet access and/or subscription fees without providing convenient ways for researchers to access music exposure data. Our research team developed the open-source MUsic to Support Engagement and Resilience (MUSER) Android application with an associated data processing engine. Caregivers can use MUSER to deliver individualized music selections via smartphones/tablets, with music exposure data being generated for research use. We used the Kotlin programming language for application development and Java/Python/Microsoft BI for data processing and analytics instrumentation. The MUSER application was tested for music exposure measurement feasibility with 16 users (ten research team members and six family caregivers of persons with dementia) for two weeks between July and November of 2021. Semi-structured interviews were conducted pre-post application testing to gather qualitative and quantitative data to enrich the understanding of user experiences. Family caregivers had a mean age of 57.8 (SD=26.2; range 20-77). The average number of listening days was 6 (SD=2.5), and the average music listening duration was 203 minutes (SD=123.2). Caregivers played an average of 52 (SD=36.9) songs from 10 (SD=4.2) albums involving 34 (SD=36.3) artists. Given the ease of deployment and integrated data collection and reporting capabilities, this application supports collaborative software development among researchers to advance MBI research.

On business adoption and use of reproducible builds for open and closed source software

Reproducible builds (R-Bs) are software engineering practices that reliably create bit-for-bit identical binary executable files from specified source code. R-Bs are applied in some open source software (OSS) projects and distributions to allow verification that the distributed binary has been built from the released source code. The use of R-Bs has been advocated in software maintenance and R-Bs are applied in the development of some OSS security applications. Nonetheless, industry application of R-Bs appears limited, and we seek to understand whether awareness is low or if significant technical and business reasons prevent wider adoption. Through interviews with software practitioners and business managers, this study explores the utility of applying R-Bs in businesses in the primary and secondary software sectors and the business and technical reasons supporting their adoption. We find businesses use R-Bs in the safety-critical and security domains, and R-Bs are valuable for traceability and support collaborative software development. We also found that R-Bs are valued as engineering processes and are seen as a badge of software quality, but without a tangible value proposition. There are good engineering reasons to use R-Bs in industrial software development, and the principle of establishing correspondence between source code and binary offers opportunities for the development of further applications.

Channeling End-User Creativity: Leveraging Live Streaming for Distributed Collaboration in Indie Game Development

This paper explores the role of live streaming in distributed collaborative software development using indie game development, an end-user driven creative community, as an example. We conducted 27 in-depth interviews with indie game developers from various cultures and countries, who had engaged in live streaming for collaborative software development either as a streamer or a viewer. Our findings show how live streaming can be used by indie game developers to support their endeavors to innovate the traditional game development model, which goes beyond just learning and teaching technical skills. We also highlight the potential challenges indie developers face in this process. We thus make unique contributions to CSCW by bridging the previously often disconnected research agendas on collaborative software development and live streaming. We also provide potential directions for designing future live streaming platforms to better support distributed collaboration in emerging end-user driven creative activities.

Opportunities and Challenges in Repeated Revisions to Pull-Requests: An Empirical Study

Background: The Pull-Request (PR) model is a widespread approach adopted by open source software (OSS) projects to support collaborative software development. However, it is often challenging to continuously evaluate and revise PRs in several iterations of code reviewsinvolving technical and social aspects. Aim: Our objective is twofold: identifying best practices for effective collaboration in continuous PR improvement and uncovering problems that deserve special attention to improve collaboration efficiency and productivity. Method: We conducted a mixed-methods empirical study of repeatedly revised PRs (i.e. those that have undergone a high number of revisions). Historical trace data of five long-lived popular GitHub projects were used for manual investigation of practices for requesting changes to PRs and reasons for nonacceptance of repeatedly revised PRs. Surveys of OSS practitioners were conducted to evaluate the results of manual analysis and to provide additional insights into developers' willingness regarding PR revisions and factors causing avoidable revisions in practice. Results: The main results of our research were as follows: (1) We identified 15 code review practices for requesting changes to PRs, among which practices with respect to explaining the reasoning behind requested changes and tracking the progress of PR review and revision were undervalued by reviewers; (2) While submitters can in general undergo 1-5 rounds of revisions, they are willing to offer more revisions when they are in a friendly community and receive helpful feedback; (3) We revealed 11 factors causing avoidable revisions regarding to reviewers' feedback, code review policy, pre-submission issues, and implementation of new revisions; and (4) Nonacceptance of repeatedly revised PRs was due mainly to inactivity of submitters or reviewers and being superseded for better maintenance. Finally, based on these findings, we proposed recommendations and implications for OSS practitioners and tool designers to facilitate efficient collaboration in PR revisions.

Understanding and Analyzing Factors that Affect Merge Conflicts from the Perspective of Software Developers

Merge conflicts are very common in collaborative software development, which is supported mainly by the use of branches that can be potentially merged. In this context, several studies have proposed mechanisms to avoid conflicts whenever possible and some identified factors that lead to conflicts. In this article, we report on an investigation of factors that can lead to conflicts or that can somehow reduce the chances of conflict from the developers’ perspective. To do so, based on related work, we conducted two empirical studies with Brazilian software developers to both understand and analyze factors that affect merge conflicts. Firstly, we conducted survey research with 109 software developers to understand how they use branches, the occurrence of conflicts and the resolution process, and factors that can lead to or avoid conflicts. Results showed that the use of branches is very common and mostly has the purpose of creating a new feature or fixing a bug. According to the participants, in most projects, developers have the autonomy to create new branches and sometimes conflicts happen. The main factors that can lead to conflicts are “the time a branch is isolated” and “lack of communication”. On the other hand, the factors cited as good practices to avoid conflicts were “improve team communication” and “less branching duration”. Secondly, we conducted a field study based on interviews with 15 software developers to analyze those factors to understand better what leads to or avoids conflicts in a merge. Finally, this work allowed us to conclude that communication with the team, checking code updates, shorter branch duration, and management are important for software developers, especially when they think about what increases and decreases merge conflicts.