Hi
Maybe it is useful to add a more specific bug categorization as a search
criteria. The first thing that bothers a user is e.g. that some static text
is not shown properly in a specific dialog or that the text search
function does not work as expected. That could be two categories of
bugs. A search for 'search function' issues may produce a manageable
result list of issues that is easily overlooked thus it may be
unnecessary to enter any keywords for that query. Though the issue
search form has the criteria 'subcomponent' that is quite abstract. E.g.
'ui' comprises all kinds of dialogs, toolbars, buttons etc. It has
little value for reporters for narrowing their queries. A query for
'Word processor' + 'ui' produces 1491 results. It seems to be
developer-oriented. Perhaps it would more appropriate to provide quite
specific categories like 'text search function / search dialog', 'page
preview', 'load / save functions + load/save dialog' , 'footnote
handling', 'customize dialog', 'keyboard binding', 'statusbar' etc.
Jörg
Jörg Walter wrote:
Hi
I suggest one simple to do improvement:
Add UNCONFIRMED to the default issue search criteria.
It makes no sense not to search the unconfirmed issues when looking for
duplicates since there seem to be quite many unconfirmed low ID issues.
I recently added it to my default criteria after producing some
duplicates just because of not having searched the unconfirmed issues.
Joerg
Joerg Barfurth wrote:
Hi,
Samphan Raruenrom wrote:
We submited many issues due to our work providing free web-based
technical support for OOo (and some other OSSes) at
www.thaiopensource.org, which require us
to submit every bugs that the users found.
A job that we like because it helps enhancing OOo (esp. for Thai).
Thanks.
We submit many duplicates! :-)
We always do a lot of search before submitting an issue.
However, searching in IssueZilla to see whether the bug
has been reported is not very effective. The term that was
used to report the bug may be different from the one we
use to search, though we always try many terms.
The reporter may report different aspect of the problem,
seeing the problem from different angle, may not put
keyword in the subject or the word may have many
synonyms.
You can search the description, not only the subject, but admittedly
that is much slower.
And I don't think you can fix the problem that people use very
different wording to describe one issue.
I suspect many have encounter the very same situation.
There are 9600 duplicates per all 60000+ issues.
This is 16% which is very high?
It is fine if you give it a decent try. But there is only so much you
can do from the outside. Handling duplicates causes relatively little
work. It is still best if it isn't overloaded developers or core QA
who need to do this. So it is annoying to see duplicates which can be
found trivially, e.g. by searching for their summary. But where
wording or perception differs, the developers are usually positioned
best to find duplicates, as they already own the existing issue. This
works well, unless duplicate issues end up with different owners.
I also suspect that 'duplicate' is sometimes overused by developers,
in that they close as duplicate a bug that has the same cause
underneath, but different symptoms. In that case it is the same bug
from a developer perspective, but it is not duplicate from an end-user
and QA perspective.
Is it possible to enhance the search issue feature?
It probably is possible technically. But it is unlikely to be possible
within the constraints of SourceCast...
Ciao, Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
