Enforcing public data archiving policies in academic publishing: A study of ecology journals

To improve the quality and efficiency of research, groups within the scientific community seek to exploit the value of data sharing. Funders, institutions, and specialist organizations are developing and implementing strategies to encourage or mandate data sharing within and across disciplines, with varying degrees of success. Academic journals in ecology and evolution have adopted several types of public data archiving policies requiring authors to make data underlying scholarly manuscripts freely available. Yet anecdotes from the community and studies evaluating data availability suggest that these policies have not obtained the desired effects, both in terms of quantity and quality of available datasets. We conducted a qualitative, interview-based study with journal editorial staff and other stakeholders in the academic publishing process to examine how journals enforce data archiving policies. We specifically sought to establish who editors and other stakeholders perceive as responsible for ensuring data completeness and quality in the peer review process. Our analysis revealed little consensus with regard to how data archiving policies should be enforced and who should hold authors accountable for dataset submissions. Themes in interviewee responses included hopefulness that reviewers would take the initiative to review datasets and trust in authors to ensure the completeness and quality of their datasets. We highlight problematic aspects of these thematic responses and offer potential starting points for improvement of the public data archiving process.Comment: 35 pages, 1 figure, 1 tabl

Refactoring Practices in the Context of Modern Code Review: An Industrial Case Study at Xerox

Modern code review is a common and essential 2 practice employed in both industrial and open-source projects 3 to improve software quality, share knowledge, and ensure con4 formance with coding standards. During code review, developers 5 may inspect and discuss various changes including refactoring 6 activities before merging code changes in the code base. To date, 7 code review has been extensively studied to explore its general 8 challenges, best practices and outcomes, and socio-technical 9 aspects. However, little is known about how refactoring activities 10 are being reviewed, perceived, and practiced. 11 This study aims to reveal insights into how reviewers develop 12 a decision about accepting or rejecting a submitted refactoring 13 request, and what makes such review challenging. We present an 14 industrial case study with 24 professional developers at Xerox. 15 Particularly, we study the motivations, documentation practices, 16 challenges, verification, and implications of refactoring activities 17 during code review. 18 Our study delivers several important findings. Our results 19 report the lack of a proper procedure to follow by developers 20 when documenting their refactorings for review. Our survey 21 with reviewers has also revealed several difficulties related to 22 understanding the refactoring intent and implications on the 23 functional and non-functional aspects of the software. In light of 24 our findings, we recommended a procedure to properly document 25 refactoring activities, as part of our survey feedback

Victims' rights in criminal trials: prospects for participation

Victims in common law jurisdictions have traditionally been unable to participate in criminal trials for a number of structural and normative reasons. They are widely perceived as ‘private parties’ whose role should be confined to that of witnesses; and participatory rights for such third parties are rejected as a threat to the objective and public nature of the criminal justice system. However, recent years have witnessed both a major shift in attitude in relation to the role of victims within the criminal justice system and a breakdown in the public / private divide in criminal justice discourse. This article considers the standing of the victim within the criminal trial against the backdrop of such changes, and examines the arguments for a more radical course of reform that would allow victims to actively participate in criminal hearings as they are able to do in many European jurisdictions

Open Science in Software Engineering

Open science describes the movement of making any research artefact available to the public and includes, but is not limited to, open access, open data, and open source. While open science is becoming generally accepted as a norm in other scientific disciplines, in software engineering, we are still struggling in adapting open science to the particularities of our discipline, rendering progress in our scientific community cumbersome. In this chapter, we reflect upon the essentials in open science for software engineering including what open science is, why we should engage in it, and how we should do it. We particularly draw from our experiences made as conference chairs implementing open science initiatives and as researchers actively engaging in open science to critically discuss challenges and pitfalls, and to address more advanced topics such as how and under which conditions to share preprints, what infrastructure and licence model to cover, or how do it within the limitations of different reviewing models, such as double-blind reviewing. Our hope is to help establishing a common ground and to contribute to make open science a norm also in software engineering.Comment: Camera-Ready Version of a Chapter published in the book on Contemporary Empirical Methods in Software Engineering; fixed layout issue with side-note

Explaining Explanation: An Empirical Study on Explanation in Code Reviews

Code review is an important process for quality assurance in software development. For an effective code review, the reviewers must explain their feedback to enable the authors of the code change to act on them. However, the explanation needs may differ among developers, who may require different types of explanations. It is therefore crucial to understand what kind of explanations reviewers usually use in code reviews. To the best of our knowledge, no study published to date has analyzed the types of explanations used in code review. In this study, we present the first analysis of explanations in useful code reviews. We extracted a set of code reviews based on their usefulness and labeled them based on whether they contained an explanation, a solution, or both a proposed solution and an explanation thereof. Based on our analysis, we found that a significant portion of the code review comments (46%) only include solutions without providing an explanation. We further investigated the remaining 54% of code review comments containing an explanation and conducted an open card sorting to categorize the reviewers' explanations. We distilled seven distinct categories of explanations based on the expression forms developers used. Then, we utilize large language models, specifically ChatGPT, to assist developers in getting a code review explanation that suits their preferences. Specifically, we created prompts to transform a code review explanation into a specific type of explanation. Our evaluation results show that ChatGPT correctly generated the specified type of explanation in 88/90 cases and that 89/90 of the cases have the correct explanation. Overall, our study provides insights into the types of explanations that developers use in code review and showcases how ChatGPT can be leveraged during the code review process to generate a specific type of explanation

Pull request latency explained:an empirical overview

Pull request latency evaluation is an essential application of effort evaluation in the pull-based development scenario. It can help the reviewers sort the pull request queue, remind developers about the review processing time, speed up the review process and accelerate software development. There is a lack of work that systematically organizes the factors that affect pull request latency. Also, there is no related work discussing the differences and variations in characteristics in different scenarios and contexts. In this paper, we collected relevant factors through a literature review approach. Then we assessed their relative importance in five scenarios and six different contexts using the mixed-effects linear regression model. The most important factors differ in different scenarios. The length of the description is most important when pull requests are submitted. The existence of comments is most important when closing pull requests, using CI tools, and when the contributor and the integrator are different. When there exist comments, the latency of the first comment is the most important. Meanwhile, the influence of factors may change in different contexts. For example, the number of commits in a pull request has a more significant impact on pull request latency when closing than submitting due to changes in contributions brought about by the review process. Both human and bot comments are positively correlated with pull request latency. In contrast, the bot’s first comments are more strongly correlated with latency, but the number of comments is less correlated. Future research and tool implementation needs to consider the impact of different contexts. Researchers can conduct related studies based on our publicly available datasets and replication scripts

Developing an Intervention Toolbox for the Common Health Problems in the Workplace

Development of the Health ↔ Work Toolbox is described. The toolbox aims to reduce the workplace impact of common health problems (musculoskeletal, mental health, and stress complaints) by focusing on tackling work-relevant symptoms. Based on biopsychosocial principles this toolbox supplements current approaches by occupying the zone between primary prevention and healthcare. It provides a set of evidence-informed principles and processes (knowledge + tools) for tackling work-relevant common health problems. The toolbox comprises a proactive element aimed at empowering line managers to create good jobs, and a ‘just in time’ responsive element for supporting individuals struggling with a work-relevant health problem. The key intention is helping people with common health problems to maintain work participation. The extensive conceptual and practical development process, including a comprehensive evidence review, produced a functional prototype toolbox that is evidence based and flexible in its use. End-user feedback was mostly positive. Moving the prototype to a fully-fledged internet resource requires specialist design expertise. The Health ↔ Work Toolbox appears to have potential to contribute to the goal of augmenting existing primary prevention strategies and healthcare delivery by providing a more comprehensive workplace approach to constraining sickness absence

Code Review Practices for Refactoring Changes: An Empirical Study on OpenStack

Modern code review is a widely used technique employed in both industrial and open-source projects to improve software quality, share knowledge, and ensure adherence to coding standards and guidelines. During code review, developers may discuss refactoring activities before merging code changes in the code base. To date, code review has been extensively studied to explore its general challenges, best practices and outcomes, and socio-technical aspects. However, little is known about how refactoring is being reviewed and what developers care about when they review refactored code. Hence, in this work, we present a quantitative and qualitative study to understand what are the main criteria developers rely on to develop a decision about accepting or rejecting a submitted refactored code, and what makes this process challenging. Through a case study of 11,010 refactoring and non-refactoring reviews spread across OpenStack open-source projects, we find that refactoring-related code reviews take significantly longer to be resolved in terms of code review efforts. Moreover, upon performing a thematic analysis on a significant sample of the refactoring code review discussions, we built a comprehensive taxonomy consisting of 28 refactoring review criteria. We envision our findings reaffirming the necessity of developing accurate and efficient tools and techniques that can assist developers in the review process in the presence of refactorings