1.现在已处理的可利用信息有：项目间贡献者（提交过commit信息）的交集、pull request核心开发者交集(pr的合并或关闭，重开)、issue核心开发者交集(issue的合并或关闭，重开)、项目owner的follow关系。

其中项目owner的follow关系数量极少，只有20条关系，而且大都不准确直接忽略。

• 贡献者交集数量>=5的关系数量：1152    >=1 :  275844
• pr核心开发者交集数量>=5的关系数量 ：145   >=1 : 2509
• issue核心开发者交集数量>=5的关系数量 ：102  >=1 : 715

2.两种做法：

• 选出和原项目A有依赖关系的多个项目B、C，采取投票制，训练回归模型确定项目影响权重。Acc(A) = W0 * H(B) + W1 * H(C) ,H(B)表示B的模型对A的数据的分类结果。W0、W1又可以通过pr和issue交集等信息确定，即W0 = X0 * Count(Pr) + X1 * Count(Issue) + X2 * Count(Contributors),整个可以看做是线性回归问题，最终确定权重X0,X1,X2。
• 根据依赖关系强度按比例抽取各个项目的issue数据，最终综合数据训练模型对原项目A进行预测

3.先采取第一种做法

• 由于数据计算量较大，首先将所有项目的模型和vocab存储下来
• 采取随机抽一个项目对原项目进行跨项目预测作为baseline,之后通过引入项目依赖关系等先验知识，再次对原项目预测分类比较结果

1. 实验数据：issue > 400 且 bug_ratio 在（0.2-0.8）:  874个项目。

2. 目标： 目前项目内的bug分类已经有了结果，下一步工作是找到多种方法构建项目依赖关系网络，对某一个项目，找到相关联的项目族群，并使用项目族群的issue训练的模型对该项目issue分类，看最终得到的结果能否逼近使用项目本身的数据进行分类的准确度。

3. 如何构建项目间的关系网络？

• 参考论文MSR15：【Ecosystems in GitHub and a Method for Ecosystem Identification using Reference Coupling 】

1. issue, pull request, and commit 的评论信息中对其他项目的交叉引用（文本链接）反映了项目间的技术依赖，关联权重为项目间交叉引用的数量。

2.项目的核心成员（owner）的开发行为能够反映项目的技术依赖。     

【a】项目 A的owner follow 项目 B的owner，则A & B有关联，关联权重0表示没有关联，1表示单向follow，2表示双向follow

【b】任意一个项目的owner star了项目A和B，则A & B有关联，关联权重有同时star这两个项目的owner数量决定。

3.项目的外围贡献者(Contributors )不能反映项目间的技术关联。

• 从某一类入手，比如ruby的或python的项目，另外现在github上ruby的项目有直接dependents数据，显示前100页依赖于该项目的项目数据，可以直接爬下来分析一下，看能否构建关系网络，但是874个项目中ruby的项目只有43个，可能会很稀疏。
• 关于comment信息，ghtorrent中有commmit的comment信息，但是只有前256个字符，可能还是需要重新爬取，issue和pr也需要重新爬，现在可以利用爬取的时间先分析owner的开发行为。
• 其他可以考虑的还有编程语言，项目描述的文本相似度等。

1.初步筛选项目并爬取issue数据

• 选取带label的issue>100 的项目（12797个）
• 爬虫爬取得数据最终包含11675个项目，有一些项目有错误已不存在，对应带标签的帖子数为6414872条。

2.网页数据预处理

    Github api接口中的issue id和project id和后台数据库中的id没有联系。通过issues表单的repo_id和issue_id匹配爬虫数据，且一个issue可能有多个标签，将issue_id和label插入新表

issues_labels。

3.进一步筛选项目

• 选取表示issue类型的标签格式比如'kind:*'，'type: *'等8种格式
• 截取后半段指示具体issue类型的标签，选出公有目录类型（前半段，比如'type:','kind:'等）大于5的作为issue具体类型标签(比如'bug','feature'等)，对于一些不是指示类型的标签直接人工过滤掉（比如'duplicate','test','support'）
• 然后扩展到包含该具体类型标签的所有实际标签。包含大概4222个。
• 统计覆盖这些标签的issue数量（2493903条），得出取前40个标签（2214117条）可以覆盖88.8%的帖子数。
• 将这40个标签划分为'bug'和'non-bug'，然后对issue进行标注。
• 对于既是'bug'又是'non-bug'的数据大概64378条，占比2.9%，影响不大所以全部归为'bug'类型。

    最终得到1106332条bug，1107785条non-bug。

    [b]统计项目带标签的issue数量及bug比率

• 有带标注的issue：10564个项目
• issue>500 ： 722个项目
• issue > 500 且 bug_ratio 在（0.2-0.8）：611个项目
• issue > 400 且 bug_ratio 在（0.2-0.8）:  874个项目
  

错误记录：

1.Incorrect string value: '\xF0\x9F\x98\x84\xF0\x9F

对应UTF-8编码格式中的4字节编码。正常的汉字一般不会超过3个字节，这里出现4个字节实际上是它对应的是智能手机输入法中的表情。如果想存储4个字节的必须用utf8mb4类型。不而要使用utf8mb4类型，首先要保证Mysql版本要不低于 MySQL 5.5.3。

更改mysql表格字段编码格式，并且在python处理脚本中读取数据时也要设置为utf8mb4。

conn = pymysql.connect(host='127.0.0.1', port=3306, user='root', passwd='123456', db='ghtorrent_2017_5', charset='utf8mb4')

ALTER TABLE issues CHANGE body body MEDIUMTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL;

2.python解析网页数据时，ast.literal_eval()能将数据还原成它本身或者是能够转化成的数据类型。并且相较于eval(),会进行类型安全检查