Automatic Summarization of Bug Reports

 

CONTENT:

example : KDE bug report:

https://bugs.kde.org/show_bug.cgi?id=188311

(其中还有很多comments没显示)

构建分类器，对comments中的每一句话（sentence）进行二分类。其中，0代表不选入summary，1代表选入summary。

最终，生成对bug report的答案：

研究问题：

实验方法：

1.找一帮人（10个人），对5个开源项目（Eclipse，Platform，Gnome，Mozilla和KDE）的bug report进行人工的总结，最后对每个bug report，总结出所谓的gold standard summary(GSS)。

2.根据语料库的不同（email，email&meeting data，bug report data），定义统一的特征，分别建立三个分类器。

为什么选择email和meeting data，是因为，他们都属于conversation（类似于对话的形式）的数据。

所谓的conversation features：

特别地，对于第一个分类器，基于email threads:

第二个分类器，基于email threads和meeting：

第三个分类器，基于bug report：

采用一部分bug report拿来做训练，每句话同时由三个人看过。0代表没有一个人将这句话纳入gold standard summary，1代表只有一个人将这句话纳入gold standard summary，以此类推。。。

因此，2和3（≥2）表示为positive sentence。

3.对于同一个（新的）bug report，三个不同的分类器都会生成三个不同的summary。

将其与gold standard summary进行比较，看看哪个更接近gold。

个人观点：

对于bug report的summary，更多应该针对于具体的内容而言，而其中的一些feature，例如，word count，position等显然没有十分丰富的意义，更多应该考虑一些语义方面的信息转化成为可以量化的feature。

 备注：TSE2013