Page 73 - 《软件学报》2026年第7期

2758 软件学报 2026 年第 37 卷第 7 期

中存在多个并行对话, 且消息记录相互交织 (RQ1). 针对这一问题, 在线平台供应商可考虑引入自动解缠技术, 以
提升参与者高效浏览和跟进对话线程的能力, 特别是便于负责协调在线讨论的人员, 快速定位相关内容并跟踪对
话进展.
4.2 开源软件社区
● 定制适配社区互动风格的交流入门指南, 鼓励跨社区经验借鉴. Discord 各社区的软件实践者展现出独特的
互动风格, 这一特征可通过不同社区间互动模式分布的差异得到验证 (RQ2). 深入理解特定社区的互动风格, 有助
于为开源软件社区的新成员制定入门指南, 帮助其快速融入社区. 此类指南需基于社区既有的互动规范量身定制,
聚焦于高效提问和提供简洁答案的实践指导. Redis 社区中直接回答模式 (P5) 的高频出现, 凸显了该社区倾向于
采用简洁高效的沟通方式 (RQ2). 这一发现揭示了开展跨社区分析的潜在价值, 有助于发现最佳实践并识别沟通
策略中有待改进的方面. 例如, 其他开源社区可借鉴 Redis 社区简洁高效的沟通方式, 考虑引入类似策略, 以提升
自身的沟通效率和整体协作效能.
● 提出问题时, 应确保代码片段具备充分的上下文信息. 尽管在 Discord 上的提问中嵌入代码片段似乎有助于
缩短响应时间, 但代码片段的加入并未对问题解决率产生统计学显著影响 (RQ4). 若代码片段缺乏必要的上下文
信息, 将限制参与者提供全面解决方案的能力, 从而降低问题在对话中得到解决的可能性. 例如, 以下是 Angular
社区中一个未解决问题的案例.
Anyone any idea what’s wrong with my code?
<mat-checkbox #check [checked] = “store.brickSelected$ | async” (click) = “store.toggleBrick(check.checked)”>
Select Brick <mat-checkbox>
该问题缺乏足够的背景细节, 例如复现问题所需的信息, 导致难以获得有效解决. 因此, 建议开源软件社区在
参与者发布问题时, 提供包含关键背景信息的清单作为指引, 促使参与者在提问时完整呈现必要细节, 从而提升问
题被解决的可能性.
4.3 研究人员
跨在线交流平台特征融合. 在对 RQ1 的调查中发现, Discord 的响应率在 43%–62% 之间, 明显低于 Stack Overflow
的 92% [60] . 这一差异可能源于 Stack Overflow 通过标签系统实现了问题的结构化组织, 使软件实践者能够精准定
位感兴趣的问题 [58] , 同时, 其游戏化机制也有效激励了用户持续参与 [61] . 相比之下, Discord 的交流更为随意, 结构
化程度较低, 这可能导致问题的可见度和优先级下降, 从而降低响应率. 未来研究可探索将 Stack Overflow 的功能
设计融入 Discord, 优化问题的组织与展示机制, 以提升用户参与度, 构建更活跃的社区生态.

5 相关工作

5.1 软件工程中的异步交流研究
邮件列表经常被用于协调开发和用户支持活动 [62−64] . 自 21 世纪初以来, 学界围绕邮件列表展开了诸多研究,
内容涵盖知识共享活动的剖析 [64] 以及开发者加入和退出项目的原因探究 [65] . Singh 等人 [63] 的调查显示, 邮件列表
中大约 90% 的内容与解决问题和寻求信息有关, 其余则可归类为社交沟通或功能请求.
问题跟踪系统蕴含有关软件项目的丰富信息 [66] , 这些信息可用于改进软件开发 [44] . Merten 等人 [67] 运用自然语
言处理和机器学习技术, 实现了软件功能请求的自动化检测. Rastkar 等人 [68] 则专注于错误报告的总结, 以自动化
提取问题跟踪系统中的关键信息.
作为社区驱动型问答网站的典范, Stack Overflow 一直是软件工程领域众多研究的焦点. 例如, 分析开发者的讨
论主题和趋势 [6,69−73] 、预测答案质量 [74,75] 和用户参与度 [76] 、识别领域专家 [77,78] , 以及理解其中的社交互动 [55,79] 和
删除问题的相关研究 [80] . 研究人员还利用 Stack Overflow 上的帖子来检测 API 的使用障碍 [81] 、生成 API 规则 [82] ,
以及扩充 API 文档 [83] . 近年随着大语言模型兴起, 也有研究人员对 Hugging Face 社区的问答讨论展开研究, 提出