Petr Mladek wrote > >> I'd change the workflow a little bit by putting the obvious things at the >> top: >> - feature requests aka wishlist > I do not have any strong opinion for this. I think that it is is good to > be able to discuss features, so "enhancement" bugs in bugzilla might be > usable. >> - add target milestone if a feature is planned already > This must be done by developer, anyway :-) > Well, to be clear, I see all this more like how to triage guide, that is why I started with enhancements. Target milestone can be set by QA member if feature is available. https://bugs.freedesktop.org/show_bug.cgi?id=33773#c11 for instance.
>> - bugs reported against not supported branches - exclude those at >> reporting >> level by disabling old versions in select fields; but what to do when >> they >> appear anyway - mark them as INVALID at triaging? ask the reporter to >> check >> in new version? Any comments? > We need to be more careful here. The current rule is to do NOT modify > the version picker if you reproduce the problem with newer version. It > is because it is very valuable to know how the bug is old. It helps > developers to locate it. So, maybe, we should do it the other way and > set the field to the oldest version where it was found. > I was thinking about New bug reports, which should be reported for supported branches only (proposed in https://bugs.freedesktop.org/show_bug.cgi?id=51070). Unfortunately it depends on https://bugs.freedesktop.org/show_bug.cgi?id=50198. >> - is it Most Frequently Reported - then just dupe it > What do you mean by "Most Frequently Reported"? > Is it at https://bugs.freedesktop.org/duplicates.cgi for LibreOffice product. Then it can be handled very quickly, but I see that searching for dupes is already listed on http://wiki.documentfoundation.org/BugTriage > I would personally enable voting as well but some other people thing > that it is not objective. > Unfortunately I discovered https://bugs.freedesktop.org/show_bug.cgi?id=39739. WONTFIXed by Mr Bielefeld who authored http://wiki.documentfoundation.org/Vote_for_Enhancement, 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. 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. > You are right, regression are bad and we need to fix them with high > priority. On the other hand, you still need to compare them with other > reported bugs and decide what is more annoying for the daily work. We > could not blindly set the highest priority for a tiny functional problem > just because it is a regression. As someone said, you could view almost > any bug as regression, so we need to prioritize them as well. > I would keep the current approach. Add "regression" into Whiteboard and > set one level higher priority that you would set for non-regression. > I disagree. Many people just won't upgrade because of them. Fast query shows 180 opened bugs with regression keyword. Very worrying... > It actually helps to prioritize bugs as well. If reporter is not willing > to provide more information, the problem is probably not that important > for him. > Disagree, as providing proper bt is complicated. > Also note that some crashers are reproducible only in very strange > circumstances. Also some scenarios are very hard to prepare. We just > need help from reporters in these cases. > Sure, but IMHO only if bug is not reproducible. > If someone change the priority a wrong way, I would ask them not to do > it, explain that the level is not that important, and change it back. If > they change it once again, I would leave it as is. Developers would > filter it themselves :-) > I found https://bugs.freedesktop.org/show_bug.cgi?id=49168. IMHO instead of flooding the Bugzilla, one can just disable it. > I think that it is not worth spending resources on migrating bugs to a > single bugzilla. IMHO, it is better to spend time on fixing other bugs, > improving the functionality, testing, ... > Already some bugs are migrated (from Symphony for instance). Some of them are fixed already. I just can't imagine proper bug management in a project, when you have to follow many bugtrackers. > The ideal process is described at > http://wiki.documentfoundation.org/BugReport_Details#Initial_state > Of course, developers are just humans, sometimes quite overloaded and > they do not follow the process. [...] > developers to close bugs by asking about the state. I wonder, how often > do you see such a bug with commits that is not closed? > 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. > Well, we do not want to create bug report for each fix. It is too > complex process with poor results. If a developer is talkative, she > provides a good commit message. If she is not talkative, she would > create useless bug report. We could motivate them by asking for details, > saying thanks for info, ... > Anyway, I think that it is not important now. We do not have enough > people who could test all commits, so we do not need perfect commit > messages. > It is very unfortunate and doesn't help triaging bugs. Another resource to watch by QA member - the commits. 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. > We currently do not have enough people doing bug triage. If we have, we > could start thinking about specializing. > I thought people mentioned in http://wiki.documentfoundation.org/FindTheExpert would be interested what is going on in their component? > I do not think that bugzilla is a good tool for handling these type of > tasks ;-) > 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. >> Do you VERIFY bugs? I see just 62 bugs as VERIFIED FIXED. I do not see >> such >> section in Getting Involved. Surely there are users willing to >> participate >> this way. > We do not have enough people to sort new bugs, so nobody took care of > this :-) > Would you like to create a wiki page describing the process? > Why o why I expected such question.... :) > What do you mean by the flag? > MAB just works. [..] > Alternatively, you just look at the query > and you see list of still opened bugs. > Note that the queries are available at > http://wiki.documentfoundation.org/Release_Criteria#Blocker_Bug_Nomination > I can't describe it better than Bugzilla main developer, who offered help in https://bugs.freedesktop.org/show_bug.cgi?id=33070. Also https://bugs.freedesktop.org/docs/en/html/flags-overview.html is a good read. I really like how Mozilla projects are using flags to nominate blockers and all other requests. I can't imagine manageable and organized QA process without them. Please consider... >> Well, sorry for such a pack of off-topic questions, but I'd like to >> understand QA in this project better. > It is fine. I hope that I did not discourage you. I feel that you want > to have everything perfect which is great. On the other hand, we have > only limited resources, we are just humans, and we need to optimize the > processes for this. The target is clear. We all want to improve LO with > each release and have the best office suite ever :-) > Thanks for all your contributions. > 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 :))? > PS: If you reply, please try to configure your mail client, so it puts > some prefix "> " before the old text and put your answer inline. > I am sorry if I produce garbage, but due to various reasons I am using nabble interface only... Best regards. -- View this message in context: http://nabble.documentfoundation.org/Cleaning-bug-list-tp3988836p3991648.html Sent from the Dev mailing list archive at Nabble.com. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
