Constructive Code Review: Managing the Impact of Interpersonal Conflicts in Practice

Code review is an activity where developers receive feedback on their code contributions from other developers. The frequent and potentially negative feedback developers receive makes code review prone to interpersonal conflicts. There is a consensus about such behavior being anti-social and leading to negative outcomes for the code, team, project, and even the company. However, these conflicts are a naturally occurring phenomenon that can lead to reaping the benefits of code review if managed well. Interpersonal conflicts in code review are not necessarily an issue to avoid, but rather to be managed. In this study, we survey developers in two companies - Adnovum - working predominantly on closed-source projects - and in Red Hat open source projects. Based on a set of 154 respondents, we have found that 77% of developers sometimes experience interpersonal conflicts in code review, even though mostly not very frequently. These conflicts pose some degree of a problem to 64% of developers. However, developers are rather successful in deriving constructive outcomes in the face of conflicts - 24% of developers report that conflicts have more positive than negative outcomes. While they are highly successful in deriving positive outcomes for code quality and maintainability, the motivation of developers and their communication and collaboration in a team has the most potential to be harmed by conflicts. The most effective strategy to have constructive rather than destructive conflicts is managing work effort and re-assigning tasks in the team to reduce stress in review. Data and materials: https://zenodo.org/records/10477537.


INTRODUCTION
In code reviews, developers evaluate their peers' code and offer feedback.This process not only helps in identifying technical issues but also promotes social benefits, such as improved team awareness and knowledge transfer among developers [2].
Obtaining insightful feedback is one of the main challenges in code reviews [31,33].A factor contributing to the difficulty is that this feedback can be negative, potentially inconsiderate, unfair, and even destructive [19,22].This suggests that code review is susceptible to disagreements, interpersonal conflicts, and other communication issues among developers [41].Interpersonal conflicts in code review, as defined in this study, are experiencing negative emotions stemming from perceived disagreements with other participants during the review process [23,41].
Researchers have investigated several issues in code review communication that contribute to the destructiveness of the feedback, such as toxicity [34], profanity [39], or incivility [16].For example, the Linux Kernel mailing list has raised attention due to particularly challenging communication [5,16]: "... anybody who thinks that the above is (a) legible (b) efficient (even with the magical compiler support) (c) particularly safe is just incompetent and out to lunch.The above code is sh*t, and it generates shit code.It looks bad, and there's no reason for it." [40] Toxicity is very explicit and, therefore, easy to see in the comments: 10% of threads in the mailing list contain an argument but less than 0.5% contain toxic language [16].However, communication can be disrupted in more subtle ways.For example, developers report that conflicts can be characterized by a stagnating discussion, where developers are unable to move the pull-request (PR) towards a successful merge -for example, because of developers ignoring each others' inputs [41] or because of reviewers pushing back on the acceptance of their code review changes [15].
Software engineering researchers pointed out that interpersonal conflicts are antisocial and lead to negative repercussions within the teams or communities they affect [37].Such conflicts can deteriorate code quality, hamper developer motivation and productivity, and undermine team collaboration [11,13,15,16,24,26,41].Yet, in our previous work [41], we collected qualitative evidence indicating that developers employ a variety of strategies to offset these conflicts and that, through these measures, they can reach constructive and fruitful code review outcomes.
Despite the aforementioned evidence (e.g., [16,41]), we lack a clear understanding of how common conflicts are in code reviews with respect to their inherently subjective and potentially hidden nature [30,41] and how severe they are for practitioners.Conflicts also can be constructive by bringing change and solutions to problematic situations [10].In the present study, the goal is to deepen evidence-based comprehension of interpersonal conflicts in code reviews -the destructive and the constructive ones.
Drawing inspiration from our prior qualitative research on the subject [41], we adopt a psychological lens to discern: 1) the prevalence and severity of conflicts during code reviews, 2) the negative but also positive consequences of these conflicts that developers perceive in real-world scenarios, and 3) the conflict management strategies that correlate with more constructive conflicts.To this aim, we gathered survey data from two companies: Adnovum -a closed-source company, and Red Hat -a company with a range of open-source projects.Our findings revealed that developers frequently encounter conflicts.For a substantial portion of the respondents, conflicts do not pose any issue.Yet, they can occasionally lead to severe disruptions to a developer's work.Notably, developers actively seek constructive resolutions in the face of these conflicts.While they often succeed in deriving the technical benefits of the review, their motivation, communication, and collaboration are most susceptible to the negative impact of conflicts.To foster a more positive code review environment, developers can offer more explanations and tailor their communication style to individual colleagues.Teams can support the quality of the code review communication especially by strategically managing task assignments and developers' work efforts.
The replication package is available in the online material [36].

BACKGROUND
Communication issues in code reviews and Software Engineering have received extensive research attention.In the following section, we extend the previous work by unifying the interpretation of these efforts under the concept of interpersonal conflict [23].First, we showcase that many of the related concepts are part of the overarching issue of communication quality in code reviews and represent only the explicit behavior that can accompany a conflict.We discuss the gap in methodology that is created by this imbalance.Further, we discuss the difference between the destructive and constructive outcomes of conflicts and available conflict management strategies addressed in the literature.

Interpersonal conflicts in code reviews
Developers report conflicts as a common and expected phenomenon in code review [41].According to Hartwick and Barki [23], conflict occurs when there is a behavioral interference between the conflict parties (such as pushback [15] or aggressive language [34,38]) who have a disagreement based on divergent goals, opinions, values or believes (like demonstrated in the Linux Kernel mailing list in Ferreira et al. [16]) accompanied by negative emotions (as laid out by Egelman et al. [15] when understanding pushback on changes).
In the literature, we can find conflicts defined by only one of those components.Yet, according to Hartwick and Barki [23], a situation can only be termed as a conflict when three components coexist: the experience of negative emotions, a present disagreement, and an obstruction in achieving one's objectives.Using this definition, interpersonal conflicts become a deeply subjective concept.This means that we cannot assume developers are in conflict without delving into whether they genuinely find the situation bothersome or detrimental to their work.While code reviews often abound with misunderstandings [2] and confusions [14], these do not automatically equate to the negative emotions that can foster a contentious and toxic communication environment.
Up to now, software engineering often relies on approaching conflicts through investigating the observable extremities (only 0.5% of comments actually contain offensive language [5]) of human communication such as profanities [39], incivility [16] or toxicity [34], identifying them through the textual features of communication.However, some research recognizes a distinction between overtly hostile content and mere misunderstandings or technical disagreements [25].Importantly, the presence of strong language in a discussion does not automatically signify conflict, especially if all involved parties are at ease with the communication style [41].
Similarly, even when developers experience conflicts, there can be no explicitly conflicting behavior present [15,30,41].In code reviews, they can look for example as pushback on changes [15] that does not necessarily relate to an open argument or as a stagnating discussion lacking progress [41].However, reviews that tend to take longer time or require longer discussion can be a sign of issues in the change itself or set up of the code review process other than interpersonal conflicts [6,32,42].
Interpersonal conflicts, whether expressed explicitly or not, can create a variety of issues in code review [41].Conflicts are also difficult to capture by using explicit and observable metrics [34].Due to the subjective nature of conflicts, capturing the self-reported presence of conflicts to identify when developers actually perceive the situation as conflicting or problematic is important [41]-the approach we take in this study.

Predicting problems in code review
Identifying conflicts or conflict-prone projects can be beneficial to tackle the issue.Through timely conflict detection and prediction, proactive steps can be taken to discourage toxic language [38] or to provide developers with strategies to move forward in a constructive way [41].Furthermore, we can also help developers identify pain and stagnation points in their discussion and prevent the negative feelings and pushback from happening in the first place.
Several data sources can be used to identify and predict conflicts or conflict-prone environments.Sentiment Analysis was previously used to analyze the tone of code review comments [1].The aggressive and toxic language has been used to identify explicit content, hate speech, or cyber-bullying with a toxic language detector [38] or to distinguish communication styles of profanity users [39].Other toxicity and pushback detectors use also less explicit textual features like the directive use of personal pronouns in the review comments or the presence of specific technical terms [37].Further useful sources of data are review logs [15,37] -reviews, where developers spend more time on the reviews or go through many rounds of back and forth, are more likely to be a case of pushback on the changes.This corroborates findings about the conflicts being accompanied by stagnation in the process, higher activity in the discussion, and difficulties in moving the decision process forward [41].
However, most of these methods touch only upon the observable text or data about code review activity.And, even though conflicts are a highly subjective concept, many studies rely on the manual classification of conflicts or toxicity by researchers rather than using developers to identify when they experience conflicts [34,37].Self-report methods are needed to capture the subjective aspect of conflicts as well.
The context in which code review is happening can contribute to the rise of a conflict [16,41].Stress, complex reviews, quality of the code, feedback, and relationships in the team are just examples of factors that can create a conflict-prone setup for code reviews.
Correctly identifying interpersonal conflicts therefore stands on understanding (1) the factors contributing to conflicts happening [16,41], (2) the manifestations or symptoms of conflicts in the communication during review and other review activity when they are happening [15,16,34,37,41] and (3) by corroborating these with the perception of the situation by developers themselves [41].Conflict identification can contribute to constructive conflict resolution by using effective conflict management strategies [41].

Constructive conflict management
In the software engineering research community, there is a presented consensus that interpersonal conflicts, the related aggressive speech, and toxicity, are anti-social behavior leading to negative outcomes [37].However, literature on interpersonal conflicts shows that conflicts have the potential to bring change and solutions to problematic situations and be constructive, rather than destructive [10].Even conflicts during code review have the potential to bring value and constructive ideas forward [41].Therefore, identifying ways to aid developers in constructively addressing these conflicts is paramount.Constructive conflict management is concerned with finding strategies to address conflicts in a way that minimizes the chance of loss and maximizes the prospect of gain for both parties [29].Striving to get these gains even in the face of negative experiences that conflicts are can support the legitimization of conflicts [9] and set a team culture that deals with conflicts for the greater benefit.
In software development, conflicts are related to lower process satisfaction, decreased system quality, and worse adherence to budget, schedule, and requirements [3], as well as to a lower perception of project's performance and reduced developers' identification with their OSS team [17,18].In code review, disagreements and interpersonal conflicts can negatively impact the change acceptance, slow down integration, or threaten developers' participation in a project [11,13,15,16,24,26].Conflicts can create a tense reviewing culture [24] that hampers developers' motivation [22] and inclusion [15,22].Developers also report that conflicts in code reviews affect not only their motivation and productivity but also their overall job satisfaction, creating an environment where they do not feel well, disengage from their work, and lose their trust in the code review process [41].Developers can withdraw from the discussion or spiral into an escalating conflict [16].Conflicts affect the decision process in the review.Developers report they have a direct impact on the code base by merging code with poor quality and by making the team communication deteriorate, causing them to be selective about the colleagues they invite for their reviews [41].
Resolving the conflict or seeing a positive outcome of the otherwise unpleasant review helps developers deal with it and minimize the negative impact the conflict might have [41].Developers actually report experiencing many constructive outcomes of conflicts.These consequences are closely tied to the fulfillment of the code review goals.While an unresolved conflict can jeopardize the fulfillment of code review goals like improving code quality or knowledge sharing in the team, a constructive conflict can be a way to achieve them.Developers observe a negative impact on the code quality by making poor decisions or dampening their motivation and collaboration.However, when the conflicts are managed well, they actually observe the code quality getting better, improving how they collaborate with their colleagues and even grow as professionals.
As of now, software engineering practice and research investigates three major areas of mitigating conflicts or broader communication issues -1) organization/project conflict prevention, moderation, and intervention mechanisms, 2) tool support for conflict identification and in-time intervention and 3) individual and team strategies that developers can use themselves to deal with conflicts while they are happening.The first two areas aim mostly to prevent the negative impact of these conflicts or to control the usage of aggressive and offensive behaviours [37].
The OSS communities can rely on the work of volunteering teams and project maintainers to help with moderating discussion and preventing negative experiences from occurring [16,25].The communities aim to raise awareness and warnings, educate developers, and explain rules sometimes summarised in the Code of Conduct that serve as a preventive setup of expectations about developers' interaction during code review.When conflicts are happening and need a resolution, there are also mechanisms to support negotiation or correcting misunderstandings.If the behavior in the discussion is out of the set rules or developers' comfort zone, they can also use more punitive actions like deleting comments or locking conversations.
Bots have the potential to substitute some portion of the moderation process in the community [25].Their activity can be supported by tools that identify communication turning bad that will help bots and developers alike to proactively discourage toxic texts and mitigate offensive language [5,38].The work done on the identification and prediction of conflicts and toxicity in code reviews is summarized in the Section 2.2.
However, the hidden conflicts at work require sometimes more informal strategies to be resolved because the behavior that accompanies them is either indirect or less pronounced [30].Therefore, developers themselves need to have strategies available that they can use when the discussion becomes uncomfortable or unproductive.One code review-specific strategy that is adopted to smooth the communication is asking polite questions rather than giving direct suggestions [27].Studies in software engineering and psychology alike suggest that conflict management strategies that are pro-active, collaborative, and problem-focused are related to better conflict outcomes than strategies that aim to avoid, compromise, ICSE-SEIP '24, April 14-20, 2024, Lisbon, Portugal Wurzel Gonçalves et al.
force or dominate in the conversation [3,4,12,16,20,26].Developers report using a number of the pro-active and problem-focused strategies in code review [41].Apart from the approaches already mentioned, like receiving relevant training or involving a third party in the conflict (who also might be just another reviewer) there is indeed a role of acknowledging that the conflicts are happening and proactively trying to generate ideas and solutions and invest energy into understanding each others point of view.Preparation is also a strategy that helps the clarity of communication and addresses misunderstandings -either as a preparation of a change with clear documentation or a thorough preparation of argumentation in the code review discussion.On the team level, developers can adopt explicit decision-making rules that they systematically apply in moments of stagnation in communication and optimize the level of automation and standardization in their processes so as not to spend resources in code reviews on unnecessary issues [41].

METHODOLOGY
Code reviews often grapple with the challenge of interpersonal conflicts, a concern addressed from various perspectives in the literature [15,16,25].Our prior research [41] delved deeply into this issue, employing a qualitative approach and the theoretical framework of interpersonal conflict [3,23].In the present study, we build on this foundation and aim to provide quantitative evidence for the prevalence and intensity of such conflicts, discerning how often they arise, their influence on the code review process, the strategies developers employ to navigate them, and the ultimate quality of the resulting resolutions.

Defining conflicts
Interpersonal conflicts have been defined as "a dynamic process that occurs between interdependent parties as they experience negative emotional reactions to perceived disagreements and interference with the attainment of their goals [23]." Based on this, we define: Interpersonal conflicts in code reviews refer to experiencing negative emotions stemming from perceived disagreements with other participants during the review process.
The dynamic process [3] can be understood as a cyclical process (Figure 1 (a)) in which the present antecedents and factors feed into how a conflict unfolds.The conflict situation is an interaction between the conflict itself (its content, behavioral, cognitive, and emotional components) and the conflict management applied in the situation.The interaction of the conflict and its management determines what outcomes and consequences the conflict has.The success of the resolve affects the context in which future conflicts are happening by creating less or more conflict-prone constellation of antecedents and factors.There is a wide range of factors on the side of the code and engineering process, developers themselves, the team, and even the organization [41].Therefore, we focus only on the interaction between the conflict, its management, and outcomes, as described in Figure 1 (b).

Previous qualitative work
Using the aforementioned definition of conflicts we have conducted an extensive qualitative study into the interpersonal conflicts in code reviews [41].The current study is a quantitative follow-up.
The qualitative study systematically described and categorized developers perception of these conflicts, the conflict dimensions, the conflict consequences that developers observe, the strategies they use to mitigate these conflicts, and the factors that developers see as intervening in how these conflicts unfold.The picture that we gathered from developers' experience depicts a phenomenon that is rather common and normal for developers to experience and which is closely related to the quality of the code, software development practices, team interaction, and even the company and project culture.Developers report on a wide range of both negative and positive outcomes of conflicts and sometimes see the conflicts themselves as something needed to get the code review benefits.In the study, we have laid a broad landscape of a complex socio-technical process.However, the depiction of how common these conflicts or their consequences are remains to be tackled.Therefore in the current study, we use that landscape to gather further quantitative insights into the interpersonal conflicts in code review.

Research Questions
We formulate one research question to address each of the areas of interest in Figure 1 (b).
Our qualitative findings [41] indicated that conflicts are normal and even expected to appear in code reviews.There is evidence about how common are different phenomena related to conflicts in code review, like offensive language [16], pushback [15] or unfair treatment [19].Due to the subjective nature of conflicts [23], we would like to gather developers' recollection of how often they experience conflicts, how severe they are for their work and how constructive (generating positive outcomes [29]) are these conflicts.RQ 1 .How do developers perceive the severity of interpersonal conflicts during code review?
Evidence suggests that conflicts in code reviews can lead to many negative outcomes [15,16,22,24,41].A constructive conflict aims to maximize the positive consequences of a situation [29].Developers have noted several positive effects of these conflicts on the code, themselves, and their teams [41].Our goal is to understand not only the harmful aspects of conflicts but also the extent to which developers can harness their positive potential.RQ 2 .How effectively do developers achieve positive outcomes from interpersonal conflicts in code review?
Developers and their teams use a number of strategies to try to prevent or resolve conflicts in code review to prevent or resolve the build-up of negative emotions, even if not explicitly expressed yet [41], see Section 2.3.In RQ3 we address which strategies developers and teams use to mitigate conflicts and which ones are related to more constructive code reviews and their outcomes.We use the strategies reported by some developers in our previous work [41].

Data Collection
The study was conducted in two companies -Adnovum and Red Hat.
Adnovum is working on a range of closed-source projects throughout many industries.Red Hat on the other hand encompasses many open source projects and communities.We administered a survey in both of these companies.
Adnovum has disseminated the survey via a blog post.Developers could fill the survey in as part of their work time.Red Hat Research has shared the invitation to the survey on the Red Hat global mailing list.Survey participants could either assign a charity or foundation to which the researchers would contribute 5 USD on their behalf or they could choose to be rewarded with a 10 USD contribution to the company benefit system.The respondents provided their company email in case they chose to receive the company benefits.The participants were ensured about their anonymity towards Red Hat.The list of entered email addresses was provided without the related data to Red Hat Research.The survey data collection was handled by the University of Zurich, whose Human Subject Committee approved the study design.

Survey Design.
As conflicts are a subjectively defined concept [23], we relied on collecting developers' perspectives via selfreport methods, which also allowed us to enquire developers about their experience with causality of conflict consequences, rather than using observational data that would capture bilateral relations [28].
The survey addresses each research question in a specific step (Figure 2).At first (Step 1 in the survey), developers reported their code review practice, in what type of project/team are they performing reviews, what is their current coding and reviewing routine, and their general satisfaction with the efficiency of the process (Step 2).Then (Step 3), we provided our definition of interpersonal conflicts for reference and asked respondents about how frequently they experienced such reviews (7-step Likert scale: Never to Always), how problematic they are in their practice (4-step Likert scale: None at all to Serious problem) and how constructive the outcomes of the conflicts are (7-step Likert scale: Only positive to Only negative).In the next step (Step 4), we listed the known consequences of conflicts as previously reported by developers [41] (see Table 1) and asked on the same scale what effect on conflicts they observe.The following section recorded the individual and team strategies developers use to prevent and manage conflicts (Step 5, likewise in Table 1).At the

Data Analysis
In all the research questions, we are predominantly describing three interest variables -1) frequency of interpersonal conflicts in code review, 2) their severity, and 3) constructiveness.
In RQ1 we report on frequencies of the interest variables and Spearman correlations among them.
To answer RQ2 and RQ3, we use ordinal regression to predict the interest variables [7].By analyzing correlations of all collected potential factors, we have included confidence in resolving the conflicts and code review experience as control variables in the models.Wherever applicable, we use Spearman's correlations to demonstrate relationships between variables as most of the survey responses are captured on an ordinal scale.
In RQ2, we report on frequencies of constructiveness of individual conflict outcomes as reported by developers.We build an ordinal regression model for the frequency and severity of conflicts to identify whether more frequent or severe conflicts stimulate certain types of conflict outcomes to be more or less constructive.
In RQ3 we report how frequently developers use individual and team strategies to mitigate conflicts and the relevant training they received.We build three sets of ordinal regression models to predict the interest variables and identify which management strategies and training are related to more constructive code reviews -reviews with fewer conflicts, lower severity, and better outcomes.Based on these, we calculated the required sample size using Power Analysis [8].Running the analysis for a regression model with a small effect size yielded a sample size of 95 responses.

RESULTS
In this section, we report the results of our study by starting with descriptives of the respondents and then detailing the results by research question.

Respondents
We collected a total of 154 full survey responses -38 at Adnovum and 116 at Red Hat.Most respondents (79%) code at least once a week and 72% have at least three years of code review experience.Figure 3 presents further demographic descriptives.

RQ 1 : Prominence and severity of conflicts
In RQ1, we address how frequently developers encounter interpersonal conflicts, and how severe and how constructive (maximizing positive outcomes [29]) these conflicts are for them.A summary of the responses is presented in Figure 4.
Interpersonal conflicts are a common experience in code reviews.Among our respondents, 81 (77%) developers reported they sometimes experience conflicts.For most developers (55%), this happens in less than 10% of reviews.However, for 5% of developers, conflicts are present in more than 40% of reviews, i.e., a substantial portion of their work.Developers who experience conflicts in code review more often also perceive them as being more severe ( = 0.46).In Figure 5, we display how the responses about frequency, severity, and constructiveness relate to each other.
For 64% of developers, interpersonal conflicts in code review pose some degree of a problem for their work.While most of these developers see conflicts as a minor issue, 15% of developers do report they pose a moderate to serious problem.Developers who experience more severe problems perceive them as less constructive and report more negative outcomes of the conflicts ( = −0.27).Even though there is a bigger portion of developers who see mostly the negative and destructive aspect of conflicts (31%), a quarter of developers (24%) are successful in regularly deriving constructive outcomes of the emotionally negative experience, see Figure 4 (c).Developers who feel less confident that they can resolve the situation successfully experience more severe ( = −0.3)and less constructive ( = 0.37) conflicts.
Finding 1. Interpersonal conflicts are a common experience in code reviews that can pose a serious problem in developers' work.However, developers are in general able to derive constructive outcomes of these conflicts.

RQ 2 : Outcomes from interpersonal conflicts
We offered developers a list of areas that can be affected by interpersonal conflicts (Table 1).Then we asked them whether they observed positive or negative effects of conflicts in the said area in practice.Their responses are presented in Figure 6.Developers report being rather successful in deriving constructive conflict  outcomes throughout the spectrum of conflicts' consequences.In particular, constructive outcomes of conflicts are reported for code quality and maintainability.Even though conflicts are an issue interaction between developers, they report conflicts can have a positive impact on their communication and collaboration as well.However, in these areas, conflicts can also be destructive and restrain the collaborative exchange among developers.Developers report the most destructive effects on motivation and will to work with their colleagues involved in the conflict.Developers could also report they see no effect of these conflicts or can't tell.Developers most frequently report that conflicts influence team communication, motivation, collaboration, and their willingness to work with colleagues, either positively or negatively.Among the most commonly affected areas, developers frequently cite the generation of new ideas (N=92).However, this area also sees the least agreement among developers regarding the specific impact of conflicts (N=42).Fewer developers observe a noticeable effect of conflicts on standardization, the code review process within the team, their desire to continue working on the project, and code maintainability.
The ordinal regression models (detailed results of all regression models are available in the online material [36]) revealed that more severe conflicts are especially related to worsened collaboration in the team.Developers who experience more severe conflicts report more negative outcomes for collaboration ( = −0.27)and communication ( = −0.21) in the team as well as for their willingness to work with the involved colleagues ( = −0.26)and in the team and project in general ( = −0.29).They also report more negative outcomes for code quality ( = −0.27)and generation of new ideas ( = −0.22).
Finding 2. Developers are able to derive positive outcomes in the face of conflicts, especially in the technical aspect of code review.More severe conflicts have more detrimental effects in terms of team communication and collaboration.

RQ 3 : Conflict Management Strategies
Developers rated the individual and team strategies they use to mitigate interpersonal conflicts in code review (Figure 7).They also reported which relevant training they received.
Developers whose teams apply more conflict management strategies report more constructive conflict outcomes.When conflicts happen, more than half of developers try to better explain their thoughts (77%) and propose new solutions (51%).They also acknowledge the conflict (52%) and try to find collaborative solutions(53%).At the team level, developers are the most likely to discuss communication issues at meetings and update automation and standardization to streamline the process and communication.We have also allowed the respondents to insert other strategies they might be using to mitigate conflicts.They mentioned several strategies that were not mentioned explicitly in the survey: taking a step back, not taking issues personally and focusing on technical aspects of the review, documenting agreements, building strong relationships in the team, and promoting code ownership and the role of a tech lead.
We used ordinal regression to relate the use of different strategies to the frequency, severity, and constructiveness of conflicts.Developers who reported having fewer conflicts and less severe ones also reported more often adapting their communication style to their colleagues and explaining their thoughts in more detail.In contrast, developers who report more constructive conflict outcomes tend to explain and adapt in the communication less.
Developers who report more constructive reviews with fewer and less severe conflicts work in teams that explicitly try to prevent and manage conflicts by managing effort and assignment of tasks.More constructive review outcomes are also reported by developers who try to find collaborative solutions.Furthermore, developers who experience more conflicts are more likely to involve additional reviewers in the process.
The most commonly received training is in the Code of Conduct and training in constructive feedback and communication.While developers report receiving different types of relevant training, we did not observe any relationship between the training received and constructive conflicts.
Finding 3. The more strategies teams use to mitigate conflicts, the more likely they are to reach constructive conflict outcomes.Constructive reviews happen especially when teams manage work effort and task assignments to reduce stress in the reviews.

DISCUSSION
Interpersonal conflicts have been addressed in software engineering and in the context of code reviews mainly as a problematic and anti-social issue, yielding negative outcomes [15,16,34,37].In our previous work, we provided qualitative evidence that developers observe also positive aspects of these conflicts [41].
In this study, we challenged that conflicts are a purely negative concept and provided quantitative evidence -based on developers' experience and observations from practice -that conflicts are regularly managed by developers toward reaching constructive conflict outcomes.Furthermore, while the literature so far focused mostly on the more explicit and extreme forms of conflicts [38], we have used the psychological concept of interpersonal conflict [23] to capture the subjective and potentially hidden nature of conflicts.
Our approach to interpersonal conflicts differs from previous work by (1) explicitly focusing on describing the constructive potential of interpersonal conflicts and (2) using a subjective definition of an interpersonal conflict [23] that enables also capturing the non-explicit, hidden side of the issue.The presented data has the following implications: Not every conflict is destructive.Concepts related to interpersonal conflicts have been so far researched mostly due to their potential to be anti-social and bring destructive outcomes [34,37,38].Explicit conflicts, however, are infrequent events [16].When asking developers about whether they had negative experiences in review or felt treated unfairly, we can tap into the part of conflicts that is not easily observable.While evidence exists regarding the prevalence of other negative phenomena in code reviews [15,16,39], it remained unclear if these truly troubled developers.In RQ 1 , we established that developers experience interpersonal conflicts often and regularly with 64% claiming they pose at least a mild problem in their work and for some developers are even a severe problem.However, the remaining 46% have no issue with conflicts even if they sometimes experience them.Furthermore, our data suggests that even frequent conflicts do not imply they are not constructive.We found that more frequent conflicts also tend to be perceived as more severe and more destructive.However in (RQ 3 ), we described that developers using the same strategies -adapting their communication style and explaining their thoughts in more depth experienced less problematic conflicts, but also reported more destructive outcomes.Further understanding of when frequent conflicts are the more constructive ones or mild conflicts bring many negative outcomes can help gather insights on how to turn problematic conflicts into constructive scenarios.
Developers strive to reach constructive outcomes.The literature is replete with discussions on the negative consequences of interpersonal conflicts, including reduced patch acceptance, delayed integration, diminished developer participation, and lower motivation or inclusion [11,13,15,16,22,24,26].Yet, our prior qualitative research suggests that these very areas can experience positive impacts as well [41].Our investigation of RQ 1 and RQ 2 reveals that developers often achieve constructive resolutions to interpersonal conflicts during code reviews.Although they generally perceive conflicts as having negative consequences on their work, they report more positive than negative outcomes across all the areas we inquired about.The areas most commonly associated with negative consequences of conflict are their willingness to work with colleagues and their motivation.
Empower developers to achieve constructive conflict outcomes.Developers acknowledge that observing the benefits of well-managed conflicts equips them to deal with the conflicts [41].Given the subjective and potentially concealed nature of interpersonal conflicts [23,30], developers play a pivotal role in influencing the onset and management of these conflicts.Developers sometimes face uncertainty in handling conflicts [41].We found a correlation in our study: the more severe and less constructive the conflicts, the lower the developers' confidence in addressing them (RQ 1 ).Although developers employ various strategies to mitigate conflicts (RQ 3 ), our study did not uncover many strategies that lead to better conflict outcomes.However, RQ 3 reveals that developers in teams using a broader range of conflict management strategies experience more constructive conflicts.Therefore, the focus should shift  from solely preventing negative outcomes to actively providing developers with the skills and knowledge to transform conflicts into growth opportunities and fostering a conflict-aware culture within their team.
Focus on collaboration and motivation among developers in the face of conflicts.Research has shown that a collaborative and problem-focused approach to conflict management leads to better results [3,4,12,16,20,26].Conflicts in code reviews can have implications for both technical and social dimensions [11,13,15,16,22,24,26].Notably, our second research question revealed that developers recognize positive outcomes across these areas.Importantly, motivation, collaboration, and will to work with colleagues involved in conflict situations are the areas where most developers observe either positive or negative consequences and thus, areas that might be affected more frequently or strongly.Furthermore, these are also areas where more developers report experiencing the negative effects of conflicts.Thus, promoting a culture of collaboration within teams is key to reducing the negative impact of conflicts.Interestingly, previous research has proven the negative effect of conflicts on developers' participation in their OSS projects [26].In our study, developers' will to keep working in their team and project is among the least likely affected areas -a lower number of developers report observing any effect, and fewer developers report negative effects on this area.
Developers should get to know their colleagues and tailor their communication.Our analysis for RQ 3 highlighted two individual conflict management strategies associated with constructive code reviews.Developers who elaborate on their points and modify their communication style based on the colleague tend to experience fewer and less severe conflicts.These strategies foster more flexible communication, reducing misunderstandings.In our previous study [41], developers reported that stable relationships with their colleagues enable them to learn how their colleagues communicate and adapt to it so that they make their point more clearly and create more convincing arguments but also understand when their colleagues are getting upset.Indeed, a positive, collaborative relationship is a strong factor contributing to a constructive conflict resolution [35].Interestingly, our data revealed that developers achieving constructive outcomes often did not rely as much on these strategies, using adaptive communication and in-depth explanations less frequently.
Managing workloads enhances constructive code reviews.Our qualitative study revealed that developers believe that one of the ways managers can constructively get involved and help in conflicts is by adjusting workload among team members [41].RQ 3 further underscores that the team strategy most linked to constructive reviews-marked by reduced conflict frequency and severity, and increased constructiveness-is the adept handling of work effort and the redistribution of tasks within the team.Indeed, developers indicate that workload and stress contribute to how strong role conflicts get in their code reviews [41] As a participant in our qualitative study explained: "I am late.I've been working for three or four days, my boss is putting pressure on me to deliver, and here comes [name of a person] and gives me feedback that will require two days of work.You are not going to accept it very well." This example underscores that effective effort estimation and tracking, along with reasonable review timelines and task assignments in teams, can significantly enhance constructive exchanges during code reviews.
Extend conflict detection beyond explicit toxicity.Software engineering research relies mostly on objective data when investigating conflicts in code review, such as textual features of review comments or log-based data [15,16,37,39].However, it is essential to consider the developers' subjective perspectives to truly discern when a conflict arises [23]: A conversation with the same textual features, devoid of negative emotions, might be merely a technical discussion.Therefore, to increase the conceptual validity of conflict detection tools, this perspective should be included.Currently, the identification of conflict often hinges on researchers' classifications rather than developers' labeling [37].Delving deeper into the factors that influence the presence and intensity of conflicts can prove insightful, and we have provided a comprehensive list of these factors [41].In this study, RQ 3 , developers reported that when the conflicts get more severe, they tend to involve additional reviewers.This behavior could potentially enhance the precision of conflict detection.Furthermore, signs of stagnation in the review process, such as increased participation in discussions without advancing decision-making, could also indicate underlying conflicts [15,41].

THREATS TO VALIDITY
As we used an observational design, we do not directly test the consequences of individual conflict situations or the effect of conflict management strategies on the constructiveness of conflicts but the relationships that can be observed throughout the full experience of developers with code reviews.Therefore, the direction of the relationships can be only implied by the experience of developers and requires further testing.Furthermore, studies examining relationships on the level of a single code review could provide more focused and detailed results on the effectiveness of individual conflict management strategies.
Our survey asked developers about which strategies they use to mitigate conflicts.However, they reported about their general experience with conflicts within the project including times when they potentially did not face any conflicts.As we employed an observational study design, we opted for a simplified survey in exchange for potentially less strong results about the strategies' effectiveness.
Training is one area that would benefit from more direct observation or experimentation.We documented the training developers underwent but found no correlation between the training received and constructive conflicts.Instead of viewing this as a shortcoming of the training to enhance conflict resolution, we propose that other methodologies should be used to evaluate training effectiveness, see the point above.
Our study is dependent on developers' self-report of conflicts.While using a self-report method to investigate conflicts improves the construct validity, it can be affected by phenomena like social desirability bias [21].We hope to mitigate this effect by keeping developers' data anonymous from their companies.
We collected data from two companies -a predominantly closedsource one and a predominantly open-source one.Due to this, we do not generalize our findings to comparisons between open-source and closed-source environments as we do not have a representative sample of the whole community.

CONCLUSION
Interpersonal conflicts have been proven to have a negative impact on code reviews.Despite that, this study has shown that developers are rather successful in deriving positive conflict outcomes.This holds true, especially for the technical review outcomes -code quality and maintainability.However, collaboration and developers' motivation are more susceptible to the detrimental effects conflicts can have.Empowering developers and their teams to proactively and collaboratively resolve conflicts can bring them on the path toward constructive code review.

RQ 3 .
What conflict management strategies are perceived as related to more constructive conflicts?Constructive Code Review: Managing the Impact of Interpersonal Conflicts in Practice ICSE-SEIP '24, April 14-20, 2024, Lisbon, Portugal The full dynamic process of interpersonal conflicts[3,41].The interest areas in this study.

Figure 1 :
Figure 1: The conceptual framework by Barki and Hartwick [3] used to define the Research Questions and scope of the study

Figure 2 :
Figure 2: Flow of the survey sections.
Manage work and review effort Code of conduct Collaboration in the team Discuss implementation in advance Communication in the team Set and express what are the priorities Will to keep working at the team/project Adapt communication to different colleagues Will to work with the colleagues involved Try to understand emotional state of colleagues Motivation Ask for an in-person meetng Involve a new reviewer Involve a manager

Figure 3 :
Figure 3: demographics (num. of respondents) How often have you been experiencing interpersonal conflicts during code review?How much of a problem are the interpersonal conflicts in code review for you?What kind of consequences of the interpersonal conflicts during code review do you observe?

Figure 4 :
Figure 4: The (a) frequency, (b) severity, and (c) constructiveness of interpersonal conflicts in code review (num. of respondents)

Figure 5 :
Figure 5: Flow of responses between the frequency (on the left), severity (middle), and constructiveness (right) of the conflicts.

Figure 6 :
Figure 6: Consequences of interpersonal conflicts in review.

ICSE-SEIP ' 24 ,
April 14-20, 2024, Lisbon, Portugal Wurzel Gonçalves et al. of view (a) Individual conflict management strategies (% of respondents who use the strategy) work and review effort, re-assigning tasks Explicit preparation of the change implementation Deciding about the patch on team level Having a team process to find a decision Updating automation and standardization Discussing communication in team meetings (b) Team conflict management strategies (% of resp.whose team use the strategy) Training that the respondents received (% of respondents)

Figure 7 :
Figure 7: The (a) individual and (b) team strategies developers use to mitigate conflicts and the (c) training they received.