Joel Madero schrieb:
Hi Joel,
thank you for opening this discussion with your thoughts and suggestions.
To avoid misunderstandings: my critics at current plans does not mean
that I do not want any automated mass cleanups. I would appreciate to
get rid of lots of hopeless reports with few "costs".
Although I believe we could solve some part of the problem if we would
invest the time discussing here into bug reviews, it might be useful to
do some very careful preparation, so that in future such mass closes can
be done effectively and with few preparation, because the work already
has been done here.
Some thoughts (I'm still sorting and prioritizing)
I) Such an action should avoid collateral damages as effective as
possible. A promising approach might be to find an effective query with
good accuracy for hopeless Bug reports where we can expect that there
will be no useful reaction from reporter, AND where we can be sure that
the NEEDINFO is appropriate and not only caused by laziness of reviewer
At least I can say for me that sometimes I am interested and tough and I
find a real bug even with a very rare report. And sometimes I try to get
a better bug description because I want to save some work. I will not
forget these Bugs, they are in my hold-file, but if I saw a low
priority, it might take a year or so until I get back to the bug. And
this might cause unnecessary work for other reviewers, may be hundreds
invest half a minute, see that someone is involved, leave again, and so
we loose some hors every year in such 1 bug.
II) Such a mass close should really terminate any action on a closed bug
(except reporter redelivers useful info). The last mass close in August
2012 also closed lots of appropriate enhancement requests. We should
avoid such a mistake in future.
III) I prefer to close Bugs immediately with a very polite text
encouraging the reporter to reopen the bug if he can contribute more
detailed and precise due to
<http://wiki.documentfoundation.org/BugReport>. I am pretty sure that
those who would have improved their bug description after a "first
strike" will understand our reasons and simply reopen the Bug with
better info. And for the other ones the first and second strike would be
wasted energy.
IV) We need a very polite and encouraging text for first strike bug
closing.
V) Remaining concerns
We can be as careful as possible, it's inevitable that we will close
some bugs reported from real experts with appropriate info, but only the
bad luck that the of us who reviewed was expert for something else. That
makes us looking like idiots.
My method of resolution:
I will start with a suggestion for a query with reasoning why I believe
that that should be done that way soon, and then we can integrate more
proposals for optimization step by step.
We will see to where that leads, and the rating how nearby the optimum
that is at least for me is decisive what of Joels suggesteions might be
the best.
CU
Rainer
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [email protected]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
