Locality of Fixing Activity
Analyzing several bug reports fixed by the same person in our datasets, we found
that (s)he tends to have recent fixing activities. For example, bug reports
#312322,
#312291,
#312466, and
#311848 were
fixed by the same fixer Darin Wright in two days 05/10 and 05/11/2010. We
hypothesize that, the fixing activity has locality: the recent fixing
developers are likely to fix bug reports in the near future.
To validate this hypothesis, we have conducted an experiment in which we
analyzed the collected datasets to compute how often a fixer of a bug report is
the one who has some recent fixing activity.
First, we chronically sorted the bug reports in a project by their fixing time.
For a bug report b that was fixed at time t by a developer d,
we sorted all developers having fixing activities before t based on their
most recent fixing time. Then, if d belongs to the top x% fixers
of that list, we count this as a hit. Finally, we compute p(x) as the
percentage of hits over the total number of analyzed bug reports. Table 2 shows
the experiment result for all projects.
As seen, it is consistent in all systems that p(x) is rather large even
at small x. For example in Eclipse, at x = 10%, p(x) = 81%
, i.e. in around 81% of the cases, the fixer of a bug report is in the top 10%
of the developers who have most recent fixing activities. At x = 50%,
p(x) exceeds 97% in 6 systems. Note that, at x = 100%, p(x)
could not reach 100% since there are always new fixers who have no historical
fixing activity, thus, (s)he does not belong to the list of developers with
recent fixing activities.
The experiment result confirms our hypothesis on the locality of fixing
activity. This result suggests that: instead of selecting all available
developers as fixer candidates for a bug report, we could select a small portion
of them based on their recent fixing activities. This selection would
significantly improve time efficiency without losing much accuracy.
