When Conversations Turn Into Work: A Taxonomy of Converted Discussions and Issues in GitHub

TL;DR

This study analyzes how developers convert discussions into issues and vice versa on GitHub, revealing common reasons, time costs, and implications for better communication management in open-source projects.

Contribution

It introduces two taxonomies of conversion reasons and provides empirical data on the frequency, motivations, and time involved in discussion-issue conversions.

Findings

Clarification requests are the most common reason for converting discussions to issues.

Non-actionable topics like Q&A and ideas are frequently converted from issues to discussions.

Conversion processes can take a median of 15 to 35 hours, indicating non-trivial effort.

Abstract

Popular and large contemporary open-source projects now embrace a diverse set of documentation for communication channels. Examples include contribution guidelines (i.e., commit message guidelines, coding rules, submission guidelines), code of conduct (i.e., rules and behavior expectations), governance policies, and Q&A forum. In 2020, GitHub released Discussion to distinguish between communication and collaboration. However, it remains unclear how developers maintain these channels, how trivial it is, and whether deciding on conversion takes time. We conducted an empirical study on 259 NPM and 148 PyPI repositories, devising two taxonomies of reasons for converting discussions into issues and vice-versa. The most frequent conversion from a discussion to an issue is when developers request a contributor to clarify their idea into an issue (Reporting a Clarification Request -35.1% and 34.7%, respectively), while agreeing that having non actionable topic (QA, ideas, feature requests -55.0% and 42.0%, respectively}) is the most frequent reason of converting an issue into a discussion. Furthermore, we show that not all reasons for conversion are trivial (e.g., not a bug), and raising a conversion intent potentially takes time (i.e., a median of 15.2 and 35.1 hours, respectively, taken from issues to discussions). Our work contributes to complementing the GitHub guidelines and helping developers effectively utilize the Issue and Discussion communication channels to maintain their collaboration.