On Thu, Oct 3, 2013 at 9:54 AM, Ming Wen <civiresea...@gmail.com> wrote:
> Dear Sir/Madam,
>
> I am a Ph.D candidate student in Zhejiang University, China, and currently,
> I am a visiting student in Hong Kong University of Science and Technology.
>
Hello Ming Wen,
The first thing to understand is that new bug reports can come from
two main sources:
1) Bug reports submitted by members of the Apache OpenOffice project.
and
2) Bug reports submitted by OpenOffice users.
Reports that come from project members tend to be "high quality"
reports, with most of the fields entered correctly. Reports that come
from end users, are more "raw". They often incompletely or
incorrectly categorized. You might be able to make a distinction
here if you look at how many bug reports were entered by a user.
Users who enter more bug reports are more likely to be familiar with
our process. Those who enter only a single report are probably users.
There are three main reasons why Bugzilla fields are changed:
1) When we correct a user-submitted defect report. For example, to
set the correct product and component fields.
2) To reflect the changing status of the report within the process of
fixing bugs and publishing new releases. For example, a bug will move
from unconfirmed to confirmed to fixed to resolved. Or some reports
move from unconfirmed to closed if they cannot be reproduced.
3) Bulk change operations from Bugzila admins. For example, we
occasionally remove, move or combine components, causing us to
re-categorize many defects in one large operation. Or we may
unassigned old issues that no one is currently working on. These
"house cleaning" operations should not be confused with #2 above.
Maybe you can detect and ignore transactions from me ("robweir") when
the operations are clearly batch operations, e.g., a high transaction
rate for the same kind of change.
> Currently we are working on a project about “characterizing and predicting
> which bug report fields would get reassigned”. We have collected all the bug
> reports on Bugzilla for Openoffice and plan to evaluate our method on this
> dataset. In order to make this work really useful, we would like to hear
> some suggestions from experience software developers.
>
> We know that you are an expert in this area and have fixed a large number of
> bugs on Bugzilla, so we are very interested in your opinion on this work. In
> fact, we just have one short question to ask:
>
> 1.We notice you have reported the bug 121357 about Spell check removes
> periods (https://issues.apache.org/ooo/show_bug.cgi?id=121357). We found
> that the Severity, Component, Version and Product fields have been
> reassigned.
>
> Could you kindly tell us why these fields of the bug report are changed?
>
Two changes:
1) The first set of changes, on 2012-11-15, was me, in the role of QA,
testing a new bug report and confirming it.
2) The second set of changes, 2013-02-24, occurred during a
restructuring of the product/component hierarchy. We removed
"linguacomponent" as a top-level product and moved the spellchecking
component under the "general" product. This was to simplify things
for end users when submitting bug reports.
> And could you kindly give us some advices about the root cause about some
> fields in the bug reports (e.g., severity, priority, platform, os, product,
> component, fixer, etc) get reassigned?
>
As covered above, three main causes: new report correction,
progressing in the process, and admin batch operations.
> Do you think it would be useful if there is a tool to predict which bug
> report fields would get reassigned?
>
It will be tricky because of the three causes. I think it would be
hard to predict the admin restructuring or the process-related
changes. But it might be possible to evaluate a "raw" user submitted
report and predict what fields will be changed. Perhaps hints can be
found in the text of their defect summary?
Another area that might be interesting is detecting duplicate reports,
i.e., independent bug reports that are related to the same underlying
bug.
> We would very appreciate your help. Thank you and wish you a good day!
>
> Yours Sincerely,
>
I wish you success with your research! Let me know if you have any
other questions.
Regards,
-Rob
> Ming Wen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
