Analysing Developers Affectiveness through Markov chain Models

In this paper, we present an analysis of more than 500K comments from open-source repositories of software systems. Our aim is to empirically determine how developers interact with each other under certain psychological conditions generated by politeness, sentiment and emotion expressed in developers’ comments. Developers involved in open-source projects do not usually know each other; they mainly communicate through mailing lists, chat rooms, and tools such as issue tracking systems. The way in which they communicate affects the development process and the productivity of the people involved in the project. We evaluated politeness, sentiment, and emotions of comments posted by developers and studied the communication flow to understand how they interacted in the presence of impolite and negative comments (and vice versa). Our analysis shows that when in presence of impolite or negative comments, the probability of the next comment being impolite or negative is 14% and 25%, respectively; anger, however, has a probability of 40% of being followed by a further anger comment. The result could help managers take control the development phases of a system since social aspects can seriously affect a developer’s productivity. In a distributed environment this may have a particular resonance.

💡 Research Summary

This paper investigates how developers interact in open‑source projects by analyzing the affective content of more than 500 000 issue‑tracking comments. The authors collected comments from fifteen open‑source projects (over 1 000 projects in total) hosted on Jira across the Apache, Spring, JBoss and Code‑Haus ecosystems, resulting in a corpus of roughly two million comments, of which a subset of 500 k was used for the affective analysis. Each comment was automatically labeled for three dimensions: politeness (polite, neutral, impolite), sentiment (positive, neutral, negative), and basic emotions (joy, anger, sadness, love). Politeness was assessed with a dedicated API, sentiment with tools such as SentiStrength, and emotions with the NRC Emotion Lexicon. While the authors acknowledge that automatic labeling introduces noise, they rely on the established performance of these tools (typical F1 scores between 0.70 and 0.80).

The core methodological contribution is the construction of observable Markov chain models for each affective dimension. For each project, three transition matrices were built, one per dimension, yielding a total of 45 matrices. The matrices capture the probability that a comment in state i is followed immediately by a comment in state j, i.e., a first‑order Markov assumption. By aggregating the project‑specific matrices, the authors derived general transition models that describe overall community behavior.

Key findings include: (1) the probability that an impolite comment is followed by another impolite comment is 14 %; (2) the probability that a negative sentiment comment is followed by another negative comment is 25 %; (3) the probability that an anger‑laden comment is followed by another anger comment is 40 %. In contrast, positive emotions such as joy or love have much lower self‑reinforcement probabilities (below 10 %). The authors also observed a “politeness repair” effect: when faced with an impolite comment, developers are more likely to respond politely (≈35 % chance) than to continue the impolite tone. Similarly, negative sentiment often elicits a positive response (≈30 % chance).

These results answer two research questions. RQ1 asks whether developers change their behavior in the context of impolite or negative comments; the answer is affirmative, as developers tend to counteract negativity with politeness or positivity. RQ2 examines the likelihood of shifting from positive to negative emotions; the data show that negative emotions, especially anger, tend to propagate, whereas positive emotions are less contagious.

The paper discusses practical implications for project managers: continuous streams of impolite or angry comments can degrade team cohesion, increase issue‑resolution time, and deter newcomers. An automated affective monitoring system could flag high‑risk sequences, prompting timely interventions such as mediation, policy reinforcement, or targeted training.

Threats to validity are thoroughly examined. The authors note the limitations of automated affective labeling, the omission of temporal gaps between comments, and the disregard for thread structure (i.e., comments are treated as a linear sequence rather than a tree). The first‑order Markov assumption also precludes modeling longer‑range dependencies and cumulative emotional states. Moreover, the study is limited to English‑language comments from Jira, restricting generalizability to other languages or communication platforms.

In conclusion, the study demonstrates that Markov chain models can effectively capture short‑term affective dynamics in large‑scale software development communication. The high self‑reinforcement probability of anger suggests that negative emotional bursts can quickly cascade, highlighting the need for proactive social‑technical management. Future work is proposed to explore higher‑order Markov models, incorporate time‑weighted transitions, and extend the analysis to multi‑language corpora and other collaboration tools such as mailing lists, pull‑request discussions, and chat platforms.