<blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-author" style="font-weight: bold;">Petr Mladek wrote</div>
<div class="quote-message">> I'd change the workflow a little bit by putting the obvious things at the
<br/>> top:
<br/>> - feature requests aka wishlist
<br/>I do not have any strong opinion for this. I think that it is is good to
<br/>be able to discuss features, so "enhancement" bugs in bugzilla might be
<br/>usable.
<br/>>  - add target milestone if a feature is planned already
<br/>This must be done by developer, anyway :-)
</div>
</div></blockquote>
Well, to be clear, I see all this more like how to triage guide, that is why I started with enhancements.
<br/>Target milestone can be set by QA member if feature is available. <a href="https://bugs.freedesktop.org/show_bug.cgi?id=33773#c11" target="_top" rel="nofollow" link="external">https://bugs.freedesktop.org/show_bug.cgi?id=33773#c11</a> for instance.
<br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message shrinkable-quote">> - bugs reported against not supported branches - exclude those at reporting
<br/>> level by disabling old versions in select fields; but what to do when they
<br/>> appear anyway -  mark them as INVALID at triaging? ask the reporter to check
<br/>> in new version? Any comments?
<br/>We need to be more careful here. The current rule is to do NOT modify
<br/>the version picker if you reproduce the problem with newer version. It
<br/>is because it is very valuable to know how the bug is old. It helps
<br/>developers to locate it. So, maybe, we should do it the other way and
<br/>set the field to the oldest version where it was found.
</div>
</div></blockquote>
I was thinking about New bug reports, which should be reported for supported branches only (proposed in <a href="https://bugs.freedesktop.org/show_bug.cgi?id=51070" target="_top" rel="nofollow" link="external">https://bugs.freedesktop.org/show_bug.cgi?id=51070</a>). 
<br/>Unfortunately it depends on <a href="https://bugs.freedesktop.org/show_bug.cgi?id=50198" target="_top" rel="nofollow" link="external">https://bugs.freedesktop.org/show_bug.cgi?id=50198</a>.
<br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message">> - is it Most Frequently Reported - then just dupe it 
<br/>What do you mean by "Most Frequently Reported"?
</div>
</div></blockquote>
Is it at <a href="https://bugs.freedesktop.org/duplicates.cgi" target="_top" rel="nofollow" link="external">https://bugs.freedesktop.org/duplicates.cgi</a> for LibreOffice product. Then it can be handled very quickly, 
<br/>but I see that searching for dupes is already listed on
<br/><a href="http://wiki.documentfoundation.org/BugTriage" target="_top" rel="nofollow" link="external">http://wiki.documentfoundation.org/BugTriage</a><br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message">I would personally enable voting as well but some other people thing
<br/>that it is not objective.
</div>
</div></blockquote>
Unfortunately I discovered <a href="https://bugs.freedesktop.org/show_bug.cgi?id=39739" target="_top" rel="nofollow" link="external">https://bugs.freedesktop.org/show_bug.cgi?id=39739</a>. WONTFIXed by Mr Bielefeld who authored <a href="http://wiki.documentfoundation.org/Vote_for_Enhancement" target="_top" rel="nofollow" link="external">http://wiki.documentfoundation.org/Vote_for_Enhancement</a>, where it begins with "[...] Bugzilla bug tracking system does not support Votes for requests as it is available for OpenOffice.org. Here you find an experimental Voting (or better: statistical online survey), currently with only very few rules and only for Enhancement requests." I am perplexed. How manual wiki voting, adding special keywords to bugs can be better than automated, build-in, out of the box, customizable voting within Bugzilla? Strange. 
<br/>I know that voting is not a recipe to find best bugs to fix/features to implement, but I think that giving an ability to vote (even only for QA team members or LO developers)  would help going forward. I do vote for features in other Bugzillas myself. 
<br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message">You are right, regression are bad and we need to fix them with high
<br/>priority. On the other hand, you still need to compare them with other
<br/>reported bugs and decide what is more annoying for the daily work. We
<br/>could not blindly set the highest priority for a tiny functional problem
<br/>just because it is a regression. As someone said, you could view almost
<br/>any bug as regression, so we need to prioritize them as well.
<br/>I would keep the current approach. Add "regression" into Whiteboard and
<br/>set one level higher priority that you would set for non-regression.
</div>
</div></blockquote>
I disagree. Many people just won't upgrade because of them. Fast query shows 180 opened bugs with regression keyword. Very worrying...
<br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message">It actually helps to prioritize bugs as well. If reporter is not willing
<br/>to provide more information, the problem is probably not that important
<br/>for him.
</div>
</div></blockquote>
Disagree, as providing proper bt is complicated. 
<br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message">Also note that some crashers are reproducible only in very strange
<br/>circumstances. Also some scenarios are very hard to prepare. We just
<br/>need help from reporters in these cases.
</div>
</div></blockquote>
Sure, but IMHO only if bug is not reproducible.
<br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message">If someone change the priority a wrong way, I would ask them not to do
<br/>it, explain that the level is not that important, and change it back. If
<br/>they change it once again, I would leave it as is. Developers would
<br/>filter it themselves :-)
</div>
</div></blockquote>
 I found <a href="https://bugs.freedesktop.org/show_bug.cgi?id=49168" target="_top" rel="nofollow" link="external">https://bugs.freedesktop.org/show_bug.cgi?id=49168</a>. IMHO instead of flooding the Bugzilla, one can just disable it. 
<br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message">I think that it is not worth spending resources on migrating bugs to a
<br/>single bugzilla. IMHO, it is better to spend time on fixing other bugs,
<br/>improving the functionality, testing, ...
</div>
</div></blockquote>
Already some bugs are migrated (from Symphony for instance). Some of them are fixed already. 
<br/>I just can't imagine proper bug management in a project, when you have to follow many bugtrackers.
<br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message">The ideal process is described at
<br/><a href="http://wiki.documentfoundation.org/BugReport_Details#Initial_state" target="_top" rel="nofollow" link="external">http://wiki.documentfoundation.org/BugReport_Details#Initial_state</a><br/>Of course, developers are just humans, sometimes quite overloaded and
<br/>they do not follow the process. [...]
<br/>developers to close bugs by asking about the state. I wonder, how often
<br/>do you see such a bug with commits that is not closed?
</div>
</div></blockquote>
Disagree. It is a page for bug reporters. I really like the gerrit migration and would like to see it integrated with Bugzilla. Also always precommit hooks can be implemented if developers tend to forget to put a bug number into a commit message. I already stumbled upon UNCONFIRMED bugs which have been fixed already and suddenly changed into RESOLVED FIXED. I would like to know what is going on with the bugs at any moment.
<br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message">Well, we do not want to create bug report for each fix. It is too
<br/>complex process with poor results. If a developer is talkative, she
<br/>provides a good commit message. If she is not talkative, she would
<br/>create useless bug report. We could motivate them by asking for details,
<br/>saying thanks for info, ...
<br/>Anyway, I think that it is not important now. We do not have enough
<br/>people who could test all commits, so we do not need perfect commit
<br/>messages.
</div>
</div></blockquote>
It is very unfortunate and doesn't help triaging bugs. Another resource to watch by QA member - the commits.
<br/>I really like Bugzilla developers strict workflow. Every commit with bug number, patch reviewed by a specialist (not just +1 to get it as soon as possible), bug assigned and status changed upon commit. It can be done automatically.
<br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message">We currently do not have enough people doing bug triage. If we have, we
<br/>could start thinking about specializing. 
</div>
</div></blockquote>
I thought people mentioned in <a href="http://wiki.documentfoundation.org/FindTheExpert" target="_top" rel="nofollow" link="external">http://wiki.documentfoundation.org/FindTheExpert</a> would be interested what is going on in their component?
<br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message">I do not think that bugzilla is a good tool for handling these type of
<br/>tasks ;-)
</div>
</div></blockquote>
Disagree. I really like how Mozilla use Bugzilla (it's their tool, you know). Every Action Item, problem, request etc. is in the bugtracker. Everything. Since few weeks I try to know how LibreOffice project works and I have big trouble with it. So many mailinglists, posts, wiki articles to browse.   
<br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message">> Do you VERIFY bugs? I see just 62 bugs as VERIFIED FIXED. I do not see such
<br/>> section in Getting Involved. Surely there are users willing to participate
<br/>> this way.
<br/>We do not have enough people to sort new bugs, so nobody took care of
<br/>this :-)
<br/>Would you like to create a wiki page describing the process? 
</div>
</div></blockquote>
Why o why I expected such question....  :)
<br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message">What do you mean by the flag?
<br/>MAB just works. [..]
<br/>Alternatively, you just look at the query
<br/>and you see list of still opened bugs.
<br/>Note that the queries are available at
<br/><a href="http://wiki.documentfoundation.org/Release_Criteria#Blocker_Bug_Nomination" target="_top" rel="nofollow" link="external">http://wiki.documentfoundation.org/Release_Criteria#Blocker_Bug_Nomination</a></div>
</div></blockquote>
I can't describe it better than Bugzilla main developer, who offered help in
<br/><a href="https://bugs.freedesktop.org/show_bug.cgi?id=33070" target="_top" rel="nofollow" link="external">https://bugs.freedesktop.org/show_bug.cgi?id=33070</a>.
<br/>Also <a href="https://bugs.freedesktop.org/docs/en/html/flags-overview.html" target="_top" rel="nofollow" link="external">https://bugs.freedesktop.org/docs/en/html/flags-overview.html</a> is a good read.
<br/>I really like how Mozilla projects are using flags to nominate blockers and all other requests.
<br/>I can't imagine manageable and organized QA process without them. Please consider...
<br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message">> Well, sorry for such a pack of off-topic questions, but I'd like to
<br/>> understand QA in this project better.
<br/>It is fine. I hope that I did not discourage you. I feel that you want
<br/>to have everything perfect which is great. On the other hand, we have
<br/>only limited resources, we are just humans, and we need to optimize the
<br/>processes for this. The target is clear. We all want to improve LO with
<br/>each release and have the best office suite ever :-)
<br/>Thanks for all your contributions.
</div>
</div></blockquote>
Not at all. As I am getting into this more and more the time has come to ask - where I should sign to become QA member (level 1 :))?
<br/><br/><blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-message">PS: If you reply, please try to configure your mail client, so it puts
<br/>some prefix "> " before the old text and put your answer inline. 
</div>
</div></blockquote>
I am sorry if I produce garbage, but due to various reasons I am using nabble interface only...
<br/><br/>Best regards.
        
<br/><br/>
<hr noshade="noshade" size="1" color="#cccccc" />
<div style="color:#444; font: 12px tahoma,geneva,helvetica,arial,sans-serif;">
<div style="font-weight:bold">If you reply to this email, your message will be added to the discussion below:</div>
<a href="http://nabble.documentfoundation.org/Cleaning-bug-list-tp3988836p3991648.html">http://nabble.documentfoundation.org/Cleaning-bug-list-tp3988836p3991648.html</a>
</div>
<div style="color:#666; font: 11px tahoma,geneva,helvetica,arial,sans-serif;margin-top:.4em">
This email was sent by <a href="http://nabble.documentfoundation.org/template/NamlServlet.jtp?macro=user_nodes&user=481817">bfo</a> (via Nabble)<br/>
To receive all replies by email, <a href="http://nabble.documentfoundation.org/template/NamlServlet.jtp?macro=subscribe_by_code&node=3988836&code=bGlicmVvZmZpY2UtcWFAbGlzdHMuZnJlZWRlc2t0b3Aub3JnfDM5ODg4MzZ8LTE0NjUxOTE3MDY=">subscribe to this discussion</a><br/>
</div>