背景：

      在实际软件开发过程中，软件的release大致可以分为两种：feature-based（一定功能实现后进行release）和time-based（一定时间进行release）。一般开发者都希望自己的贡献（代码、修复bug等）能够尽快的被纳入进稳定的release中，这样可以提高他们的声誉。feature-based的release方法由于具有时间不确定性，一旦突然通知将要release了，开发者就得赶代码赶材料。而time-based的release方法因为知道即将release的时间，开发者可以很好的有针对性的进行准备（即便错过了一次release，下次release的时间也大概知道）。

      有规律的release方法可以使开发者清楚了解自己贡献会在很短时间内被采纳，也可以促进用户反馈，并且有规律的release也会增加外围开发者去参与贡献。

      传统的有规律的release一般也都是管理者人工管理，形成计划文档或者自己把握，对于其他开发者（尤其外围开发者）是不可知的，他们不知道这个软件下一次release是什么时候？而在目前大规模群体协同进行软件开发的背景下，会有大量的外围开发者希望自己的贡献能够尽快被纳入稳定的release中，这就使得release predictable显得尤为重要。

      之前我对github中milestone进行了初步分析，可以认为milestone就是一种release predictable的工具。管理者可以有效地对issue、pull-requests进行管理，开发者也可以根据时间点合理安排工作。通过milestone，我们可以知道哪些贡献被纳入进下一个release，这些贡献需要逐重解决（统计发现有milestone标记的issue的评论数、参与人数都比没有milestone标记的要多，评论时间间隔要小，说明讨论更加频繁）。

拟研究问题：

1. 从贡献者角度：什么样的贡献可以被纳入release（进一步，纳入稳定release）？能否自动判断？

我们认为被纳入release的issue应该是好的重要的，那么我们需要分析有无被纳入release的issue或pull-requests的特点，从而指导开发者更好地贡献代码或修复bug。

初步进展：除了通过milestone标记判断，在Rails中，我利用commit信息，可以回溯找到对应的pull-request，从而找到那些没有milestone标记但被纳入release的pull-requests。进一步，通过判断commit中“Fixes #”以及pull-requests中的“#”链接，可以找到那些没有milestone标记但被纳入release的issues信息。在此基础上，分析有无纳入release的issue的特点，进一步可以设计算法，实现自动判断，当新的issue或pull-requests来后，可以自动添加milestone或标签，告诉管理者可以放到下一个release中。

3. 管理者角度：怎样合理设置release时间？

统计发现，github中大部分的milestone建立后都没有设置截止时间，即便设置截止时间的也有很多最后超过了的。我们能否通过分析那些著名项目的milestone特点，来为管理者提供建议：什么时候可以开始准备下一个release了？大概需要准备多久？进一步进行自动预测。

可行性分析:

1. 虽然本身有milestone标记的issue数目很少，但通过commit信息回溯关联，可以得到足够的分析样本，来分析有无纳入release的issue特点；结合文本信息，通过训练也可以实现简单的issue分类或milestone标记；

2. 通过前期的分析，github中那些著名的项目的milestone设置是存在一定规律性的，加上通过1补充的issue与release信息，应该可以实现对milestone时间的预测；

与开题及出国工作的联系：

1. 目前开题还是想做开源社区中贡献的汇聚与管理，这个大点对于需求的汇聚和管理同样适用，汇聚包括很多层面，项目内汇聚、项目间汇聚、跨社区汇聚。项目内汇聚主要研究如何激发开发者参与讨论、进行贡献，项目间和跨社区汇聚主要分析汇聚现象和规律。

2. 管理层面，主要研究如何更好的管理贡献。milestone就是管理的工具，目前github中milestone的使用还存在一定的问题（用的不多，用的不好），所以想通过这部分研究来看是否形成一些有价值工作。

3. release和测试过程密不可分，Rails的release流程就明确说明，要先通过CI等测试才能release，所以CI应该是release的一个重要因素，我觉得这个点应该可以和国外那边工作结合起来，但具体怎样结合还需要进一步思考。

背景：

      在实际软件开发过程中，软件的release大致可以分为两种：feature-based（一定功能实现后进行release）和time-based（一定时间进行release）。一般开发者都希望自己的贡献（代码、修复bug等）能够尽快的被纳入进稳定的release中，这样可以提高他们的声誉。feature-based的release方法由于具有时间不确定性，一旦突然通知将要release了，开发者就得赶代码赶材料。而time-based的release方法因为知道即将release的时间，开发者可以很好的有针对性的进行准备（即便错过了一次release，下次release的时间也大概知道）。

      有规律的release方法可以使开发者清楚了解自己贡献会在很短时间内被采纳，也可以促进用户反馈，并且有规律的release也会增加外围开发者去参与贡献。

      传统的有规律的release一般也都是管理者人工管理，形成计划文档或者自己把握，对于其他开发者（尤其外围开发者）是不可知的，他们不知道这个软件下一次release是什么时候？而在目前大规模群体协同进行软件开发的背景下，会有大量的外围开发者希望自己的贡献能够尽快被纳入稳定的release中，这就使得release predictable显得尤为重要。

      之前我对github中milestone进行了初步分析，可以认为milestone就是一种release predictable的工具。管理者可以有效地对issue、pull-requests进行管理，开发者也可以根据时间点合理安排工作。通过milestone，我们可以知道哪些贡献被纳入进下一个release，这些贡献需要逐重解决（统计发现有milestone标记的issue的评论数、参与人数都比没有milestone标记的要多，评论时间间隔要小，说明讨论更加频繁）。

拟研究问题：

1. 从贡献者角度：什么样的贡献可以被纳入release（进一步，纳入稳定release）？能否自动判断？

我们认为被纳入release的issue应该是好的重要的，那么我们需要分析有无被纳入release的issue或pull-requests的特点，从而指导开发者更好地贡献代码或修复bug。

初步进展：除了通过milestone标记判断，在Rails中，我利用commit信息，可以回溯找到对应的pull-request，从而找到那些没有milestone标记但被纳入release的pull-requests。进一步，通过判断commit中“Fixes #”以及pull-requests中的“#”链接，可以找到那些没有milestone标记但被纳入release的issues信息。在此基础上，分析有无纳入release的issue的特点，进一步可以设计算法，实现自动判断，当新的issue或pull-requests来后，可以自动添加milestone或标签，告诉管理者可以放到下一个release中。

2. 管理者角度：怎样合理设置release时间？

统计发现，github中大部分的milestone建立后都没有设置截止时间，即便设置截止时间的也有很多最后超过了的。我们能否通过分析那些著名项目的milestone特点，来为管理者提供建议：什么时候可以开始准备下一个release了？大概需要准备多久？进一步进行自动预测。

可行性分析:

1. 虽然本身有milestone标记的issue数目很少，但通过commit信息回溯关联，可以得到足够的分析样本，来分析有无纳入release的issue特点；结合文本信息，通过训练也可以实现简单的issue分类或milestone标记；

2. 通过前期的分析，github中那些著名的项目的milestone设置是存在一定规律性的，加上通过1补充的issue与release信息，应该可以实现对milestone时间的预测；

与开题及出国工作的联系：

1. 目前开题还是想做开源社区中贡献的汇聚与管理，这个大点对于需求的汇聚和管理同样适用，汇聚包括很多层面，项目内汇聚、项目间汇聚、跨社区汇聚。项目内汇聚主要研究如何激发开发者参与讨论、进行贡献，项目间和跨社区汇聚主要分析汇聚现象和规律。

2. 管理层面，主要研究如何更好的管理贡献。milestone就是管理的工具，目前github中milestone的使用还存在一定的问题（用的不多，用的不好），所以想通过这部分研究来看是否形成一些有价值工作。

3. release和测试过程密不可分，Rails的release流程就明确说明，要先通过CI等测试才能release，所以CI应该是release的一个重要因素，我觉得这个点应该可以和国外那边工作结合起来，但具体怎样结合还需要进一步思考。