{'fraction_non_alphanumeric': 0.037108125399872044, 'fraction_numerical': 0.003198976327575176, 'mean_word_length': 4.265993265993266, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Studying the fix-time for bugs in large open source projects

Background: Bug fixing lies at the core of most software maintenance efforts. Most prior studies examine the effort needed to fix a bug (fix-effort). However, the effort needed to fix a bug may not correlate with the calendar time needed to fix it (fix-time). For example, the fix-time for bugs with low fix-effort may be long if they are considered to be of low priority.
 Aims: We study the fix-time for bugs in large open source projects.
 Method: We study the fix-time along three dimensions: (1) the location of the bug (e.g., which component), (2) the reporter of the bug, and (3) the description of the bug. Using these three dimensions and their associated attributes, we examine the fix-time for bugs in two large open source projects: Eclipse and Mozilla, using a random forest classifier.
 Results: We show that we can correctly classify ~65% of the time the fix-time for bugs in these projects. We perform a sensitivity analysis to identify the most important attributes in each dimension. We find that the time of the filing of a bug and its location are the most important attributes in the Mozilla project for determining the fix-time of a bug. On the other hand, the fix-time in the Eclipse project is highly dependant on the severity of the bug. Surprisingly, the priority of the bug is not an important attribute when determining the fix-time for a bug in both projects.
 Conclusion: Attributes affecting the fix-time vary between projects and vary over time within the same project.