vlambda博客
学习文章列表

像GitHub这样的社交编码网站使开发者能够轻松地对多个问题发表评论，并在问题之间切换讨论，即多个讨论。同时讨论多个问题可以提高开发人员的工作效率。然而，多方讨论也有赖于开发者合理分配时间和精力，这可能会对问题的解决产生不同的影响。因此，研究多重讨论如何影响问题的解决是一个有意义的研究问题，它可以帮助开发人员了解在不同问题之间切换讨论的好处和局限性。在本文中，我们使用定量方法初步研究了GitHub项目中多次讨论对问题解决的影响。首先，我们收集并分析了631个GitHub项目的数据，以探索多讨论如何影响项目问题的平均解决延迟。此外，我们还开发了一种测量开发人员讨论切换行为的速率和广度的方法，并使用回归建模来研究讨论切换如何影响单个问题的解决延迟。我们发现，多人讨论是GitHub项目中开发人员的常见行为。此外，多次讨论与缩短项目的平均问题解决延迟有关。然而，在单一问题解决过程中，更多参与者的讨论切换往往会带来更长的问题解决延迟。我们的研究激发了进一步研究多重讨论的必要性。

GitHub是领先的开源开发网站之一，截至2018年6月，它已经托管了超过8500万个存储库。通过实现社会编码的概念，GitHub创建了一个开发人员友好的环境，使开发人员能够建立网络、协作和推广他们的项目[1]。这种社会化编码还带来了增强的问题解决过程，在这个过程中，开发人员可以轻松地参与报告和讨论问题。因此，开发人员在多个问题上发表评论并在不同问题之间切换讨论的情况并不少见。在我们的研究中，我们将其定义为多重讨论。

多重讨论是当今敏捷软件开发时代的一种常见现象，可以被视为一种多任务处理。多任务处理旨在优化人力资源分配并动态调整任务优先级，这是开发人员停止处理任务，切换到另一个任务，并根据需要或按计划返回其原始任务的能力。最近，许多研究探索了GitHub项目中的多任务处理。然而，他们的主要目标是调查开发人员如何在项目之间进行多任务处理，即在项目级别。据我们所知，目前还没有关于开发人员如何在问题之间进行多次讨论（即在问题级别）的研究。一方面，多重讨论可以提高开发人员的工作效率，帮助他们同时讨论多个问题。另一方面，多方讨论依赖于开发者合理分配他们的时间和精力，这可能会有所不同。不同的策略和多方讨论的焦点可能会对问题解决过程产生不同的影响。在开发人员社区中，多方讨论是一种常见的行为吗？多次讨论如何影响问题的解决？回答这些问题可以帮助开发人员了解在讨论和关注问题之间切换时的好处和局限性。

在本文中，我们使用定量分析方法对GitHub中的多重讨论问题进行了初步研究。在数据收集过程中，我们从631个大型项目（每个项目包含3000个问题）中获取问题数据。我们通过计算多讨论参与者的问题百分比来研究多讨论的基本用法。接下来，为了探索多重讨论如何影响问题解决，我们从两个层面进行了调查，即项目层面和问题层面。在项目层面，我们试图通过回归建模项目中的多次讨论百分比与该项目的平均问题解决延迟之间的关系，研究多次讨论如何影响项目的总体问题解决。在问题层面，我们旨在分析开发者在问题中的讨论切换行为如何影响该问题的解决，方法是制定讨论焦点的衡量标准，并对讨论焦点和单个问题解决延迟之间的关系进行回归建模。最后，我们提炼出一些对研究人员和开发人员的启示。

虽然多讨论是开发人员在实践中的一种常见行为，但很少有人对其进行研究。为了填补这一研究空白，我们旨在探索开发者如何进行多重讨论，以及多重讨论对问题解决的影响。具体来说，为了更好地理解多重讨论用法，我们要求：

RQ1：参与者在其中讨论了多少问题？

为了回答这个问题，我们收集了631个大型GitHub项目的问题数据，并计算了有多个讨论参与者的问题的百分比。接下来，我们试图研究多重讨论如何影响问题的解决。我们提出以下两个问题：

RQ2：多次讨论如何影响项目的整体问题解决？

我们从GitHub的开源项目中收集数据。在这项工作中，我们从GHTorrent获得数据。它致力于创建一个可扩展的、离线的数据镜像，该镜像通过Github REST API提供。在我们的研究中，为了更好地调查多个讨论中的问题，我们只选择历史数据中有3000多个问题的大型项目。请注意，我们只考虑一般的问题，我们不考虑拉请求在本研究中。此外，在删除了从其他项目中派生出来的项目或从GitHub中删除的项目后，我们收集了631个项目的信息，以用于下一个数据收集过程。请注意，在我们的研究中，我们只考虑那些不是项目成员的开发人员，也就是外部贡献者。我们不考虑项目成员，因为他们很可能在问题上进行多方面的讨论，例如回答问题记录的问题，并与外部贡献者讨论。表一显示了631个项目的总体统计数据。平均而言，每个项目中的问题数量为6649个（中位数为5259个；最大值为18614个），分支数量为2275个（中位数为1034个；最大值为93397个）。所以我们数据集中的项目都是大型的著名项目。请注意，在我们的RQ3中，我们只选择了两个著名的大型项目进行研究，即Rails2和TrinityCore3。因为他们在GitHub上非常有名，有很多star和分支，他们都是活跃的项目，有很长的生命周期，有很多经验丰富的开发人员，还有大量的历史数据。

考虑到开发者Y在第i周的情况，Pi是Y参与的问题的问题ID，是Y在第i周参与的问题总数。因此，focus值越高，开发人员对单个问题的讨论就越少。例如，图3显示了两个计算开发人员A和开发人员B之间的focus的示例。A和B在一周内讨论了五次问题。但这五次讨论在A和B之间的分散程度不同。A讨论了三个不同的问题，即#17257、#19237和#39044，并在#17257一周内讨论了三次。B讨论了四个不同的问题，即#17257、#19237、#22688和#39044，他对问题的讨论在一周内相对分散。所以A的focus（值为0.73）高于B的focus（值为0.52）。

• avgIssueLatency：项目中的平均问题解决延迟，以分钟为单位，代表总体问题解决速度。在我们的研究中，我们只考虑发行期到第一个截止日期之间的问题潜伏期。

           该模型的控制变量和自变量描述如下：

• mdPerc：包含多人讨论的开发人员的问题的百分比，作为项目多人讨论使用的代表。

• nIssues：项目中的问题总数，代表项目的总体工作量

• nMember：项目成员总数，代表项目的人力资源

• nForks：项目中的分支总数，作为项目关系网络的代理

• nStars：项目中的明星总数，代表项目的受欢迎程度。

   

2） 单问题解决模型：其次，为了研究多讨论对单问题解决的影响，我们建立了两个多元线性回归模型（使用PackageMin R），即Rails单问题解决延迟模型（Model2）和Trinitycore单问题解决延迟模型（model-3）。这两个模型的因变量是：

• ingleIssueLatency：单一问题的问题解决延迟，以分钟为单位，作为单一问题解决速度的代理。

两个模型的自变量描述如下：

• NComments：本期评论的总数，代表本期的讨论长度

• nDevelopers：参与该问题的开发人员总数，代表该问题的人力努力。

• subMemberTag：二进制，如果问题提交者是项目成员之一，则为True。

• hasLabelTag：二进制，如果此问题至少有一个标签，则为True

• textLen：问题文本（标题和描述）的总字长，代表问题的复杂性。较长的描述可能表明问题的复杂性更高或文件更完善。

• multi-discussingTag：二进制，如果此问题至少有一个multi-discussing参与者，则为True。

        3） 开发者关注模型：第三，为了探索开发者的讨论焦点如何影响问题解决，我们构建了两个模型，即Rails开发者关注模型（Model4）和Trinitycore开发者关注模型（model-5）。如前所述，这两个模型的因变量仍然是单一延迟。两个模型的自变量分别为注释、nDevelopers、subMemberTag、hasLabelTag、textLen和

• avgFocus：本期讨论的所有开发人员的平均价值。请注意，我们不考虑项目成员。

在我们的模型中，必要时，我们对因变量进行对数变换，以稳定其方差并降低异方差。我们还删除了高度倾斜变量的前2%数据，以控制异常值并提高模型的稳健性，符合最佳实践。在我们的模型中，衡量预测集多重共线性的方差通货膨胀因子是安全的，低于3。对于每个模型变量，我们报告其系数、标准误差、显著性水平和平方和（通过方差分析）。我们认为这些系数值得注意，如果它们有统计学意义的ATP＜0.05.对于广义混合效应模型，使用边际（R2m）和条件（R2c）确定系数对混合效应线性回归模型拟合进行评估。R2MD描述了仅由固定效应解释的方差比例，R2CD描述了由固定效应和随机效应共同解释的方差比例。

1） 研究1：为了研究多重讨论如何影响单一问题的解决，我们在数据集中选择了两个著名的大型项目，Rails和TrinityCore。基于两个项目的问题，我们首先比较了多讨论问题和没有多讨论参与者的问题解决延迟的差异。从统计数据来看，Rails项目中有4207个（65.4%）问题，其中包括多人讨论的开发者；TrinityCore项目中有7208个（78.5%）问题，其中包括多人讨论的开发者。这两个项目中的其他问题没有涉及多个开发人员。特别是，我们要问：

RQ3：在多个讨论的问题和没有多个讨论的问题之间，单个问题解决延迟是否存在差异？

A.Rails问题。图6显示了多个讨论问题和无多个讨论问题之间的问题解决延迟差异箱线图。Rails项目中每个多讨论问题的平均问题解决延迟为131。1天（中位数为25.9天），而每个非多次讨论问题的问题解决延迟为16天。4天（中位数为1.9天）。惠特尼·曼·威尔科克森（WMW）检验表明，这两个数据集之间的差异显著（W=1.9×106；p<2.2×（10）−16). 这种分析没有考虑到许多可能的混淆，所以为了更精确的发现，我们转向多元回归分析。表III显示了Rails问题解决延迟模型（model-2）的结果。该型号的调整配合R2=0.19。

B.三一核心问题。图7显示了TrinityCore项目中多讨论问题和非多讨论问题之间的问题解决延迟差异箱线图。TrinityCore项目中每个多讨论问题的平均问题解决延迟为231。在TrinityCore项目中，每个问题的平均延迟时间为6天，每个问题的平均延迟时间为39天。8天（中位数为1.4天）。WMW检验表明，两个数据集之间的差异显著（W=8.4×106；p<2.2×10）−16)。表四显示了三一核心单一问题解决模型（model-3）的结果。该型号的调整配合R2=0.23.正如预期的那样，控制多重讨论是重要的，并且对单一问题解决延迟具有最大的积极影响。

根据研究结果，我们发现，在TrinityCore项目中，多次讨论的问题往往比没有多次讨论的问题具有更长的问题解决延迟。因此，我们发现，在Rails和TrinityCore项目中，多次讨论的问题往往比没有多次讨论的问题具有更长的问题解决延迟。

然而，我们的结果也表明，多次讨论往往会对单一问题解决（RQ3）产生负面影响。我们知道，多方讨论依赖于开发商合理分配时间和精力，这可能会对不同问题的解决产生不同的影响。在RQ3中，我们发现，随着开发商讨论的焦点分散，项目中单个问题的解决时间逐渐增加。换句话说，如果开发人员应该关注这个问题，但是有太多的多重讨论行为，这往往会对这个问题的解决产生负面影响。多次讨论可以提高整个项目中问题的解决效率，但对单个问题的影响可能有限。因此，考虑到整体项目问题解决方案和单一问题解决方案，开发人员在进行多个讨论时可能会存在权衡，这需要在未来进一步探讨。

B.有效性威胁。

我们的数据集是631项目，因此，它可能并不代表所有现实世界项目的宇宙。此外，我们将这项研究的重点放在GitHub上发现的开源项目上，这些项目可能并不完全适用于每个软件项目。尽管如此，据我们所知，GitHub是最大的项目数据库，对可以托管的项目类型没有限制。但我们的结果可能不适用于其他非开源项目的商业项目。在我们的回归模型中，我们的因素可能被认为是不完整的。例如，在rails项目的问题解决延迟模型中，我们只考虑了问题文本的长度，没有分析它们的语义。在未来的工作中，我们将进一步分析它们的语义。

在GitHub这样的开源生态系统中，开发人员跨问题进行多人讨论的现象很常见。本文探讨了多元讨论与问题解决之间的关系。我们收集和分析631个GitHub开源项目的数据。我们的研究结果表明，多次讨论往往会对项目的整体问题解决产生积极影响，即多次讨论越多，平均问题解决延迟越短。然而，多个讨论似乎对单个问题的解决有负面影响，即更多的讨论切换可能会带来更长的问题解决延迟。我们还提炼出一些对研究人员和开发人员的启示。

在未来，我们将尝试对多个讨论进行更深入的调查，以建议开发人员每周关注多少问题可以最有利于提高开发效率。