Context and Motivation – Developer eXperience (Dev-X) is a recent research area that focuses on developers perceptions, feelings, and values with respect to software development and software quality. Research suggests that factors and practices related to Dev-X can have a substantial impact on developer productivity (Dev-P). However, despite a large and diverse body of literature on factors that can impact Dev-P in general, there is no coherent and comprehensive characterization of how Dev-X-specific insights can influence developer productivity. Aims – In the presented research, we aim to provide a coherent, comprehensive characterization of factors and practices related to Dev-X, with a particular focus on those factors and practices that potentially affect Dev-P. Method – To this end, we performed a systematic literature review and identified 218 relevant papers in this area. We characterize the papers based on the related frameworks and concepts common to Dev-X and Dev-P as presented in the existing literature. Dev-X factors such as “work fragmentation” and practices such as “collaboration with owner-developer” are identified using a grounded-in-the-literature, content-analysis method, guided by the theory. For each Dev-X factor, we identify attributes that might be used to assess/ measure the current status (of an organization or project) regarding that factor and how that factor and its effects on productivity have been evidenced in the literature (mentioned vs. considered in questionnaires vs. substantiated with a more positivist evaluation). Results – We identify 33 Dev-X-related factors and 41 Dev-X-related practices, which are organized into 10 themes to summarize their influence. The results suggest that the availability of required resources, relevant expertise re the allocated tasks, and fewer interruptions are among the top positively impacting factors. Conversely, factors such as code complexity, heterogeneous contexts of tasks, and non-adherence to standardization harm Dev-X and Dev-P. Top industrial practices employed to mitigate the negative influence of factors include characterization-based task assignments, mental model support, and the timely evolution of technologies. Conclusions – Overall, this research suggests that organizations can influence Dev-P through improved Dev-X, incorporating suitable practices to mediate relevant factors in their context. Important in this regard are practices such as fragmenting large tasks, highlighting the utility of proposed tasks/changes to the developers, and promoting (developer) ownership of artefacts. Finally, our results point to areas where further research seems appropriate, i.e., where Dev-X factors/practices have been proposed as being impactful on Dev-P but not yet fully substantiated or explored as such (factors like “Nature of Activity” and practices like choosing practices/protocols appropriately).

Background: Digital contact tracing apps have the potential to augment contact tracing systems and disrupt COVID-19 transmission by rapidly identifying secondary cases prior to the onset of infectiousness and linking them into a system of quarantine, testing, and health care worker case management. The international experience of digital contact tracing apps during the COVID-19 pandemic demonstrates how challenging their design and deployment are. Objective: This study aims to derive and summarize best practice guidance for the design of the ideal digital contact tracing app. Methods: A collaborative cross-disciplinary approach was used to derive best practice guidance for designing the ideal digital contact tracing app. A search of the indexed and gray literature was conducted to identify articles describing or evaluating digital contact tracing apps. MEDLINE was searched using a combination of free-text terms and Medical Subject Headings search terms. Gray literature sources searched were the World Health Organization Institutional Repository for Information Sharing, the European Centre for Disease Prevention and Control publications library, and Google, including the websites of many health protection authorities. Articles that were acceptable for inclusion in this evidence synthesis were peer-reviewed publications, cohort studies, randomized trials, modeling studies, technical reports, white papers, and media reports related to digital contact tracing. Results: Ethical, user experience, privacy and data protection, technical, clinical and societal, and evaluation considerations were identified from the literature. The ideal digital contact tracing app should be voluntary and should be equitably available and accessible. User engagement could be enhanced by small financial incentives, enabling users to tailor aspects of the app to their particular needs and integrating digital contact tracing apps into the wider public health information campaign. Adherence to the principles of good data protection and privacy by design is important to convince target populations to download and use digital contact tracing apps. Bluetooth Low Energy is recommended for a digital contact tracing app's contact event detection, but combining it with ultrasound technology may improve a digital contact tracing app's accuracy. A decentralized privacy-preserving protocol should be followed to enable digital contact tracing app users to exchange and record temporary contact numbers during contact events. The ideal digital contact tracing app should define and risk-stratify contact events according to proximity, duration of contact, and the infectiousness of the case at the time of contact. Evaluating digital contact tracing apps requires data to quantify app downloads, use among COVID-19 cases, successful contact alert generation, contact alert receivers, contact alert receivers that adhere to quarantine and testing recommendations, and the number of contact alert receivers who subsequently are tested positive for COVID-19. The outcomes of digital contact tracing apps' evaluations should be openly reported to allow for the wider public to review the evaluation of the app. Conclusions: In conclusion, key considerations and best practice guidance for the design of the ideal digital contact tracing app were derived from the literature.

Feature Location (FL) aims to locate observable functionalities in source code. Considering its key role in software maintenance, a vast array of automated and semi-automated Feature Location Techniques (FLTs) have been proposed. To compare FLTs, an open, standard set of non-subjective, reproducible “compare-to” FLT techniques (baseline techniques) should be used for evaluation. In order to relate the performance of FLTs compared against different baseline techniques, these compare-to techniques should be evaluated against each other. But evaluation across FLTs is confounded by empirical designs that incorporate different FL goals and evaluation criteria. This paper moves towards standardizing FLT comparability by assessing eight baseline techniques in an empirical design that addresses these confounding factors. These baseline techniques are assessed in twelve case studies to rank their performance. Results of the case studies suggest that different baseline techniques perform differently and that VSM-Lucene and LSI-Matlab performed better than other implementations. By presenting the relative performances of baseline techniques this paper facilitates empirical cross-comparison of existing and future FLTs. Finally, the results suggest that the performance of FLTs partially depends on system/benchmark characteristics, in addition to the FLTs themselves.

Background: The silent transmission of COVID-19 has led to an exponential growth of fatal infections. With over 4 million deaths worldwide, the need to control and stem transmission has never been more critical. New COVID-19 vaccines offer hope. However, administration timelines, long-term protection, and effectiveness against potential variants are still unknown. In this context, contact tracing and digital contact tracing apps (CTAs) continue to offer a mechanism to help contain transmission, keep people safe, and help kickstart economies. However, CTAs must address a wide range of often conflicting concerns, which make their development/evolution complex. For example, the app must preserve citizens’ privacy while gleaning their close contacts and as much epidemiological information as possible. Objective: In this study, we derived a compare-and-contrast evaluative framework for CTAs that integrates and expands upon existing works in this domain, with a particular focus on citizen adoption; we call this framework the Citizen-Focused Compare-and-Contrast Evaluation Framework (C3EF) for CTAs. Methods: The framework was derived using an iterative approach. First, we reviewed the literature on CTAs and mobile health app evaluations, from which we derived a preliminary set of attributes and organizing pillars. These attributes and the probing questions that we formulated were iteratively validated, augmented, and refined by applying the provisional framework against a selection of CTAs. Each framework pillar was then subjected to internal cross-team scrutiny, where domain experts cross-checked sufficiency, relevancy, specificity, and nonredundancy of the attributes, and their organization in pillars. The consolidated framework was further validated on the selected CTAs to create a finalized version of C3EF for CTAs, which we offer in this paper. Results: The final framework presents seven pillars exploring issues related to CTA design, adoption, and use: (General) Characteristics, Usability, Data Protection, Effectiveness, Transparency, Technical Performance, and Citizen Autonomy. The pillars encompass attributes, subattributes, and a set of illustrative questions (with associated example answers) to support app design, evaluation, and evolution. An online version of the framework has been made available to developers, health authorities, and others interested in assessing CTAs. Conclusions: Our CTA framework provides a holistic compare-and-contrast tool that supports the work of decision-makers in the development and evolution of CTAs for citizens. This framework supports reflection on design decisions to better understand and optimize the design compromises in play when evolving current CTAs for increased public adoption. We intend this framework to serve as a foundation for other researchers to build on and extend as the technology matures and new CTAs become available.

Feature Location (FL) is a core software maintenance activity that aims to locate observable functionalities in the source code. Given its key role in software change, a vast array of Feature Location Techniques (FLTs) have been proposed but, as more and more FLTs are introduced, the selection of an appropriate FLT is an increasingly difficult problem. One consideration is the characteristics of the features being sought. For example, in the code associated with the feature, programmers may have named identifiers consistently, and with meaningful naming conventions, or not, and this may impact on the suitability of different FLTs. The suggestion that such characteristics matter has implicit support in the literature: An analysis of existing FLT empirical studies reveals that the system under study can often have a stronger impact on FLT performance than differing FLTs themselves. To understand this interaction between feature characteristics and FLTs better, this paper proposes a suite of feature-characteristic metrics that are postulated to control FLTs’ performance, holistically across FLTs and impacting on individual FLTs to different degrees. To evaluate the suite, a controlled experiment is performed, using 878 features, to probe the relationship between the metrics and the performance of four FTL techniques: three commonly-used techniques and one state-of-the-art technique. The evaluation is performed using four commonly used evaluation measures and extended by employing 41 other established source-code metrics as extraneous variables. Results of the empirical evaluation suggest that the feature-metric suite presented impacts FLT performance holistically, and impacts different FLTs to different degrees. Thus, this paper moves towards the more standard selection of appropriate FLTs, with respect to the prominent feature characteristics in the software systems under study, and more rigorous consideration of the features selected to compare FLTs.