How Are Communication Channels on GitHub Presented to Their Intended Audience? -- A Thematic Analysis

Communication is essential in software development, and even more in distributed settings. Communication activities need to be organized and coordinated to defend against the threat of productivity losses, increases in cognitive load, and stress among team members. With a plethora of communication channels that were identified by previous research in open-source projects, there is a need to explore organizational issues in how these communication channels are introduced, explained, and motivated for use among all project members. In this study, we wanted to understand which communication channels are used in GitHub projects and how they are presented to the GitHub project audience. We employed thematic analysis to analyze 151 artifacts in 90 GitHub projects. Our results revealed 32 unique communications channels that can be divided into nine different types. Projects mostly provide channels of different types, but for some types (e.g., chat) it is common to provide several channels. Maintainers are aware that channels have different properties and help the developers to decide which channel should be used in which case. However, this is not true for all projects, and often we have not found any explicit reasons why maintainers chose to provide one channel over another. Different channels can be used for different purposes and have different affordances, so maintainers have to decide wisely which channels they want to provide and make clear which channel should be used in which case. Otherwise, developers might feel overwhelmed of too many channels and information can get fragmented over multiple channels.Comment: 10 pages, 5 figures. Accepted for presentation at the International Conference on Evaluation and Assessment in Software Engineering (EASE) 202

Investigation on Self-Admitted Technical Debt in Open-Source Blockchain Projects

Technical debt refers to decisions made during the design and development of software that postpone the resolution of technical problems or the enhancement of the software's features to a later date. If not properly managed, technical debt can put long-term software quality and maintainability at risk. Self-admitted technical debt is defined as the addition of specific comments to source code as a result of conscious and deliberate decisions to accumulate technical debt. In this paper, we will look at the presence of self-admitted technical debt in open-source blockchain projects, which are characterized by the use of a relatively novel technology and the need to generate trust. The self-admitted technical debt was analyzed using NLP techniques for the classification of comments extracted from the source code of ten projects chosen based on capitalization and popularity. The analysis of self-admitted technical debt in blockchain projects was compared with the results of previous non-blockchain open-source project analyses. The findings show that self-admitted design technical debt outnumbers requirement technical debt in blockchain projects. The analysis discovered that some projects had a low percentage of self-admitted technical debt in the comments but a high percentage of source code files with debt. In addition, self-admitted technical debt is on average more prevalent in blockchain projects and more equally distributed than in reference Java projects.If not managed, the relatively high presence of detected technical debt in blockchain projects could represent a threat to the needed trust between the blockchain system and the users. Blockchain projects development teams could benefit from self-admitted technical debt detection for targeted technical debt management

Motivating programming language design for digital lutherie

Digital lutherie is a sub-domain of digital craft focused on creating digital musical instruments: high-performance devices for musical expression. It represents a nuanced and challenging area of human-computer interaction that is well established and mature, offering the opportunity to observe designers’ work on highly demanding human-computer interfaces. Through the integration of instruments and computers, a new digital 'material' is introduced to the craft. And with a new medium comes new tools. Digital luthiers require expressive use of programming languages to draw together multiple different problem domains in creating new instruments. Motivated by initial explorations in programming language design, this thesis explores the motivations for tool choice in digital lutherie and inductively researches what characterises good programming language design for digital lutherie. Findings from 27 standardised open-ended interviews with prominent digital luthiers from commercial, research, independent and artistic backgrounds are analysed through reflexive thematic analysis. Our discussion explores their perspectives, generating a set of themes that are analysed and discussed. Through this process, a set of 'selective pressures' on language design is presented in order to help motivate and guide future language design in digital lutherie. We also present how challenges faced by digital luthiers relate to social creativity and meta-design, key components of end-user development. Some suggestions are also made to inspire strategies and approaches to programming language design