Search

Peer code review is a widely practiced software engineering process in which software developers collaboratively evaluate and improve source code quality. Whether developers can perform good reviews depends on whether they have sufficient competence and experience. However, the knowledge of what competencies developers need to execute code review is currently limited, thus hindering, for example, the creation of effective support tools and training strategies. To address this gap, we firstly identified 27 competencies relevant to performing code review through expert validation. Later, we conducted an online survey with 105 reviewers to rank these competencies along four dimensions: frequency of usage, importance, proficiency, and desire of reviewers to improve in that competency. The survey shows that technical competencies are considered essential to performing reviews and that respondents feel generally confident in their technical proficiency. Moreover, reviewers feel less confident in how to communicate clearly and give constructive feedback - competencies they consider like-wise an essential part of reviewing. Therefore, research and education should focus in more detail on how to support and develop reviewers' potential to communicate effectively during reviews. In the paper, we also discuss further implications for training, code review performance assessment, and reviewers of different experience level. Data and materials: https://doi.org/10.5281/zenodo.7401313

Emotions are known to impact cognitive skills, thus influencing job performance. This is also true for software development, which requires creativity and problem-solving abilities. In this paper, we report the results of a field study involving professional developers from five different companies. We provide empirical evidence that a link exists between emotions and perceived productivity at the workplace. Furthermore, we present a taxonomy of triggers for developers' positive and negative emotions, based on the qualitative analysis of participants' self-reported answers collected through daily experience sampling. Finally, we experiment with a minimal set of non-invasive biometric sensors that we use as input for emotion detection. We found that positive emotional valence, neutral arousal, and high dominance are prevalent. We also found a positive correlation between emotional valence and perceived productivity, with a stronger correlation in the afternoon. Both social and individual breaks emerge as useful for restoring a positive mood. Furthermore, we found that a minimum set of non-invasive biometric sensors can be used as a predictor for emotions, provided that training is performed on an individual basis. While promising, our classifier performance is not yet robust enough for practical usage. Further data collection is required to strengthen the classifier, by also implementing individual fine-tuning of emotion models.

Supplementary Methods, Tables, and Figures

Purpose:Clear cell ovarian carcinoma (CCOC) is an aggressive disease that often demonstrates resistance to standard chemotherapies. Approximately 25% of patients with CCOC show a strong APOBEC mutation signature. Here, we determine which APOBEC3 enzymes are expressed in CCOC, establish clinical correlates, and identify a new biomarker for detection and intervention.Experimental Designs:APOBEC3 expression was analyzed by IHC and qRT-PCR in a pilot set of CCOC specimens (n = 9 tumors). The IHC analysis of APOBEC3B was extended to a larger cohort to identify clinical correlates (n = 48). Dose-response experiments with platinum-based drugs in CCOC cell lines and carboplatin treatment of patient-derived xenografts (PDXs) were done to address mechanistic linkages.Results:One DNA deaminase, APOBEC3B, is overexpressed in a formidable subset of CCOC tumors and is low or absent in normal ovarian and fallopian tube epithelial tissues. High APOBEC3B expression associates with improved progression-free survival (P = 0.026) and moderately with overall survival (P = 0.057). Cell-based studies link APOBEC3B activity and subsequent uracil processing to sensitivity to cisplatin and carboplatin. PDX studies extend this mechanistic relationship to CCOC tissues.Conclusions:These studies demonstrate that APOBEC3B is overexpressed in a subset of CCOC and, contrary to initial expectations, associated with improved (not worse) clinical outcomes. A likely molecular explanation is that APOBEC3B-induced DNA damage sensitizes cells to additional genotoxic stress by cisplatin. Thus, APOBEC3B is a molecular determinant and a candidate predictive biomarker of the therapeutic response to platinum-based chemotherapy. These findings may have broader translational relevance, as APOBEC3B is overexpressed in many different cancer types.

Context: Execution logs capture the run-time behavior of software systems. To assist developers in their maintenance tasks, many studies have proposed tools to analyze execution information from logs. However, it is as yet unknown how industry developers use logs in embedded software engineering. Objective: In this study, we aim to understand how developers use logs in an embedded software engineering context. Specifically, we would like to gain insights into the type of logs developers analyze, the purposes for which developers analyze logs, the information developers need from logs and their expectation on tool support. Method: In order to achieve the aim, we conducted these interview studies. First, we interviewed 25 software developers from ASML, which is a leading company in developing lithography machines. This exploratory case study provides the preliminary findings. Next, we validated and refined our findings by conducting a replication study. We involved 14 interviewees from four companies who have different software engineering roles in their daily work. Results: As the result of our first study, we compile a preliminary taxonomy which consists of four types of logs used by developers in practice, 18 purposes of using logs, 13 types of information developers search in logs, 13 challenges faced by developers in log analysis and three suggestions for tool support provided by developers. This taxonomy is refined in the replication study with three additional purposes, one additional information need, four additional challenges and three additional suggestions of tool support. In addition, with these two studies, we observed that text-based editors and self-made scripts are commonly used when it comes to tooling in log analysis practice. As indicated by the interviewees, the development of automatic analysis tools is hindered by the quality of the logs, which further suggests several challenges in log instrumentation and management. Conclusions: Based on our study, we provide suggestions for practitioners on logging practices. We provide implications for tool builders on how to further improve tools based on existing techniques. Finally, we suggest some research directions and studies for researchers to further study software logging.

The intersection of ageism and sexism can create a hostile environment for veteran software developers belonging to marginalized genders. In this study, we conducted 14 interviews to examine the experiences of people at this intersection, primarily women, in order to discover the strategies they employed in order to successfully remain in the field. We identified 283 codes, which fell into three main categories: Strategies, Experiences, and Perception. Several strategies we identified, such as (Deliberately) Not Trying to Look Younger, were not previously described in the software engineering literature. We found that, in some companies, older women developers are recognized as having particular value, further strengthening the known benefits of diversity in the workforce. Based on the experiences and strategies, we suggest organizations employing software developers to consider the benefits of hiring veteran women software developers. For example, companies can draw upon the life experiences of older women developers in order to better understand the needs of customers from a similar demographic. While we recognize that many of the strategies employed by our study participants are a response to systemic issues, we still consider that, in the short-term, there is benefit in describing these strategies for developers who are experiencing such issues today., Comment: Proceedings of the 45th International Conference on Software Engineering (ICSE 2023), 13 pages, 1 figure, 5 tables

Funding: This work is partly funded by NSF award OAC-1839900. This material is based upon work supported by the U.S. Department of Energy, Office of Science, under contract number DE-AC02-06CH11357. libEnsemble was developed as part of the Exascale Computing Project (17-SC-20-SC), a collaborative effort of the U.S. Department of Energy Office of Science and the National Nuclear Security Administration. This research used resources of the OLCF at ORNL, which is supported by the Office of Science of the U.S. DOE under Contract No. DE-AC05-00OR22725. Lightning talks of the Workflows in Support of Large-Scale Science (WORKS) workshop are a venue where the workflow community (researchers, developers, and users) can discuss work in progress, emerging technologies and frameworks, and training and education materials. This paper summarizes the WORKS 2022 lightning talks, which cover five broad topics: data integrity of scientific workflows; a machine learning-based recommendation system; a Python toolkit for running dynamic ensembles of simulations; a cross-platform, high-performance computing utility for processing shell commands; and a meta(data) framework for reproducing hybrid workflows. Postprint

Code review is a popular software engineering practice. Success of code reviews can be threatened by confusion experienced by code reviewers. For instance, on the one hand, research has studied the reasons for confusion in code reviews, and on the other hand, it also has analyzed source code patterns, so called "atoms of confusion", that have been shown to lead to misunderstanding in the lab setting. However, to the best of our knowledge, there is no research which tried to investigate the possible cause and effect relationship between atoms of confusion and confusion in code reviews. Another important aspect still not studied is how those atoms of confusion evolve across pull requests. In this emerging results paper, we report an exploratory case study to provide a deeper understanding of atoms of confusion, more specifically, whether atoms of confusion are related to confusion in code reviews and how they persist across pull requests. With the help of an existing tool for the detection of atoms of confusion, and a manual analysis of code reviews comments, we observed that statistical analysis did not show any relationship between atoms of confusion and presence of confusion comments in code reviews. Additionally, we found evidence that atoms of confusion are mostly not being removed in pull requests. Based on the results, we formulate hypotheses on atoms of confusion in the code review context, that should be confirmed or rejected by future studies.

Purpose Exposure to high doses of ionizing radiation can result in hematopoietic acute radiation syndrome (H-ARS) and delayed effects of acute radiation exposure (DEARE). There is no radiation medical countermeasure approved by the U.S. Food and Drug Administration which can be used prior to radiation exposure to protect exposed individuals. Different formulations containing synthetic genistein (BIO 300) are being developed to counter the harmful effects of radiation exposure. Materials and methods We investigated the efficacy of a BIO 300 Oral Powder (OP) formulation as a prophylactic radiation medical countermeasure against a lethal dose of cobalt-60 gamma-radiation in CD2F1 male mice while comparing to other formulations of BIO 300 and Neulasta (PEGylated filgrastim), a standard of care drug for H-ARS. Results BIO 300 OP provided significant radioprotection against ionizing radiation in mice when administered twice per day for six days prior to total-body radiation exposure. Its radioprotective efficacy in the murine model was comparable to the efficacy of a single subcutaneous (sc) injection of Neulasta administered after total-body radiation exposure. Conclusions Our results demonstrate that BIO 300 OP, which can be administered orally, is a promising prophylactic radiation countermeasure for H-ARS.

Self-Admitted Technical Debt (SATD) consists of annotations—typically, but not only, source code comments—pointing out incomplete features, maintainability problems, or, in general, portions of a program not-ready yet. The way a SATD comment is written, and specifically its polarity, may be a proxy indicator of the severity of the problem and, to some extent, of the priority with which it should be addressed. In this paper, we study the relationship between different types of SATD comments in source code and their polarity, to understand in which circumstances (and why) developers use negative or rather neutral comments to highlight an SATD. To address this goal, we combine a manual analysis of 1038 SATD comments from a curated dataset with a survey involving 46 professional developers. First of all, we categorize SATD content into its types. Then, we study the extent to which developers express negative sentiment in different types of SATD as a proxy for priority, and whether they believe this can be considered as an acceptable practice. Finally, we look at whether such annotations contain additional details such as bug references and developers’ names/initials. Results of the study indicate that SATD comments are mainly used for annotating poor implementation choices ($\simeq $≃41%) and partially implemented functionality ($\simeq $≃22%). The latter may depend from “waiting” for other features being implemented, and this makes SATD comments more negatives than in other cases. Around 30% of the survey respondents agree on using/interpreting negative sentiment as a proxy for priority, while 50% of them indicate that it would be better to discuss SATD on issue trackers and not in the source code. However, while our study indicates that open-source developers use links to external systems, such as bug identifiers, to annotate high-priority SATD, better tool support is required for SATD management.

A pharmaceutical formulation of genistein, produced as an amorphous solid dispersion by hot melt extrusion (genistein HME), has been developed that can be administered prophylactically to improve outcomes and survival following radiation exposure. Here, genistein HME was evaluated in a phase 1, open-label, single ascending dose (SAD) and multiple single dose (MSD) study enrolling 34 healthy volunteers. In the SAD study, participants were administered a single dose (500, 1000, 2000, or 3000 mg) and in the MSD study, participants were administered a single daily dose for six consecutive days (3000 mg/day). The overall adverse event profile and pharmacokinetics of genistein HME were determined. Additionally, biomarkers of genistein HME were evaluated by profiling whole blood for changes in gene expression by RNA sequencing. Genistein HME was found to be safe at doses up to 3000 mg. Most toxicities were mild to moderate gastrointestinal events, and no dose-limiting toxicities were reported. The maximum tolerated dose was not determined and the no observable adverse effect level was 500 mg. Genistein HME bioavailability greatly increased between the 2000 mg and 3000 mg doses. RNA sequencing analysis revealed that the majority of drug-related changes in gene expression occurred 8-12 hours after the sixth dose in the MSD study. Based on these results, the putative effective dose in humans is 3000 mg.

Background Bacterial vaginosis (BV) treatment failures and recurrences are common. To identify features associated with treatment response, we compared vaginal microbiota and host ectocervical transcriptome before and after oral metronidazole therapy. Methods Women with BV (Bronx, New York and Thika, Kenya) received 7 days of oral metronidazole at enrollment (day 0) and underwent genital tract sampling of microbiome (16S ribosomal RNA gene sequencing), transcriptome (RNAseq), and immune mediator concentrations on day 0, 15, and 35. Results Bronx participants were more likely than Thika participants to clinically respond to metronidazole (19/20 vs 10/18, respectively, P = .0067) and by changes in microbiota composition and diversity. After dichotomizing the cohort into responders and nonresponders by change in α-diversity between day 35 and day 0, we identified that transcription differences associated with chemokine signaling (q = 0.002) and immune system process (q = 2.5 × 10–8) that differentiated responders from nonresponders were present at enrollment. Responders had significantly lower levels of CXCL9 in cervicovaginal lavage on day 0 (P < .007), and concentrations of CXCL9, CXCL10, and monocyte chemoattractant protein 1 increased significantly between day 0 and day 35 in responders vs nonresponders. Conclusions Response to metronidazole is characterized by significant changes in chemokines and related transcripts, suggesting that treatments that promote these pathways may prove beneficial.

The development of systems following model-driven engineering can include models from different domains. For example, to develop a mechatronic component one might need to combine expertise about mechanics, electronics, and software. Although these models belong to different domains, the changes in one model can affect other models causing inconsistencies in the entire system. Only few tools, however, support management of models from different domains. Indeed, these models are created using different modeling notations and it is not plausible to use a multitude of parsers geared toward each and every modeling notation. Therefore, to ensure maintenance of multi-domain systems, we need a uniform approach that would be independent from the peculiarities of the notation. Notation independence implies that such a uniform approach can only be based on elements commonly present in models of different domains, i.e., text, boxes, and lines. In this study, we investigate the suitability of optical character recognition (OCR) as a basis for such a uniformed approach. We select graphical models from various domains that typically combine textual and graphical elements. We start by analyzing the performance of Google Cloud Vision and Microsoft Cognitive Services, two off-the-shelf OCR services. Google Cloud Vision performed better than Microsoft Cognitive Services being able to detect text of 70% of model elements. Errors made by Google Cloud Vision are due to absence of support for text common in engineering formulas, e.g., Greek letters, equations, and subscripts. We identified the multi-line text error as one of the main issues of using OCR to recognize textual elements in models from different domains. This error happens when OCR misinterprets one textual element as two separate elements. To address the multi-line text error, we build Xamã on top of Google Cloud Vision. Xamã includes two approaches to identify whether the elements are positioned on a single line or multiple lines, and merge those identified as positioned on multiples lines. With and without shape detection, Xamã correctly identified 956 and 905 elements, respectively, out of 1171. Additionally, we compared the accuracy of Xamã and state-of-the-art tool img2UML, and we observe that Xamã outperformed img2UML in both precision and recall, being able to recognize 433 out of 614 textual elements as opposed to 171 by img2UML.

The “Practioners' Digest” department in this issue of IEEE Software covers two topics: the behavioral science of software engineering and diversity in software engineering (this issue’s theme) and includes papers from the 42nd International Conference on Software Engineering (ICSE20), 2019 IEEE International Conference on Software Maintenance and Evolution (ICSME19), 13th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE20), Empirical Software Engineering and Measurement 2020 (ESEM20), and Association for Computing Machinery Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE20). Feedback or suggestions are welcome. In addition, if you try or adopt any of the practices included in this article, please send me and the authors of the paper(s) a note about your experiences.

The ‘Practitioners’ Digest’ department in this issue of IEEE Software includes papers from the 2021 International Conference on Software Engineering (ICSE). A paper entitled, ‘Siri, Write the Next Method’ by Fengcai Wen and colleagues, expands upon the long-standing concept of code completion to include the automation of function signatures and function bodies. Code completion, an important support mechanism used by professional developers, helps complete method names, suggests the signature of an application programming interface function, or simply formats code. FeaRS, the authors’ new tool, takes that concept one step further by writing entire function signatures and function bodies based on the analysis of 2.5 million commits of existing functions in various open source projects. Another paper entitled ‘A Case Study of Onboarding in Software Teams: Tasks and Strategies’, by An Ju and colleagues, reports on the results of a study with 32 developers and 15 managers involved in the onboarding process.

BIO 300, a pharmaceutical formulation of genistein, is being developed as a radiation countermeasure to treat hematopoietic acute radiation syndrome (H-ARS) and the delayed effects of acute radiation exposure (DEARE). Several studies have affirmed its safety and efficacy in alleviating the damaging effects of ionizing radiation. However, dose optimization of any drug has always been an important area of research because unnecessarily high drug doses may result in serious complications. In this study, we assessed the pharmacokinetics (PK) and metabolic profiles of two different doses of a novel solid-dosage formulation of BIO 300 (BIO 300 Oral Powder; 100 mg/kg and 200 mg/kg), when administered orally to nonhuman primates (NHPs). While the Tmax values of both doses remained the same, the area under the curve at 48 h (AUC0-48) was tripled by doubling the dose. Additionally, we monitored serum samples for global metabolomic/lipidomic changes using high resolution mass spectrometry followed by functional pathway analysis prior to and at various time points up to 48 h post drug administration. Interestingly, the metabolomic profiles of sera from NHPs that received the lower dose demonstrated a transient perturbation in numerous metabolites between the 4 and 12 h time points. Eventually, the metabolite abundance reverted to near-normal by 48 h. These study results are consistent with our previous studies focused on the PK and metabolomic analysis for parenteral and oral aqueous nanosuspension formulations of BIO 300. This study affirms that administration of a single dose of up to 200 mg/kg of BIO 300 Oral Powder is safe in NHPs and conferred no metabolomic-mediated safety features.

Context: Tangled commits are changes to software that address multiple concerns at once. For researchers interested in bugs, tangled commits mean that they actually study not only bugs, but also other concerns irrelevant for the study of bugs. Objective: We want to improve our understanding of the prevalence of tangling and the types of changes that are tangled within bug fixing commits. Methods: We use a crowd sourcing approach for manual labeling to validate which changes contribute to bug fixes for each line in bug fixing commits. Each line is labeled by four participants. If at least three participants agree on the same label, we have consensus. Results: We estimate that between 17% and 32% of all changes in bug fixing commits modify the source code to fix the underlying problem. However, when we only consider changes to the production code files this ratio increases to 66% to 87%. We find that about 11% of lines are hard to label leading to active disagreements between participants. Due to confirmed tangling and the uncertainty in our data, we estimate that 3% to 47% of data is noisy without manual untangling, depending on the use case. Conclusion: Tangled commits have a high prevalence in bug fixes and can lead to a large amount of noise in the data. Prior research indicates that this noise may alter results. As researchers, we should be skeptics and assume that unvalidated data is likely very noisy, until proven otherwise., Status: Accepted at Empirical Software Engineering

Open-Source Software (OSS) projects have adopted various automations for repetitive tasks in recent years. One common type of automation in OSS is bots. In this exploratory case study, we seek to understand how the adoption of one particular bot (ASFBot) by the Apache Software Foundation (ASF) impacts the discussions in the issue-trackers of these projects. We use the SmartShark dataset to investigate whether the ASFBot affects (i) human comments mentioning pull requests and fixes in issue comments and (ii) the general human comment rate on issues. We apply a regression discontinuity design (RDD) on nine ASF projects that have been active both before and after the ASFBot adoption.Our results indicate (i) an immediate decrease in the number of median comments mentioning pull requests and fixes after the bot adoption, but the trend of a monthly decrease in this comment count is reversed, and (ii) no effect in the number of human comments after the bot adoption. We make an effort to gather first insights in understanding the impact of adopting the ASFBot on the commenting behavior of developers who are working on ASF projects.

Code reading is one of the most frequent activities in software maintenance. Such an activity aims at acquiring information from the code and, thus, it is a prerequisite for program comprehension: developers need to read the source code they are going to modify before implementing changes. As the code changes, so does its readability; however, it is not clear yet how code readability changes during software evolution. To understand how code readability changes when software evolves, we studied the history of 25 open source systems. We modeled code readability evolution by defining four states in which a file can be at a certain point of time (non-existing, other-name, readable, and unreadable). We used the data gathered to infer the probability of transitioning from one state to another one. In addition, we also manually checked a significant sample of transitions to compute the performance of the state-of-the-art readability prediction model we used to calculate the transition probabilities. With this manual analysis, we found that the tool correctly classifies all the transitions in the majority of the cases, even if there is a loss of accuracy compared to the single-version readability estimation. Our results show that most of the source code files are created readable. Moreover, we observed that only a minority of the commits change the readability state. Finally, we manually carried out qualitative analysis to understand what makes code unreadable and what developers do to prevent this. Using our results we propose some guidelines (i) to reduce the risk of code readability erosion and (ii) to promote best practices that make code readable.

When identifying the origin of software bugs, many studies assume that “a bug was introduced by the lines of code that were modified to fix it”. However, this assumption does not always hold and at least in some cases, these modified lines are not responsible for introducing the bug. For example, when the bug was caused by a change in an external API. The lack of empirical evidence makes it impossible to assess how important these cases are and therefore, to which extent the assumption is valid. To advance in this direction, and better understand how bugs “are born”, we propose a model for defining criteria to identify the first snapshot of an evolving software system that exhibits a bug. This model, based on the perfect test idea, decides whether a bug is observed after a change to the software. Furthermore, we studied the model’s criteria by carefully analyzing how 116 bugs were introduced in two different open source software projects. The manual analysis helped classify the root cause of those bugs and created manually curated datasets with bug-introducing changes and with bugs that were not introduced by any change in the source code. Finally, we used these datasets to evaluate the performance of four existing SZZ-based algorithms for detecting bug-introducing changes. We found that SZZ-based algorithms are not very accurate, especially when multiple commits are found; the F-Score varies from 0.44 to 0.77, while the percentage of true positives does not exceed 63%. Our results show empirical evidence that the prevalent assumption, “a bug was introduced by the lines of code that were modified to fix it”, is just one case of how bugs are introduced in a software system. Finding what introduced a bug is not trivial: bugs can be introduced by the developers and be in the code, or be created irrespective of the code. Thus, further research towards a better understanding of the origin of bugs in software projects could help to improve design integration tests and to design other procedures to make software development more robust.

Given growing attention to gender diversity in software development teams, we asked practitioners if it was a useful tool to mitigate undesirable communication patterns. While many participants didn't consider gender diversity useful in this context, those who did were motivated by their own professional experience.

Context: Relationships within open-source software ecosystems (OSSECO) emerge from collaborations within an ecosystem. Power relations are present in this context whenever an entity has the power of making other entities act as it wants them to act. Therefore, these power relations could affect collaboration within an OSSECO. Objective: This research aims at investigating power relations and providing an understanding of them in OSSECO. A conceptual model will be refined and will represent the power relations and their dynamics. Method: A systematic mapping study was conducted to gather knowledge about power relations from previous studies, and a survey research, considering this knowledge, was conducted with randomly selected npm OSSECO community members to evaluate that knowledge. Next, interviews with selected ecosystem community members will be conducted to identify the types of power relations and their dynamics within an OSSECO. Based on the results from the previous phases, a conceptual model to represent power relations and their dynamics in OSSECO will be refined. Results: The literature review and the survey research with the npm OSSECO community show that, as expected, power relations are present and affect relationships and interactions within an OSSECO. Hierarchy and financial rewards seem to be related to the power relations within the OSSECO. Implications: Identifying power relations that might be present within an OSSECO would enable those who study or are members of the ecosystem's community to understand previous movements and predict future decisions based on the power relations present in their OSSECO.

This is the replication package for the paper "Opinion Mining for Software Development: A Systematic Literature Review", co-authored by Bin Lin, Nathan Cassee, Alexander Serebrenik, Gabriele Bavota, Nicole Novielli, and Michele Lanza. Please open the "index.html" file to navigate. For easy viewing, the replication package is also hosted onhttps://binlin.info/om4sd/.

In this experience report we present SAW-BOT, a bot proposing fixes for static analysis warnings. The bot has been evaluated with five professional software developers by means of a Wizard of Oz experiment, semi-structured interviews and the mTAM questionnaire. We have observed that developers prefer GitHub suggestions to two baseline operation modes. Our study indicates that GitHub suggestions are a viable mechanism for implementing bots proposing fixes for static analysis warnings.

BIO 300, a suspension of synthetic genistein nanoparticles, is being developed for mitigating the delayed effects of acute radiation exposure (DEARE). The purpose of the current study was to characterize the pharmacokinetic (PK) profile of BIO 300 administered as an oral or parenteral formulation 24 h after sham-irradiation, total-body irradiation (TBI) with 2.5-5.0% bone marrow sparing (TBI/BMx), or in nonirradiated sex-matched C57BL/6J mice and non-human primates (NHP). C57BL/6J mice were randomized to the following arms in two consecutive studies: sham-TBI [400 mg/kg, oral gavage (OG)], TBI/BM2.5 (400 mg/kg, OG), sham-TBI [200 mg/kg, subcutaneous (SC) injection], TBI/BM2.5 (200 mg/kg, SC), sham-TBI (100 mg/kg, SC), or nonirradiated [200 mg/kg, intramuscular (IM) injection]. The PK profile was also established in NHP exposed to TBI/BM5.0 (100 mg/kg, BID, OG). Genistein-aglycone serum concentrations were measured in all groups using a validated liquid chromatography-tandem mass spectrometry (LC-MS/MS) assay. The PK profile demonstrates 11% and 19% reductions in Cmax and AUC0-inf, respectively, among mice administered 400 mg/kg, OG, after TBI/BM2.5 compared to the sham-TBI control arm. Administration of 200 mg/kg SC in mice exposed to TBI/BM2.5 showed a 53% increase in AUC0-inf but a 28% reduction in Cmax compared to the sham-TBI mice. The relative bioavailability of the OG route compared to the SC and IM routes in mice was 9% and 7%, respectively. After the OG route, the dose-normalized AUC0-inf was 13.37 (ng.h/mL)/(mg/kg) in TBI/BM2.5 mice compared to 6.95 (ng.h/mL)/(mg/kg) in TBI/BM5.0 NHPs. Linear regression of apparent clearances and weights of mice and NHPs yielded an allometric coefficient of 1.06. Based on these data, the effect of TBI/BMx on BIO 300 PK is considered minimal. Future studies should use SC and IM routes to maximize drug exposure when administered postirradiation. The allometric coefficient is useful in predicting therapeutic drug dose regimens across species for drug approval under the FDA animal rule.

Execution logs capture the run-time behavior of software systems. To assist developers in their maintenance tasks, many studies have proposed tools to analyze execution information from logs. However, it is as yet unknown how industry developers analyze logs in embedded software engineering. In order to bridge the gap, we study how developers analyze logs by interviewing 25 software developers from ASML, which is a leading company in developing lithography machines. In particular, we explore the type of logs developers analyze, the purposes for which developers analyze logs, the information developers need from logs and their expectation on tool support. As the main contribution, we observed that the lack of domain knowledge, lack of familiarity with code base and software design, and presence of concurrency, raise major challenges in log analysis for such complex and multidisciplinary systems. Particularly, we observed that inspecting execution information at different levels of abstraction is useful to develop comprehension of such complex systems. However, obtaining the abstraction is difficult with current tools. Our study has several implications. The empirical evidence provided by our study implies the need to support log inspection and comparison with multiple levels of abstraction, categorize log differences, and recover links between different types of logs.

Self-Admitted Technical Debt (SATD) represents the admission, made through source code comments or other channels, of portions of a program being poorly implemented, containing provisional solutions or, in general, simply being not ready yet. To better understand developers’ habits in SATD annotation, and possibly support their exploitation in tool support, this paper provides an in-depth analysis of the content provided in SATD comments, and the expressed sentiment. We manually inspect and classify 1038 instances from an existing dataset, grouping them along a taxonomy composed of 41 categories (of which 9 top-level ones), identifying their sentiment, and the presence of external references such as author names or issue IDs. Results of our study indicate that (i) the SATD content is crosscutting along life-cycle dimensions identified in previous work, (ii) comments related to functional problems or on-hold SATD are generally more negative than poor implementation choices or partially implemented functionality, and (iii) despite observations from previous literature, only a minority of SATD comments leverage external references.

The topic of gender in software engineering received significant attention during the most recent International Conference on Software Engineering (ICSE). Papers related to gender appeared in the main research track, the Software Engineering in Society (SEIS) track, and the second Gender Equity (GE) workshop (https://sites.google.com/view/ge-icse2019). Three of the papers summarized in this column are coauthored by the column authors.

The OpenStack Foundation's goal is to “promote the global development,distribution and adoption of open infrastructure." As in many other open source communities, and in the technology industry as a whole, the OpenStack community experienced a lack of representation of females andunderrepresented minorities, a fact that should be supported with evidence. Intel and Bitergia have conducted an assessment of the current state of gender diversity within the community, examining both code and non-code contributions, including leadership, governance, and event representation, among other elements. In this paper, the authors summarize the results of this assessment and discuss the importance of data to increase awareness of the topic and later use those numbers to improve the diversity and inclusion within the OpenStack community. This is the first comprehensive analysis of the OpenStack gender diversity status and has opened the possibility to extend this to othercommunities.

This issue's article reports from the 40th International Conference on Software Engineering (ICSE 18) and the 17th International Conference on Software Reuse (ICSR 18). The ICSE papers focus on sociotechnical issues related to gender and sentiment or emotion. The ICSR paper focuses on safety-critical systems.

Software bots are used by Open Source Software (OSS) projects to streamline the code review process. Interfacing between developers and automated services, code review bots report continuous integration failures, code quality checks, and code coverage. However, the impact of such bots on maintenance tasks is still neglected. In this paper, we study how project maintainers experience code review bots. We surveyed 127 maintainers and asked about their expectations and perception of changes incurred by code review bots. Our findings reveal that the most frequent expectations include enhancing the feedback bots provide to developers, reducing the maintenance burden for developers, and enforcing code coverage. While maintainers report that bots satisfied their expectations, they also perceived unexpected effects, such as communication noise and newcomers' dropout. Based on these results, we provide a series of implications for bot developers, as well as insights for future research.

Static analysis tools are useful to detect common programming errors. However, they generate a large number of false positives. Postprocessing of these alarms using a model checker has been proposed to automatically eliminate false positives from them. To scale up the automated false positives elimination (AFPE), several techniques, e.g., program slicing, are used. However, these techniques increase the time taken by AFPE, and the increased time is a major concern during application of AFPE to alarms generated on large systems.To reduce the time taken by AFPE, we propose two techniques. The techniques achieve the reduction by identifying and skipping redundant calls to the slicer and model checker. The first technique is based on our observation that, (a) combination of application-level slicing, verification with incremental context, and the context-level slicing helps to eliminate more false positives; (b) however, doing so can result in redundant calls to the slicer. In this technique, we use data dependencies to compute these redundant calls. The second technique is based on our observation that (a) code partitioning is commonly used by static analysis tools to analyze very large systems, and (b) applying AFPE to alarms generated on partitioned-code can result in repeated calls to both the slicer and model checker. We use memoization to identify the repeated calls and skip them.The first technique is currently under evaluation. Our initial evaluation of the second technique indicates that it reduces AFPE time by up to 56%, with median reduction of 12.15%.

Software bots, which are widely adopted by Open Source Software (OSS) projects, support developers on several activities, including code review. However, as with any new technology adoption, bots may impact group dynamics. Since understanding and anticipating such effects is important for planning and management, we investigate how several activity indicators change after the adoption of a code review bot. We employed a regression discontinuity design on 1,194 software projects from GitHub. Our results indicate that the adoption of code review bots increases the number of monthly merged pull requests, decreases monthly non-merged pull requests, and decreases communication among developers. Practitioners and maintainers may leverage our results to understand, or even predict, bot effects on their projects’ social interactions.