From: Jon Date: 2013-04-03T02:10:24+09:00 Subject: [ruby-core:53897] Re: An evaluation of 2.0.0 release On Sun, 31 Mar 2013 14:15:44 +0900 Yusuke Endoh wrote: > Let's look back at 2.0.0 release so that we can do better next time. > I am listing some points. These are based on developer meeting in Japan: > http://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20130223Japan > > Feel free to comment and discuss each point. > If some paticular point seems to be heavily argued, it will be good > to move the item to a separate thread/ticket. Late in the 2.0.0 release cycle, both mame and ko1 spent chunks of time attempting to triage old issues. As a result of the time pressure, many of the triage resolutions were of the "kick the can down the road until the next release" or "quickly close" variety. One tweak that could smooth issue management, and help prevent issue triage from clustering too close to releases, is more aggressive pruning of the ancient issues. As I recall, many issues seemed so old that (a) they appeared irrelevant, and/or (b) the OP appears to have given up, forgotten about the issue, and/or stopped participating. Under the Darwinistic perspective that "if it's truly important, it will get focus", one "fix" is to regularly close (every 2-3 months?) old issues that aren't making forward progress. Prematurely closed issues can be reopened/resubmitted if the OP still feels strongly enough to continue championing the issue. And no, redmine email notification screwups aren't cause for one to stop championing their issue ;) While technical (e.g. - hard-to-implement feature requests) and non-technical (e.g. - over-incent premature closures) problems exist with over aggressive pruning, and one could could slurp the project history into R or python/pandas/matplotlib to create basic stats (mean, sd, histogram, boxplot) on issue metrics via [1] https://bugs.ruby-lang.org/issues.csv?status_id=*&c[]=project&c[]=tracker&c[]=status&c[]=priority&c[]=subject&c[]=assigned_to&c[]=created_on&c[]=start_date&c[]=updated_on frankly, did managing the current batch of old issues harm the 2.0.0 release? Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat. http://thecodeshop.github.com | http://jonforums.github.com/ [1] I wasn't able to extract all the 7600+ open/closed issues this way, but I also didn't spend time tweaking.