SEmotion '18- Proceedings of the 3rd International Workshop on Emotion Awareness in Software Engineering

Software developers communicate and interact with each other in order to solve complex problems. Such communication often includes emotional displays that have been shown to influence team processes and performance. Yet, little is known about the evolution of team emotional displays. Hence, we investigate a sample of 1121 Open Source Software (OSS) projects from GitHub, using longitudinal data analysis. The results from growth curve analysis shows that the team emotional display decrease over time. This negative linear trend decelerates mid-term as suggested by a positive quadratic trend of time. Such deceleration diminishes toward the end as a negative cubic trend suggests.

Emotions and sentiment of software developers can largely influence the software productivity and quality. However, existing work on emotion mining and sentiment analysis is still in the early stage in software engineering in terms of accuracy, the size of datasets used and the specificity of the analysis. In this work, we are concerned with conducting entity-level sentiment analysis. We first build a manually labeled dataset containing 3,000 issue comments selected from 231,732 issue comments collected from 10 open source projects in GitHub. Then we design and develop SentiSW, an entity-level sentiment analysis tool consisting of sentiment classification and entity recognition, which can classify issue comments into <sentiment, entity> tuples. We evaluate the sentiment classification using ten-fold cross validation, and it achieves 68.71% mean precision, 63.98% mean recall and 77.19% accuracy, which is significantly higher than existing tools. We evaluate the entity recognition by manually annotation and it achieves a 75.15% accuracy.

In this study, we analyzed issues and comments on GitHub projects and built collaboration networks dividing contributors into two categories: users and commenters. We identified as commenters those users who only post comments without posting any issues nor committing changes in the source code. Since previous studies showed that there is a link between a positive environment (regarding affectiveness) and productivity, our goal was to investigate commenters' contribution to the project concerning affectiveness.

We analyzed more than 370K comments from 100K issues of 25K contributors from 3 open source projects. We then calculated and compared the affectiveness of the issues' comments written by users and commenters in terms of sentiment, politeness, and emotions. We provide empirical evidence that commenters are less polite, less positive and in general they express a lower level of emotions in their comments than users. Our results also confirm that GitHub's contributors consist of different groups which behave differently, and this provides useful information for future studies in the field.

Software engineering researchers are increasingly interested in the role of emotion during software development. While general tools are available to extract emotions from textual data, these perform poorly in the domain of software engineering. Hence, this paper develops MEME - a Method for EMotion Extraction. Using GHtorrent and GitHub as data sources, the paper presents an implementation of the method. The evaluation results suggest a better performance of MEME in contrast to Syuzhet R package emotion analysis.

In software projects, a continuous exchange of information among team members is necessary to ensure a successful project. Meetings support this information exchange because they enable team members to share information simultaneously with all other team members. However, teams often get lost in endless discussions or developers do not gain a real benefit from a meeting. Consequently, participants are often frustrated by meetings. This leads to a negative mood and the project is endangered. To ensure the quality of information exchange and to prevent frustrated developers, meetings have to be assessed periodically. We ask the participants about their perception during a meeting because participants' satisfaction with the outcome is essential for project success. Hence, the definition of a good meeting bases on effectiveness, efficiency, and satisfaction. In order to measure perceived meeting success, we developed a feedback method and a tool applying it. To validate the method, we conducted a case study during two meetings and compared our results to an objective analysis. During the case study, our feedback method showed the advantages over the compared behavior-based approach. Using our method, teams can easily gather feedback about their meeting and decide whether future meetings need an improvement or can be abandoned. So the method helps teams to find the right manner of communication in meetings and to reduce the developers' frustration.

Communicating¹ automatically inferred programming difficulty to appropriate observers can promote help if they have enough context to determine whether they should and can offer help. Buffered workspace awareness keeps a segment of the developer's actions around an inferred difficulty as context, and allows the recording to be played a single or multiple times. Semi-structured interviews with mentor-intern pairs in a large company showed that they liked the general idea of buffered workspace awareness. We performed a two-phase user study where observers used both single- and multi-pass awareness to determine the problems developers' had and the solution to those problems. Almost all solutions required a one-line fix. We could find no statistical difference in the correctness of their solutions in the two conditions, though the observers overwhelmingly preferred and were more confident using the multi-pass mechanism, and made use of its rewind and pause commands. Both kinds of mechanisms allowed the observers to solve the majority of problems by looking only at 5 minutes of the workers' interaction before the difficulty. The time spent by them processing the context was a small fraction of the time spent by the developers on the difficulties. The time wasted on abandoned difficulties was a small fraction of the time spent on difficulties.

According to authors best knowledge, this workshop paper makes two novel extensions to software engineering research. First, we create and execute a daily questionnaire monitoring the work well-being of software developers through a period of eight months. Second, we utilize statistical methods developed for discovering psychological dynamics to analyze this data. Our questionnaire includes elements from job satisfaction surveys and one software development specific element. The data were collected every day for a period of 8 months in a single software development project producing 526 answers from eight developers. The preliminary analysis shows the strongest correlations between hurry and interruptions. Additionally, we constructed temporal and contemporaneous network models used for discovering psychological dynamics from the questionnaire responses. In the future, we will try to establish links between the survey responses and the measures collected by conducting software repository mining and sentiment analysis.

Software development consulting companies must be able to select the best suited developers for their clients. A method of doing this is through competence evaluation. Sigma IT Consulting uses manual methods consisting of heavy documentation for employees to fill in their competence. Problems such as data inconsistencies in documentation of competency might cause difficulties for managers while making decisions to assign right developer to the right job. Such difficulties may lead to frustration in managers and negatively affect their decision-making process. Similarly, developers might feel themselves under pressure always having to fill in the competency documents whenever the manager makes requests among all the tasks the developers are busy with and feeling under pressure might have negative effects on developers' performance. Researchers have shown that negative emotions lead to poor software development performance, while positive emotions improve developers' performance. Competency evaluation is an integral part of the daily routine at Sigma IT Consulting. Therefore, negative effects of competency sheets on developers and managers cannot be tolerated. In this case study, having investigated how competency is evaluated at Sigma IT and what employees think about competency evaluation in general, we implemented a web-based competency evaluation platform. When supplemented with qualitative data, the results of the Self-Assessment Manikin (SAM) and Intrinsic Motivation Inventory (IMI) we conducted show that automation of competency evaluation as a web-based platform has positive effects on developers' and managers' emotions and motivations. Interviews we conducted with developers and managers also include their positive thoughts about automation of the competency evaluation.

Software developers experience a wide variety of emotions during their work and research is now focusing on the role played by these emotions on software developers productivity as well as on their wellbeing. In this paper, we propose a replication of a study aimed investigating to what extent biometric sensors can be used to automatically detect developers' emotions during programming tasks. The long-term goal of our research is to discover which emotions affect developers' productivity and wellbeing during their work. Specifically, we aim at defining approaches for early detection of negative affective states that are known to impair mental wellbeing and productivity.¹

Many software engineering researchers use sentiment and politeness analysis tools to study the emotional environment within collaborative software development. However, papers that use these tools rarely establish their reliability. In this paper, we evaluate popular existing tools for sentiment and politeness detection over a dataset of 589 manually rated GitHub comments that represent developer discussions. We also develop a coding scheme on how to quantify politeness for conversational texts found on collaborative platforms. We find that not only do the tools have a low agreement with human ratings on sentiment and politeness, human raters also have a low agreement among themselves.