 |
|
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 |
