由young 更新于 01/20/2016 20:51
背景:
在实际软件开发过程中,软件的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的一个重要因素,我觉得这个点应该可以和国外那边工作结合起来,但具体怎样结合还需要进一步思考。