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.
翻译:交流在软件开发中至关重要,在分布式环境中更为重要。 交流活动需要组织和协调,以防范生产力损失、认知负荷增加和团队成员压力的威胁。 由于以前对开放源头项目的研究所查明的通信渠道过多,有必要探索如何引入、解释和激励所有项目成员使用这些通信渠道的组织问题。 在这项研究中,我们希望了解GitHub项目使用哪些通信渠道,以及如何向GitHub项目受众介绍这些渠道。我们利用专题分析来分析90个GitHub项目中的151件艺术品。我们的成果揭示了32个独特的通信渠道,可以分为9种不同类型。项目大多提供不同类型的渠道,但有些类型(例如聊天)通常提供若干渠道。维护者知道这些渠道有不同的特点,帮助开发者决定哪个频道应该用于哪个案例。 但是,并非所有项目都使用这种渠道,而且我们常常没有找到任何明确的理由来让维护者选择在另一个频道上提供一个频道。 不同的渠道可以被明智地用于不同的渠道。