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

有感于最近围绕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