关于 bugs.kde.org 的一些想法

adaptee | 2011/10/01

有感于最近围绕bugs.kde.org(下文简称BKO)的一些讨论,写一些自己对于BKO的想法。

客观事实:KDE 的开发者账户数量[1]目前为2513,而 KDE的用户数量应该有百万级别。这个数量对比很重要,所以读下文时请多回想一下。

BKO目前的问题:report 数量过多(23000+),且每周都以400+左右的数量增加(这里没考虑同时关掉的report)

用户对于BKO的抱怨:report 长期得不到解决或者得不到开发者的回应,甚至一两年后仍是 0 comemnt 和 ‘UNCONFIRMED’ 状态。用户觉得自己被开发者忽略了。

开发者对于BKO的抱怨:没有价值的report太多了, BKO没有发挥预期的帮助开发者跟踪问题和安排开发计划的作用,反而成了干扰开发者的噪声, 延缓了开发进度。

我认为两方面的抱怨都非常有道理,不存在谁对谁错的问题。问题的根源在于BKO:BKO上存在太多没有价值的report。这里的没有价值有几种表现形式:

1). 重复的 report: 这个没什么好解释的
2). 语焉不详的 report: 问题表述的含糊不清,也缺乏具体清晰的重现步骤,需要开发者问各种问题
3). 价值很小的crash report : 无法高概率的重现,或是backtrace里没有debug sybmols
4). 错误的报告对象;比如大多数shortcut相关的问题都应该报告给kdelibs,而不是具体的某个KDE程序
5). 不是 bug 的 report: 个人配置问题,或是发行版的问题

我目前只参与了konsole的开发,就列举下konsole的数字来说明这些没有价值的report多到了什么程度。

konsole目前有260个report(绝大部分我认为都是有价值的);过去的90天内,343个针对konsole的report被关闭,这其中大概有50~70个report是有价值并得到修复的,其余的都是没有价值的report。粗略估算的结果是 50%的report都是无益的噪声。有兴趣的读者还可以看一下dolphin目前的174 个 crash report[2] 。情况糟糕的一塌糊涂,我估计里面有价值的不超过50个。

那么该为这些无价值report负责任的是谁?我要给出一个刺耳的看法了:BKO,还有用户。

BKO应该更激进的阻止用户提交无价值的report,譬如在当前版本为4.7.1的情况下,就不允许提交针对4.6.x的report,因为这样的report几乎肯定是重复的,或者已经在最新版本里解决了;另一方面,BKO则应强制用户提供更多的信息,譬如重要的Qt版本,标题和描述不得少于多少字(我见过两个令人吐血的report标题,一个叫samba,一个叫default)。用户应该更谨慎的提交report,先通过发行版的支持渠道来寻求帮助和解答,有足够把握后再考虑BKO.

在理想世界中,清理无用的report是KDE开发者工作的一部分。但是现实世界中这几乎是不可能的任务:清理BKO的成本过于昂贵了,它会吞噬掉开发者大部分原本能用于开发工作的时间。用户提交一个report大概要花掉5分钟的时间,而开发者分析、确认和关闭一个无价值report的平均时间要远多于5分钟。请再回想一下开发者和用户数量的对比,以及我前面估计的无价值report的比率。konsole 最近关闭的这300+的report我大部分都有参与,我个人的感受是花在关闭无价值report上的时间要比写代码的时间多很多,更不要提乐趣上的天壤之别了。

再强调一遍这些无价值的report给开发者、用户带来的负面影响:清理会吞噬开发者大部分的时间; 不清理则成为了BKO里的噪声,而且严重影响开发者的情绪和用户对产品的信心。想像一个只有2、3个人的小团队面临BKO上 600+ 的report时该有多沮丧(我指得是几个月前的konsole),想像用户面对一个report 2000+ 且没人清理report的产品(没错,我指的是目前的plasma)时是否心存疑虑、信心不足。每增加一个无价值的report,就意味着那些有价值的report的解决时间被延后了。

基于BKO的现状,如果真的有提交report的打算,我强烈建议考虑如下事项:

0). KDE版本是否最新? 如果用的是Ubutnu/Fedora/OpenSuSE这样的周期性发行版,基本上都是旧版本,发现的问题基本上都已经被报告过或是解决了, 强烈建议在此步停止。
1). 首先排除个人配置导致问题的可能性
2). 优先从发行版的支持渠道寻求帮助,最好的结果是发行版的开发者确认问题的存在并由他们向BKO提交report
3). 提交前请务必多搜索几遍寻找重复的report,这也许令你觉得麻烦,但是这是在帮助KDE。
4). 标题和内容请务必写的清晰和详细。”xxx crash” 和 “xxx doesn’t work” 这样的标题只比”default”、”samba”略好,千万别这么写。务必写上清晰的重现步骤,即使问题看起来如此简单明显而不需要写明重现步骤
5). 最好附上Qt版本
6). 在comment里讽刺开发者反应迟钝绝对不是个好主意。开发者巴不得解决所有的问题,但是做不到。讽刺只会让开发者感到沮丧和恼火,并在自己的开发计划里降低这个report的优先级

[1] http://websvn.kde.org/trunk/kde-common/accounts?view=markup
[2] https://bugs.kde.org/buglist.cgi?product=dolphin&component=general&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=crash

    11 FEEDBACKS

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Note: Commenter is allowed to use '@User+blank' to automatically notify your reply to other commenter. e.g, if ABC is one of commenter of this post, then write '@ABC '(exclude ') will automatically send your comment to ABC. Using '@all ' to notify all previous commenters. Be sure that the value of User should exactly match with commenter's name (case sensitive).

    This site uses Akismet to reduce spam. Learn how your comment data is processed.